Coming from managed platforms
Managed platforms such as Vercel combine a deployment control plane, build infrastructure, runtime infrastructure, networking, and platform defaults.
Coolify provides the deployment control plane and coordinates Docker on servers you connect. This gives you more infrastructure control, but it also makes server capacity, networking, data persistence, and recovery explicit responsibilities.
Map familiar concepts
| Managed-platform concept | Coolify equivalent |
|---|---|
| Project or application | A resource inside a Coolify project and environment |
| Git integration | A Git source, deploy key, or public repository |
| Framework preset | Nixpacks or Railpack detection, or explicit build commands |
| Build image | A Docker image created on the deployment server or a build server |
| Serverless or managed runtime | A Docker container running on a server connected to Coolify |
| Production domain | A resource domain routed by the Coolify Proxy on the deployment server |
| Preview URL | A preview deployment with its own generated or configured domain |
| Environment variables | Resource variables with build-time, runtime, and preview scopes |
| Persistent data | A volume or bind mount, database, or external storage service |
| Platform logs | Deployment logs and runtime container logs |
| Instant rollback | A rollback to an image still retained on the deployment server |
What you must decide
Use this order to plan the Coolify deployment before moving production traffic.
Choose where the application runs
Select a server with enough CPU, memory, disk, and network capacity. A self-hosted installation starts with a localhost server that can run both Coolify and deployed resources. Coolify Cloud requires a connected or provisioned server for deployed resources.
Choose what Coolify deploys
Choose a deployment method that matches what you want to deploy. For a Git repository, use Nixpacks or Railpack for automatic framework detection, or choose Static, Dockerfile, or Docker Compose. Use Docker Image when another system already publishes the image.
Plan where data persists
Identify uploads, generated files, and application state that must survive a deployment. Configure persistent storage or use an external data service instead of the writable container filesystem.
Plan how traffic reaches the application
Identify the domain, DNS record, and internal port the application needs. The Coolify Proxy on the deployment server handles HTTP and HTTPS routing to that port.
Plan how the application recovers
Decide how you will recover from a bad release, data loss, or server failure. A rollback can redeploy a retained application image, but it does not restore databases or persistent files. Keep separate backups for persistent data and document how to restore external dependencies.
A safe migration sequence
- Deploy the application to Coolify without changing production DNS.
- Configure environment variables and external dependencies.
- Add persistent storage where the application writes important files.
- If the application provides a health endpoint, configure and verify a health check.
- Test the Coolify deployment through a temporary or generated domain.
- Point production DNS to the Coolify deployment server.
- Monitor runtime logs and keep the previous platform available until the Coolify deployment is confirmed stable.
Stop writes or use the database or storage system's supported migration process before transferring persistent data. Copying a live data directory can produce an inconsistent result.