Migrate from Vercel to Coolify: what the work involves
For most Next.js and frontend apps, moving from Vercel to Coolify is a containerization and operations change, not a code rewrite. The app is packaged as a Docker container that Coolify builds from a Git repository, Dockerfile or prebuilt image, and the work centers on environment variables, domains, persistent storage, backups and the DNS cutover. The usual trigger is a renewal, a change in metered billing or a data residency requirement, and the people who do the work are typically platform or frontend engineers, often with an implementation partner who handles the server setup and cutover plan. Coolify's own migration guide uses Vercel as its example, which makes it a practical reference for the mapping exercise.
The effort and risk sit in the parts Vercel did for you without being asked. Serverless functions become container processes that you size and scale, previews move to Coolify's pull request previews, and rollbacks redeploy a retained image on the server. The guide notes that a rollback does not restore databases or persistent files, so backup schedules and restore tests must be set up separately, and Coolify's database backups do not cover Redis, Dragonfly or KeyDB. Confirm early which of your workloads depend on Vercel-managed storage or caching, and which databases sit with a third-party Marketplace provider, since those need their own move plan.
Coolify's documented sequence is to deploy without changing production DNS, configure environment variables and external dependencies, add persistent storage, verify a health check, and test on a temporary domain. Only then should production DNS point to Coolify, with the old platform kept running until the new setup is stable. Ask your team to plan for a parallel run, a named owner for the cutover window and a tested rollback path that does not depend on Vercel. Before quoting an implementation partner, confirm the number of apps, databases, preview requirements and the server capacity you intend to use, because these drive the scope and the recurring operations work.
Which Vercel capabilities map cleanly to Coolify
This table maps the main Vercel capabilities a team relies on to their closest Coolify equivalent and marks each as clean, needs rework or gap. Read it before the migration plan so you know which features move as-is, which need code or process changes, and which you must rebuild or replace on your own servers.
| Vercel capability | Coolify equivalent | Status |
|---|---|---|
| Serverless or managed runtime for Next.js and other frameworks | Application deployed as a Docker container from a Dockerfile, Nixpacks or Docker Compose build pack, running on a server you control | Needs rework: builds and runtime become your responsibility |
| Git-triggered builds from a repository | Git deployment through the GitHub App or other Git source, with Nixpacks, Static, Dockerfile or Docker Compose build packs | Clean: confirm the build pack matches your framework |
| Preview deployments per pull request | Coolify previews at a {{pr_id}}.{{domain}} URL, built from GitHub, GitLab, Gitea or Bitbucket and removed when the request closes | Needs rework: requires a wildcard DNS record and a GitHub App |
| Instant rollback to a previous deployment | Redeploy of a retained application image on the server | Needs rework: rolls back the app image only, not databases or persistent files |
| Domains and automatic HTTPS | Coolify proxy (Traefik by default or Caddy) with automatic HTTPS, or a custom proxy you operate | Clean: confirm DNS and certificate issuance on your domains before cutover |
| Environment variables per environment | Application environment settings configured in Coolify before the first production deploy | Needs rework: export and re-enter values, including secrets, by hand |
| Global CDN and edge caching | No equivalent built in; requires a CDN or caching layer you add and operate | Gap: plan a separate CDN before cutover if global caching matters |
| Edge functions and edge middleware | No equivalent built in; move logic into the application container or a service you run | Gap: confirm which edge logic your app depends on |
| Managed image optimization | No built-in equivalent; confirm your framework's image handling and any library you need in the container | Gap: confirm before migration, as this typically needs rework |
What data and integrations have to move by hand
Vercel holds more than code. Environment variables, third-party services, persistent files and any databases bought through Vercel's Marketplace each need a path into Coolify before production DNS changes. The cards below separate what Coolify can import directly from what your team must export and rebuild.
Environment variables and secrets
Each project's environment variables must be re-entered in Coolify for every application and preview target, and they must be set before the first build that depends on them. Vercel separates secret values from plain ones, and secret values may not be returned by its CLI, so confirm with your team which values are stored only in Vercel and must be recovered from the owning service or a password manager. Check build-time and runtime variables separately, since Next.js inlines some values at build time and a wrong one only shows up after a rebuild. Coolify's migration sequence treats this as a required step before the test domain.
External services and webhooks
Payment providers, identity callbacks, email senders, analytics and CMS webhooks often hold the Vercel domain or IP as an allowed origin or callback URL. Inventory every outbound and inbound integration, then update allow lists and callback URLs to the Coolify server before cutover. Plan for a period where both platforms answer requests, so that webhooks sent during DNS propagation are not lost. Coolify's sequence tests on a temporary domain first, which lets you confirm each integration against the new address before production DNS moves.
Persistent files and uploads
Vercel functions have no local disk that survives a deployment, so files your app writes at runtime may live in Vercel Blob or in a third-party bucket. On Coolify, add persistent storage for any path your container must keep across redeploys. Coolify's rollback redeploys a retained image but does not restore persistent files, so a restore plan for these volumes is separate work. Confirm with your team whether Blob content will be exported through the provider's SDK and copied to S3-compatible storage you operate, or left in place and called over the network.
Databases Coolify can deploy or import
Coolify deploys PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Dragonfly, KeyDB and ClickHouse as managed services on your server. For PostgreSQL, Coolify's Import Backup accepts SQL dumps, custom archives, tar archives and all-database dumps, which covers most exports from a hosted Postgres. Create a fresh dump, restore it to a Coolify database, run a test query set against it, and only then repoint the application's connection string. Keep the source database read-only during the final copy so no writes are lost.
Backups that Coolify does not schedule
Scheduled backups in Coolify cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB. If Vercel-adjacent caches or session stores run on those engines, you must choose persistence settings and an external backup method yourself, and test a restore. Redis-compatible data often holds sessions or rate-limit counters that are safe to rebuild, so confirm with the application owners which keys are authoritative before you decide what to back up.
Marketplace-hosted data
Databases and stores bought through Vercel's Marketplace, such as those from Neon or Upstash, are held by the provider, not by Vercel. Moving them is an export from that provider, followed by an import into a self-hosted instance, and the exact export tooling and any retention limits belong to that provider. Ask each Marketplace provider for its export procedure, the format it offers, and how long your data stays available after you cancel. Record the answers in the cutover plan before setting a target date.
How to run Vercel and Coolify in parallel before cutover
This sequence moves a Vercel project to Coolify while Vercel keeps serving production, so each stage produces evidence before DNS changes. Vercel stays available as the rollback path until the Coolify deployment has proven stable.
Inventory every Vercel project and dependency
List each project, its framework, build settings, environment variables, custom domains, serverless functions, scheduled jobs, storage and databases, and any Marketplace integrations such as hosted Postgres or Redis. Mark which items Coolify will host and which will stay external. The output is a written inventory with an owner for each item, and you know it is done when someone outside the migration team can read it and name every dependency.
Deploy the app to Coolify without changing DNS
Connect the server to Coolify, then deploy the application from its Git repository using a Dockerfile, Nixpacks or the build pack that fits the framework. Production DNS keeps pointing at Vercel throughout this step, so users see no change. The output is a running container on Coolify and a build log you can compare with the Vercel build. Confirm the image builds reproducibly from a clean checkout.
Configure environment variables and external dependencies
Recreate each environment variable in Coolify, keeping production and preview values separate. Check every external dependency the app calls, including third-party APIs, webhooks and databases, and confirm the Coolify server can reach them. Vercel does not export secret values, so the team must retrieve them from the owning system. The output is a variables list checked against the inventory, and you know it is done when the app starts without missing configuration errors.
Add persistent storage and verify the health check
Attach persistent volumes for any file output or uploads that the app writes, and move those files to object storage if the app relies on Vercel Blob or similar services. Configure a health check endpoint that Coolify can call, then confirm it returns success after a container restart. The output is a documented storage mapping and a passing health check. Confirm that backups for any database are set up separately, because a Coolify rollback does not restore databases or persistent files.
Pilot the app on a temporary domain
Attach a temporary domain to the Coolify deployment and run the functional tests, smoke tests and key user journeys against it. Compare responses, redirects, headers and rendered pages with the Vercel production site, and test any preview workflow you plan to keep, including the wildcard DNS record that pull request previews need. The output is a test report with each difference either fixed or accepted by the owner. You know it is done when the pilot matches production behavior on the agreed checks.
Run in parallel and cut DNS over to Coolify
Lower the TTL on the production records ahead of the change, then point the production DNS to the Coolify server. Watch error rates, latency and logs on both platforms while traffic moves, and keep the Vercel deployment and its domain configuration unchanged. The output is production traffic served by Coolify and a dated record of the change. You know it is done when monitoring shows stable behavior and the team has confirmed it with the service owner.
Keep Vercel as rollback and decommission after stability
Leave the Vercel project in place until the Coolify deployment has run stably for the period your change policy requires, and restore DNS to Vercel if a severe fault appears. Only after the owner signs off should you remove the Vercel project, its domains and its integrations. Confirm with Vercel and the billing team how the subscription, usage and any retained data are closed. The output is a decommission record listing what was removed and what was retained.
Setting up GitHub pull request previews with wildcard DNS
Set up pull request previews early in the migration, because Vercel's per-branch previews are often how reviewers, product owners and QA sign off on changes. Coolify recommends installing its GitHub App for pull request previews, since automated pull request comments need permissions that a plain webhook does not grant. Install the app on the repositories that need previews, then choose the preview deployment option on each Coolify application. Keep the default preview URL template, {{pr_id}}.{{domain}}, unless your naming standard requires a different pattern.
That default template depends on DNS. Add a wildcard DNS record, such as *.preview.example.com, pointing at the same server that runs the Coolify proxy, so every pull request number resolves without a manual record. Confirm with your DNS provider that wildcard records are supported at the zone level and that the record does not conflict with existing subdomains. Coolify's proxy must also be able to obtain TLS certificates for these hostnames, so check how your chosen proxy handles certificates for each new subdomain before you rely on previews for review.
Coolify removes a preview when its pull request is closed or merged, so reviewers should capture any link they need before a merge. Coolify's preview support also covers GitLab, Gitea and Bitbucket, so a team that is moving its repositories at the same time can keep the same workflow. Before cutover, list every Vercel preview URL that is shared in tickets, client reviews or stakeholder links, and decide which ones will be replaced. Vercel's protection for preview URLs does not carry over automatically, so confirm how each Coolify preview will be restricted, whether by basic authentication, IP allowlisting at the proxy or a VPN, and test that an unauthorized visitor cannot open a preview.
What drives the cost and duration of the move
This table breaks the cost of moving a Vercel estate to Coolify into its components, showing who is paid, what recurs and what pushes each cost up. Read it as a checklist for building a quote, since the drivers are your project count, databases, build setup and preview volume rather than a single headline figure.
| Cost component | Who is paid or what it covers | One-time or recurring | What drives it up |
|---|---|---|---|
| Engineering time for the move | Your team or a partner, for mapping functions, env vars, domains and cutover | One-time | Number of projects, custom Vercel config, edge or middleware logic, and Marketplace integrations to re-create |
| Server capacity | Cloud or data center servers that run Coolify and your app containers | Recurring | Concurrent app count, memory-heavy Next.js builds, and whether you add a second server for redundancy |
| Server operation | Your operations staff for OS updates, Docker, the coolify-proxy container and certificate checks | Recurring | Number of servers, Linux distributions in use, and how often base images change |
| Coolify edition | Self-hosted Coolify is Apache-2.0 and free, while Coolify Cloud costs $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing (Coolify pricing page) | Recurring if you choose Coolify Cloud | Server count. Ask whether the managed control plane fits your data residency rules before choosing it |
| Backup storage and restore testing | S3-compatible storage for scheduled PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse dumps, plus staff time to test restores | Recurring, with a one-time setup | Database count, dump size, retention by count, days or size, and how often you restore to test |
| Patching and on-call | Staff rota for security updates, incident response and dependency upgrades | Recurring | Preview volume, public traffic, number of production apps and the Coolify upgrade cadence, including the v5 line noted in the v4 release notes |
What usually goes wrong and how to prevent it
Most failed Vercel-to-Coolify moves come from assumptions carried over from a managed platform: that a rollback restores everything, that backups exist because a schedule was set, or that DNS and previews will work without extra setup. Each card below names one of these gaps and the check that closes it before production traffic moves.
Rollbacks do not restore data
Coolify's guide notes that a rollback can redeploy a retained application image but does not restore databases or persistent files. On Vercel, teams often assume a rollback returns the whole app to a prior state. On Coolify, a bad migration that also wrote to PostgreSQL or uploaded files stays written after the rollback. Prevention: before each cutover, take a database dump and snapshot the persistent volumes, and write down which data a rollback will not reverse.
Untested backup restores
Coolify can run scheduled PostgreSQL backups with retention by count, days or size, and can upload them to S3-compatible storage. A schedule that has never been restored is not evidence of recovery. Import Backup accepts several dump formats, so the restore path itself needs a rehearsal on a separate server. Prevention: restore the latest backup into a scratch database, run the application against it, and record how long the restore took.
Redis data without backups
Coolify deploys Redis, Dragonfly and KeyDB, but its scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse only. Vercel workloads that use a Redis-compatible store for sessions, queues or caches often inherit that store with no backup process on the new side. Prevention: list every Redis instance the app uses, decide which keys must survive a server loss, and add an explicit export or replication job for them.
DNS cutover without a tested domain
Coolify's documented sequence deploys without changing production DNS, then tests on a temporary domain before pointing production records at the server. Teams that switch DNS first discover missing environment variables, failing health checks or absent persistent storage with live users on the app. Prevention: verify the health check and external dependencies on the temporary domain, keep the Vercel project running, and lower the TTL on the production record before the change window.
Missing wildcard DNS breaks previews
Coolify's default preview URL template is {{pr_id}}.{{domain}}, which needs a wildcard DNS record pointing at the server. Without it, pull request previews build but their URLs never resolve, and reviewers assume the pipeline is broken. Coolify's GitHub App also needs its permissions to post pull request comments. Prevention: create the wildcard record, confirm it resolves to the server address, and open a test pull request before telling developers that previews are live.
Server sizing below the minimum
Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, and it runs only on specific Linux distributions. Teams often install it on the smallest instance they had for a static site, then find that Docker image builds exhaust disk or memory during deploys. Build caches and retained images also grow over time. Prevention: size the server for the heaviest build plus database and proxy load, monitor free disk, and prune old images on a schedule.
How the move differs by starting point
A static site or a frontend-only build has the smallest change surface. The build output is a set of files, so Coolify can serve it through its Static build pack or a Nixpacks build, and the main work is reproducing the build command, output directory and domain setup rather than rewriting code. Most of the effort lands on DNS and on preview behavior, because the deployment itself is usually quick to repeat.
- Build settings: Confirm the build command, Node version and output directory in Coolify match what the Vercel project used.
- Environment variables: Recreate any build-time variables, and check which ones were marked as secret in Vercel, since those values cannot be exported.
- Previews: Set up the GitHub App and a wildcard DNS record before relying on pull request URLs for review.
- Forms and redirects: Check any redirect or rewrite rules and third-party form handlers that depended on the old host.
- Cache headers: Compare the headers Vercel served with the ones the Coolify proxy returns for assets.
Before cutover, confirm that every redirect and asset path returns the same status and content on the temporary domain.
A Next.js app that uses server rendering, route handlers, middleware or image optimization depends on runtime behavior that Vercel supplies for you. Running it on Coolify means packaging it as a Node.js server or a Docker container, which Next.js documents as supporting all of its features. The migration work is mostly about the features Vercel handled automatically, such as caching, image processing and scaling across instances. The Next.js migration page covers those details, so this tab only covers what changes in the Coolify workflow.
- Container build: Use a Dockerfile or Nixpacks build and confirm the container starts and answers a health check before pointing a domain at it.
- Multiple instances: If Coolify runs more than one container for the app, plan for how server-side state is shared.
- Proxy behavior: Verify that streaming responses pass through the Coolify proxy without buffering.
- Rollback scope: A rollback redeploys a retained image, so it reverts code but not data changes made in the meantime.
- Deploy steps: Keep the Vercel project live until the Coolify deployment is stable under real traffic.
Check that the features your app uses are listed as supported in the Next.js deployment guide for Node.js servers and containers before you commit to a cutover date.
An app that relies on serverless functions and managed data has the largest number of moving parts. Each function becomes part of a container or service, and any data held in a managed provider needs a new home on your servers. Coolify deploys PostgreSQL, MySQL, MariaDB, MongoDB, Redis and several other databases, so many data stores can be moved onto the same server or a separate one. Coolify's guide to managed platforms maps serverless runtimes to Docker containers, so the function logic moves but the hosting model changes.
- Function mapping: Group related functions into services and check cold-start assumptions, timeouts and memory limits that Vercel enforced.
- Database move: Export data and restore it with Coolify's import tools, which accept PostgreSQL SQL dumps and custom archives.
- Backups: Scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB, so plan a separate approach for caches that hold data you need.
- Connection strings: Update every external dependency, including Marketplace providers, to the new endpoints before cutover.
- Persistent files: Rollbacks do not restore persistent files, so set up storage and its backups separately.
List every managed service the app calls and confirm who will back up and restore each one before the first production deployment.
A team with several Vercel projects moving to one Coolify server changes the operating model more than any single app. Coolify connects to each server over SSH, prepares it to run Docker workloads and deploys applications from Git, Dockerfile, Docker Compose or prebuilt images, so many projects can share one host. The work shifts to capacity planning, isolation between projects, and shared proxy and DNS configuration. Projects that need separate failure domains or compliance boundaries may belong on separate servers.
- Capacity: Check CPU, memory and disk against the combined load of all projects. Coolify requires at least 2 CPU cores, 2 GB RAM and 10 GB of free disk as a minimum, which is a floor rather than a sizing guide.
- Shared proxy: Each server runs one coolify-proxy container, so a proxy problem affects every project on that host.
- Domains and previews: Assign each project its own domain and a wildcard record, and confirm preview URLs do not collide.
- Access: Decide which team members can deploy to which projects, and review API tokens.
- Multi-server layout: If you add servers later, plan how projects are placed before you move them.
Write down which projects share a host and which need their own, because that decision is hard to reverse once several teams depend on it.
Questions teams ask before moving from Vercel to Coolify
How much does moving from Vercel to Coolify cost?
The software is free to self-host, so the cost is the servers, the people who run them and any services you add. Coolify's self-hosted edition is described on its pricing page as free forever with all features and no limitations. Vercel's cost is metered: its Pro plan includes a $20 usage credit, and charges apply above it. On the Coolify side, budget for servers that meet the minimum of 2 CPU cores, 2 GB RAM and 10 GB of free disk, plus backup storage, a monitoring setup, and the engineering hours for builds, DNS, backups and upgrades. If you prefer a managed Coolify instance, Coolify's pricing page lists Coolify Cloud at $5 per month for 2 connected servers and $3 per month for each additional server, with a 20% discount for annual billing. Ask any quote to separate one-time migration work from recurring server, storage and support costs.
How long does a Vercel to Coolify migration take?
The pace is set by how many projects you have, how much state they hold and how many DNS records and external services must change. Coolify's own sequence is simple to state: deploy without changing production DNS, set environment variables and external dependencies, add persistent storage, verify a health check, test on a temporary domain, then point production DNS to Coolify and keep Vercel running until the new setup is stable. Projects with databases, uploads or many integrations take longer than static or stateless frontends. Because no duration is supplied for this work, ask DeployOpen or your internal lead for a timeline based on a written inventory of projects, databases and domains.
What does our team need to provide before the migration starts?
Gather access and inputs before anyone changes production. You will need administrative access to the target servers so Coolify can connect over SSH and prepare them for Docker workloads, plus a Git provider connection for each repository. Collect the Vercel environment variables, which must be exported with care because some secret values cannot be read back from Vercel, and list every external dependency, such as hosted databases, storage and webhooks. You also need control of the DNS zone, including the ability to add a wildcard record for pull request previews, and accounts for any third-party service that issues certificates or sends email. Confirm each item with your own administrators before scheduling cutover.
Can our internal team migrate from Vercel to Coolify without outside help?
A team with Linux, Docker, DNS and CI experience can migrate simple, stateless frontends alone, using Coolify's documented steps. The work gets harder when projects depend on persistent files, production databases, scheduled jobs or strict change control, because those need backup, restore and monitoring designed before cutover. Coolify does not restore databases or persistent files on rollback, so someone must own that design. If your team lacks capacity or the required skills, a fixed-scope engagement from DeployOpen can plan, implement and document the move in your own infrastructure. Fixed scope, deliverables and timelines are agreed in writing before work starts.
How do rollbacks and backups work after moving to Coolify?
Rollback and backup are separate tasks, and only the first is covered by the platform. Coolify's guide for teams coming from managed platforms notes that a rollback can redeploy a retained application image on the server, which is similar to Vercel's instant rollback for code. It does not restore databases or persistent files. Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, can upload to S3-compatible storage, and support retention by count, days or size. Redis, Dragonfly and KeyDB are not covered by scheduled backups. Test restores on a separate server, and confirm retention and storage costs with your own recovery targets.
Which Vercel features have no direct Coolify equivalent?
Coolify maps the core workflow well: a Git push builds a container, a reverse proxy routes domains and handles HTTPS, and preview deployments build pull or merge requests at a default URL that needs wildcard DNS. Gaps remain. Vercel's global CDN and edge network are not replicated by a single Coolify server, so latency for distant users may change. Vercel's managed functions run on infrastructure you no longer operate, so each function must become a container or service with its own resource limits. Vercel's usage analytics, Blob storage and Marketplace integrations need replacements. Ask Coolify or DeployOpen to confirm each feature your applications rely on before you commit.
Should we use Coolify Cloud or self-host Coolify?
Choose Coolify Cloud when you want the Coolify control panel run for you while your applications stay on servers you own. Choose self-hosting when you need the whole control plane inside your own network, for example to meet a data residency rule that covers management tooling. Coolify Cloud costs $5 per month for 2 connected servers plus $3 per month for each additional server, according to Coolify's pricing page, while the self-hosted edition is free to run with its own server and operations costs. Coolify is licensed under Apache-2.0. Confirm with Coolify which data the managed instance stores before you decide.
How DeployOpen scopes and runs the migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside your own infrastructure. For a Vercel to Coolify move, that means the Coolify server or servers, their cloud accounts or data center network, the DNS zone, the GitHub App used for previews and the backup targets all stay under your control. Most engagements are fixed-scope, so the work starts only after the scope, deliverables and timelines are agreed in writing. A quote follows from that written scope, and DeployOpen does not publish a price list.
A useful scope for this migration usually names the Vercel projects in and out of the move, the runtime each one needs in a container, the environment variables and external services each one calls, the persistent storage and database backups to be set up separately, the wildcard DNS record for preview URLs, the health check each application must pass, and the date DNS changes and the old Vercel project is retired. Ask for each of these to appear as a deliverable with an acceptance check, including a rollback plan that covers databases and persistent files, since a Coolify rollback redeploys a retained image but does not restore them. Ask whether the work covers the cutover rehearsal on a temporary domain and whether the old platform stays live until stability is confirmed.
Ongoing work is separate from the migration itself and can be contracted as a retainer. Common retainer items are Coolify upgrades between releases, such as moving through the v4 line while v5 is previewed, restore tests for the backup schedule, certificate and proxy checks, and periodic review of server capacity. Ask for the retainer scope, response expectations and the upgrade procedure in writing. DeployOpen prepares systems, controls and evidence for compliance reviews, but independent auditors and certification bodies issue any audit report or attestation.
