Category: PaaS and containers
Managed Coolify and Dokploy: your own Heroku or Vercel in your account
The convenience of pushing and seeing the application go live, but on servers you pay for, with someone looking after the dashboard, the backups and everything running underneath.
- Where it runs
- In your account, in your name
- Backups
- With tested restores
- Updates
- Planned and documented
- Licence
- Coolify: Apache 2.0. Dokploy: Apache 2.0, except its proprietary folder
In short
Coolify and Dokploy are open source dashboards that turn your servers into a deployment platform in the style of Heroku or Vercel. We install them in your account, connect your repositories, set up the databases with backups we restore in tests, protect the dashboard and keep both the tool and the servers underneath up to date.
What do we look after?
Self-hosted Coolify or Dokploy installs with a single command, and that ease is deceptive: the hard part starts the day the disk fills up, a database without a backup gets corrupted or someone finds the dashboard open. This is what we keep under control:
Dashboard
Coolify or Dokploy on its own server, with restricted access, two-factor authentication and one user per person.
Deployments
Connected repositories, tidy environment variables and previews per branch where they add value.
Servers
The nodes where the applications run: patches, Docker, firewall and cleaning up old images.
Databases
PostgreSQL, MySQL, Redis or MongoDB in containers, with offsite backups and rehearsed restores.
Proxy and domains
Traefik with certificates that renew themselves and domains pointed without surprises.
Alerts
Failed deployments, containers stuck in a restart loop, disk and certificates about to expire.
How do we set it up?
The default installation puts the dashboard and the applications on the same machine. That is fine for testing; in production we prefer to separate responsibilities:
Dashboard server
Runs only Coolify or Dokploy and its internal database. Small, with no public traffic other than access to the dashboard.
Application servers
The dashboard drives them over SSH: it builds the images, starts the containers and configures the proxy.
Proxy with HTTPS
Traefik in front of each server routes traffic by domain and requests the certificates.
Offsite backups
Databases and dashboard backed up to S3-compatible storage in another location.
A single application server is enough to start with. When losing that machine starts to hurt, we add a second node and spread out what is critical; on Dokploy, with Swarm replicas. If Dokploy specifically is what interests you, we cover it in managed Dokploy.
Which problems do we find with a self-hosted PaaS?
- Disk full of images: every deployment leaves new layers and nobody scheduled the clean-up.
- Databases with no backup, or with an untested one: the backup button was switched on, but nothing was ever restored.
- Exposed dashboard with a shared user: a single password for the whole team and no two-factor authentication.
- Everything on the same machine: the dashboard, the applications and the databases go down together.
- Automatic dashboard updates: a new version changes something in the proxy on a Friday afternoon.
- Variables with secrets copied by hand between environments, with no idea which one is right.
How do we handle backups and updates?
There are two different backups and both matter. The one for your applications’ databases is scheduled from the dashboard itself to an S3-compatible bucket; periodically we restore one into a separate container and check that the data is there. The dashboard backup includes its internal database and its application key: without that key, the backup cannot decrypt the stored secrets. Coolify’s documentation describes this procedure and we rehearse it on a clean server.
We turn off automatic dashboard updates. We read the notes for each version, update a test environment first when the change is large, and apply it in production during an announced window. Security patches for the operating system and Docker follow their own, shorter schedule.
What is it like to move off Heroku or Vercel?
To move off Heroku, each application is built with Nixpacks, buildpacks or a Dockerfile, and the databases are exported and imported in a short window. From Vercel, static websites and Next.js applications with a Node server move across well; edge functions and some platform-specific optimisations need reviewing. We set up the new application in parallel, test it on a temporary domain and switch the DNS once everything responds the same way.
How do we protect the dashboard and the servers?
The dashboard is the key to everything: whoever gets in can deploy, read variables and delete databases. We put it behind a VPN or restrict access by IP, with two-factor authentication and named users. The servers only accept SSH with a key, and the firewall closes the database ports to the outside. If you need several teams with separate permissions, we organise it by projects inside the dashboard.
- GitPush or webhook
- DashboardCoolify or Dokploy, on its own server
- Application serversDocker, over SSH
- TraefikHTTPS and domains
- DatabasesBackups to S3
Where do we set it up?
In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.
Providers we set it up on
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Own server
| Provider | How we set it up | Things to bear in mind |
|---|---|---|
| Hetzner | A small cloud server for the dashboard and one or more for the applications, joined by a private network. | The most common combination in Europe. Backups go to Hetzner Object Storage, which is S3-compatible. |
| AWS | EC2 instances for the dashboard and the applications, with backups in an S3 bucket. | If you already have RDS, the applications can use it instead of containerised databases. |
| Google Cloud | Compute Engine machines and backups in Cloud Storage through its S3-compatible access. | A good fit if the rest of your infrastructure already lives on Google Cloud. |
| Azure | Virtual machines for the dashboard and the applications. | Blob Storage does not speak S3 natively: backups go to S3-compatible storage or through an intermediate step that we prepare. |
| DigitalOcean | Droplets for the dashboard and the applications, with backups in Spaces. | |
| OVH | Public Cloud instances and backups in OVHcloud Object Storage, which is S3-compatible. | |
| Own server | The dashboard and the applications on your physical or virtual servers, with Docker. | To publish to the internet we use a tunnel or a proxy in front; we do not open up the whole server. |
What is included
- A Coolify or Dokploy dashboard on a server separate from the applications, in your account and in your name.
- Repositories connected to deploy on push, with preview environments per branch where it fits.
- A proxy with automatic HTTPS certificates and your own domains for each application.
- Databases with scheduled backups to S3-compatible object storage, restored in tests.
- A backup of the dashboard itself: its internal database and its application key, kept off the server.
- Restricted access to the dashboard, two-factor authentication and named users for your team.
- Servers with system patches, Docker up to date, firewall and disk monitoring.
- Migration from Heroku, Vercel, Render or a hand-built server.
Frequently asked questions
Coolify or Dokploy: which do you recommend?
It depends on what you have. Coolify comes with a huge catalogue of ready-to-install services and works very well with several standalone servers over SSH. Dokploy is plainer, builds on Docker Swarm and is convenient if you plan to spread replicas across several nodes. If you already use one of the two, the usual choice is to stick with it.
Is it a real alternative to Vercel or Heroku?
For websites, APIs and containerised applications, yes: deploys from Git, previews per branch and automatic certificates. What you will not have is a global distribution network or edge functions like Vercel's. If your application depends on that, we discuss it before moving anything.
What happens if the dashboard server goes down?
The applications keep running, because they run on their own servers with Docker. What you lose in the meantime is the ability to deploy. That is why we separate the dashboard from the applications and keep its backup elsewhere: it can be rebuilt on another server without touching what is already live.
Does the Dokploy licence allow us to use it in our company?
Yes. Dokploy's code is published under the Apache 2.0 licence, except what sits inside its proprietary folder, which has a separate licence. Installing it on your servers and using it in your company is fine; if a feature you need falls within the proprietary part, we review it first.
Can our developers keep deploying on their own?
Yes, that is the idea. Each person logs in with their own user and deploys their applications from the dashboard or with a push. We take care of what you do not see: servers, backups, proxy, updates and alerts.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Official documentation consulted
The technical details on this page are based on:
- Coolify Docs: Backup and restore your Coolify instance
- Dokploy: LICENSE.MD (Apache 2.0 and proprietary folder)
Reviewed on