Migration runbook

Migrate Next.js from Vercel to Hetzner

Move a portable Next.js application from Vercel to Hetzner Cloud with explicit server, firewall, backup, DNS, validation, and rollback controls.

By HostNextJS Editorial TeamReviewed by HostNextJS Technical Review Published Updated
01Typemigration
02Last reviewed
03Update policyReview every 90 days and after material Hetzner Cloud, Vercel DNS, or Next.js self-hosting changes.
Controlled change

Migration controls

01

Inventory

  • Target Hetzner project, location, server type, primary IPs, SSH keys, labels, Firewall, and backup policy
  • Source domains, TTLs, Vercel deployment, environment variables, integrations, and rollback owner
  • External database, storage, cache, cron, email, identity, webhook, and analytics paths
  • Required compute, memory, disk, transfer, availability, recovery time, and data-location constraints
02

Validation

  • Hetzner Firewall allows public 80/443, restricts administration, and leaves the Next.js listener private
  • TLS, redirects, streaming, images, cache behavior, dynamic routes, health checks, logs, and shutdown pass
  • Authentication, payments, email, uploads, webhooks, scheduled work, and analytics complete
  • CPU, memory, disk, transfer, error rate, latency, and business signals remain within written thresholds
03

Rollback

  • Preserve the previous DNS values and keep the known-good Vercel deployment routable
  • Name one rollback owner and thresholds for errors, latency, failed transactions, or resource saturation
  • Restore DNS to Vercel when a threshold is crossed, then verify resolver propagation and service recovery
  • Reconcile writes, uploads, webhooks, and scheduled events created while Hetzner received traffic
  1. 01

    Build the Hetzner target

    Create a maintained Linux server with SSH keys, a primary IP, Cloud Firewall, guest firewall, backups, monitoring, and a non-root application account.

  2. 02

    Deploy the proven artifact

    Install the supported runtime and reverse proxy, load production configuration securely, start the immutable artifact under supervision, and retain a prior release.

  3. 03

    Validate through the real hostname

    Resolve the production hostname to the candidate IP from a controlled client, issue TLS, and run the complete technical and business test plan before public DNS changes.

  4. 04

    Cut over and observe

    Lower TTL in advance, freeze unrelated releases, change the authoritative record, monitor both targets, and keep Vercel and its dependencies active through the rollback window.

Use this runbook only after the application runs as a portable production artifact. Hetzner provides the virtual machine, network controls, and optional disk backups; your team owns the runtime, proxy, release process, observability, data protection, and incidents.

Build an independently recoverable target

Create the server with an SSH key and attach a Cloud Firewall before exposing it. Permit HTTP and HTTPS publicly, restrict SSH to trusted sources where practical, and keep the application port private. Mirror essential controls in the guest firewall because provider and operating-system rules fail independently.

Enable Hetzner backups if they fit the recovery plan, but back up application data according to its own consistency requirements. Test restoration before the change window. Seven rotating server backup slots do not prove that a database or object store can be recovered.

Validate before DNS

Deploy the same artifact that passed portability testing. Exercise the candidate through the production hostname using controlled DNS or host resolution so redirects, cookies, certificates, callbacks, and origin checks see the real domain.

Measure resource headroom during representative load. A successful homepage request does not validate image optimization, streaming, cache revalidation, background work, or graceful shutdown.

Keep the old path live

Shorten TTL before cutover and record every original DNS value. Change only the required record. During the rollback window, monitor both technical health and transactions that matter to the business. If rollback triggers, restore traffic first, then reconcile data and external events rather than assuming DNS reversal erased the target window.

Methodology

How this resource was produced

The runbook combines Hetzner's documented Cloud server, Firewall, primary IP, and backup controls with the official Next.js self-hosting requirements. It assumes application portability is already proven and keeps Vercel serving until target validation passes.

Limitations
  • 01

    Hetzner Cloud supplies infrastructure, not a managed replacement for Vercel Functions, previews, CDN behavior, logs, or application services.

  • 02

    A server backup is not an application-consistent backup for an external database, object store, or event system.

FAQ

Questions about migrate next.js from vercel to hetzner.

No fog. Just the practical details developers need before moving a production app.

Can a Hetzner snapshot replace application rollback?

No. A snapshot can help reconstruct server disk state, but traffic rollback, external data, secrets, and events require separate controls.

Should I delete the Vercel project after DNS moves?

No. Keep it and its required integrations available through the agreed rollback and reconciliation window.

Next step

Turn the resource into a deployment decision.

Review a Hetzner cutover