Migrate Vercel to Coolify or Hetzner

Moving a Vercel application to Coolify or controlled infrastructure? WZ-IT provides Vercel migration from EUR 1,990 excluding VAT with discovery, a test environment, cutover and optional ongoing operations.

A migration from Vercel to Coolify or Hetzner is more than a new deployment. Vercel combines builds, runtime, functions, domains, environment variables, preview deployments and often additional data products. Only a complete dependency inventory shows whether the target needs one container, a Coolify project or a broader platform architecture.

Coolify and Hetzner are not alternatives at the same layer:

• Coolify is a self-hosted deployment and application platform.
• Hetzner is one possible provider for servers, networking and other infrastructure.
• A common target design runs Coolify on Hetzner, but neither component requires the other.

Contents

• What actually moves
• Map Vercel capabilities to the target
• Self-host Next.js
• Use Coolify as the target platform
• Data, storage and external services
• Staging, previews and CI/CD
• Rehearsal and cutover
• When another target architecture fits better

What actually moves

Inventory the Vercel project as a complete system before choosing the target:

• repository, framework and package manager
• build command, output and start behaviour
• Node.js, edge or other runtimes
• serverless functions, middleware and cron jobs
• environment variables for development, preview and production
• domains, redirects, headers and DNS
• preview deployments and branch rules
• databases, blob storage, queues or other integrations
• webhooks, email, OAuth and external APIs
• logging, analytics and error tracking

Source code does not always expose every dependency. Variables, integrations and domains may live in the Vercel project without being represented fully in the repository. Export or document that configuration before the first target build.

Map Vercel capabilities to the target

Not every feature needs an identical replacement. The required behaviour is what matters. An infrequently called function may run as a normal application endpoint, while a latency-sensitive edge function needs a separate architecture decision.

Self-host Next.js

Next.js supports self-hosting with a Node.js server or Docker container. Its official documentation recommends placing a reverse proxy in front of the Next.js process. This layer can handle TLS, request limits and protection against malformed or unwanted traffic.

One instance is often straightforward. Several instances introduce additional controls:

• shared or consistent cache behaviour
• identical build IDs and deployment artefacts
• Incremental Static Regeneration behaviour
• Server Actions and their keys
• image optimisation and cache persistence
• stateless sessions or a shared session store
• controlled rolling deployments

A successful local next start is therefore an important test, but not a complete production acceptance.

Use Coolify as the target platform

Coolify can combine repository, build, deployment, environment variables, domains, TLS and health checks in a self-hosted interface. Depending on the application, it uses an existing Dockerfile or builds from source.

Define before production:

• which branch triggers production
• whether staging uses a separate branch or project
• which variables apply to each environment
• which health check confirms a successful rollout
• how long old deployments remain available for rollback
• where logs, metrics and alerts are collected
• which persistent paths require backups

Coolify reduces operational interaction, but it does not automatically assume responsibility for the host, backups, security, capacity or recovery. Those layers remain part of the operating model.

Data, storage and external services

The application may continue using external databases or storage. A complete cloud exit requires an explicit decision for each dependency:

1. Retain it: only the application moves at first.
2. Migrate in parallel: application and data service move in one project with separate rehearsals.
3. Replace it later: the initial cutover stays smaller and the data move becomes another phase.

For databases, assess version, extensions, roles, connection limits, pooling, backups and latency. Object storage adds bucket rules, URLs, metadata, object counts and checksums. Write traffic during cutover needs a clear freeze, final sync or suitable replication method.

When Vercel only serves the frontend and Supabase provides the backend, both paths can be planned separately. The Supabase migration knowledge area covers the backend move.

Staging, previews and CI/CD

The customer can keep developing normally after the move: a push triggers the agreed build and deploys the change under the target rules. The delivery path now runs on the selected platform.

A common separation is:

• Development: local or personal development environment
• Staging: stable test environment with separate variables and test data
• Production: production environment with approval, monitoring and backups
• Preview: optional short-lived environment per pull request

Preview deployments are not free of operational design. They need rules for database access, secrets, cost and cleanup. A preview must not be able to change production data accidentally.

Rehearsal and cutover

Run the target under a test domain first. Acceptance covers at least:

• build and reproducible startup
• health check and restart behaviour
• login and critical user journeys
• uploads and background jobs
• email, webhooks and external APIs
• caching and dynamic pages
• logs, metrics and alerting
• backup and a defined recovery path

Set DNS TTL, maintenance window, owners and rollback point before switching. Keep the old Vercel deployment unchanged until the agreed rollback window ends, where application and data design allow it.

When another target architecture fits better

Coolify suits one or more containerisable applications with Git-based deployments. Another architecture may fit better when:

• multi-node scheduling is required
• several teams, granular policies or standard platform APIs are needed
• the product relies heavily on edge computing
• very low global latency is a central feature
• complex event, queue or data platforms belong to the system
• selected managed services should deliberately remain

Kubernetes, a separate data platform or a hybrid transition may then be appropriate. Use the PaaS exit checklist to define target and sequence before implementation. Where the target architecture remains open, the PaaS Exit Review provides a sound decision and migration basis. For other sources, the Railway, Render and Fly.io comparison explains the platform-specific differences.

Sources

• Next.js: Self-Hosting
• Vercel: Environment Variables
• Vercel: Functions
• Coolify: Applications