Vercel zu Coolify oder Hetzner migrieren
Timo Wevelsiep•Aktualisiert: 30.08.2026Hinweis zum Inhalt: Versionen, Befehle und Preise können sich ändern. Bitte prüfen Sie kritische Schritte vor dem produktiven Einsatz eigenständig. Dieser Leitfaden ersetzt keine individuelle Beratung.
Eine Vercel-Anwendung soll auf Coolify oder kontrollierbarer Infrastruktur weiterlaufen? WZ-IT übernimmt die Vercel-Migration ab 1.990 Euro netto mit Bestandsaufnahme, Testumgebung, Cutover und optionalem Betrieb.
Eine Migration von Vercel zu Coolify oder Hetzner ist nicht nur ein neues Deployment. Vercel verbindet Build, Runtime, Functions, Domains, Umgebungsvariablen, Preview Deployments und häufig weitere Datenprodukte. Erst wenn diese Abhängigkeiten erfasst sind, lässt sich beurteilen, ob ein Container, ein Coolify-Projekt oder eine umfangreichere Zielplattform benötigt wird.
Dabei sind Coolify und Hetzner keine Alternativen derselben Ebene:
- Coolify ist eine selbst gehostete Deployment- und Anwendungsplattform.
- Hetzner ist ein möglicher Anbieter für Server, Netzwerk und weitere Infrastruktur.
- Eine typische Zielarchitektur kann Coolify auf Hetzner nutzen, muss es aber nicht.
Inhalt
- Was beim Wechsel wirklich migriert wird
- Vercel-Funktionen auf das Ziel abbilden
- Next.js selbst hosten
- Coolify als Zielplattform
- Daten, Storage und externe Dienste
- Staging, Preview und CI/CD
- Testmigration und Cutover
- Wann eine andere Zielarchitektur sinnvoll ist
Was beim Wechsel wirklich migriert wird
Vor der Zielentscheidung wird das Vercel-Projekt als System aufgenommen:
- Repository, Framework und Paketmanager
- Build Command, Output und Startverhalten
- Node.js-, Edge- oder andere Runtimes
- Serverless Functions, Middleware und Cronjobs
- Environment Variables für Development, Preview und Production
- Domains, Redirects, Header und DNS
- Preview Deployments und Branch-Regeln
- Datenbanken, Blob Storage, Queues oder andere Integrationen
- Webhooks, E-Mail, OAuth und externe APIs
- Logging, Analytics und Fehlerbeobachtung
Der Quellcode allein zeigt nicht immer alle Abhängigkeiten. Variablen, Integrationen und Domains können im Vercel-Projekt konfiguriert sein, ohne vollständig im Repository zu stehen. Diese Konfiguration wird vor dem ersten Ziel-Build exportiert oder nachvollziehbar dokumentiert.
Vercel-Funktionen auf das Ziel abbilden
| Vercel-Ebene | Mögliche Abbildung im Ziel |
|---|---|
| Git Deployment | Coolify-Git-Integration oder bestehende CI/CD-Pipeline |
| Build Settings | Dockerfile, Nixpacks oder expliziter Build-Prozess |
| Environment Variables | getrennte Secrets und Variablen je Umgebung |
| Serverless Functions | Node.js-Prozess, separater Service oder Job |
| Edge Functions | normale Server-Runtime oder gezielt gewählte Edge-Komponente |
| Cron Jobs | Plattform-Scheduler, System-Timer oder separater Worker |
| Preview Deployments | eigene Staging- oder Preview-Umgebungen |
| Domains und TLS | Reverse Proxy, DNS und automatisierte Zertifikate |
| Vercel-Datenprodukte | bestehender externer Dienst oder migriertes Zielprodukt |
| Logs und Analytics | zentrale Logs, Metriken und Fehlerbeobachtung |
Nicht jede Funktion braucht einen identischen Ersatz. Entscheidend ist das benötigte Verhalten. Eine selten ausgeführte Function kann beispielsweise als normaler Anwendungsendpunkt laufen. Eine latenzkritische Edge-Funktion benötigt dagegen eine gesonderte Architekturentscheidung.
Next.js selbst hosten
Next.js unterstützt Self-Hosting mit einem Node.js-Server oder einem Docker-Container. Die offizielle Dokumentation empfiehlt, einen Reverse Proxy vor den Next.js-Prozess zu setzen. Dieser übernimmt unter anderem TLS, Request-Grenzen und Schutz vor fehlerhaften oder unerwünschten Anfragen.
Für eine einzelne Instanz sind die Anforderungen häufig überschaubar. Bei mehreren Instanzen müssen zusätzliche Punkte geklärt werden:
- gemeinsames oder konsistentes Cache-Verhalten
- identische Build IDs und Deployment-Artefakte
- Umgang mit Incremental Static Regeneration
- Server Actions und zugehörige Schlüssel
- Image Optimization und Cache-Persistenz
- zustandslose Sessions oder gemeinsamer Session Store
- kontrolliertes Rolling Deployment
Ein erfolgreicher lokaler Start mit next start ist deshalb ein wichtiger Test, aber noch keine vollständige Betriebsabnahme.
Coolify als Zielplattform
Coolify kann Repository, Build, Deployment, Umgebungsvariablen, Domains, TLS und Health Checks in einer selbst gehosteten Oberfläche bündeln. Je nach Anwendung wird ein vorhandenes Dockerfile verwendet oder ein Build aus dem Quellcode erzeugt.
Vor der produktiven Nutzung werden festgelegt:
- welcher Branch Produktion auslöst
- ob Staging aus einem eigenen Branch oder Projekt entsteht
- welche Variablen pro Umgebung gelten
- welcher Health Check einen erfolgreichen Rollout bestätigt
- wie lange alte Deployments für einen Rückfall verfügbar bleiben
- wo Logs, Metriken und Alarme gesammelt werden
- welche persistenten Verzeichnisse gesichert werden müssen
Coolify reduziert den Bedienaufwand, übernimmt aber nicht automatisch die Verantwortung für Host, Backup, Sicherheit, Kapazität und Wiederherstellung. Diese Ebenen gehören weiterhin zum Betriebsmodell.
Daten, Storage und externe Dienste
Eine Anwendung kann weiterhin externe Datenbanken oder Storage-Dienste verwenden. Ein vollständiger Cloud Exit verlangt jedoch eine bewusste Entscheidung pro Abhängigkeit:
- Beibehalten: Der Dienst bleibt zunächst bestehen und nur die Anwendung wechselt.
- Parallel migrieren: Anwendung und Datenprodukt wechseln im selben Projekt, aber mit getrennten Testläufen.
- Später ablösen: Der erste Cutover reduziert Komplexität; die Datenmigration folgt als eigene Phase.
Für Datenbanken werden Version, Extensions, Rollen, Verbindungsgrenzen, Pooling, Backup und Latenz geprüft. Bei Objektspeicher zählen zusätzlich Bucket-Regeln, URLs, Metadaten, Objektzahlen und Prüfsummen. Schreibzugriffe während des Cutovers benötigen einen klaren Freeze, einen finalen Sync oder ein geeignetes Replikationsverfahren.
Wenn Vercel nur das Frontend bereitstellt und Supabase das Backend bildet, können beide Migrationspfade getrennt geplant werden. Für den Backend-Wechsel steht der Supabase-Migrationsbereich bereit.
Staging, Preview und CI/CD
Der Kunde kann nach dem Wechsel weiterhin normal am Code arbeiten: Ein Push startet den vereinbarten Build und stellt die Änderung nach den definierten Regeln bereit. Der Unterschied liegt darin, dass die Delivery-Strecke nun auf der gewählten Zielplattform kontrolliert wird.
Eine typische Trennung besteht aus:
- Development: lokale oder persönliche Entwicklungsumgebung
- Staging: feste Testumgebung mit separaten Variablen und Testdaten
- Production: produktive Umgebung mit Freigabe, Monitoring und Backup
- Preview: optional kurzlebige Umgebung pro Pull Request
Preview Deployments sind kein Selbstzweck. Sie benötigen klare Regeln für Datenbankzugriff, Secrets, Kosten und Bereinigung. Eine Vorschau darf nicht unbeabsichtigt produktive Daten verändern.
Testmigration und Cutover
Der Wechsel wird zuerst unter einer Testdomain ausgeführt. Die Abnahme umfasst mindestens:
- Build und reproduzierbarer Start
- Health Check und Neustartverhalten
- Login und kritische Nutzerwege
- Datei-Uploads und Hintergrundjobs
- E-Mail, Webhooks und externe APIs
- Caching und dynamische Seiten
- Logs, Metriken und Alarmierung
- Backup und ein definierter Wiederherstellungsweg
Vor der DNS-Umschaltung werden TTL, Wartungsfenster, Verantwortliche und Rückfallpunkt festgelegt. Die alte Vercel-Bereitstellung bleibt bis zum Ende des vereinbarten Rückfallfensters unverändert verfügbar, sofern Anwendung und Datenmodell das zulassen.
Wann eine andere Zielarchitektur sinnvoll ist
Coolify passt gut zu einer oder mehreren containerisierbaren Anwendungen mit Git-basiertem Deployment. Eine andere Architektur kann sinnvoller sein, wenn:
- mehrere Nodes mit eigenständigem Scheduling benötigt werden
- viele Teams, feinere Policies oder standardisierte Plattform-APIs erforderlich sind
- die Anwendung stark an Edge-Computing gebunden ist
- sehr kurze globale Latenzen ein zentrales Produktmerkmal sind
- komplexe Event-, Queue- oder Datenplattformen dazugehören
- spezielle verwaltete Dienste bewusst erhalten bleiben sollen
Dann kommen beispielsweise Kubernetes, eine getrennte Datenplattform oder ein hybrider Übergang infrage. Die PaaS-Exit-Checkliste hilft, Ziel und Reihenfolge vor der technischen Umsetzung festzulegen. Ist die Zielarchitektur noch offen, liefert der PaaS Exit Review eine belastbare Entscheidungs- und Migrationsgrundlage. Für andere Quellen vergleicht der Überblick Railway, Render und Fly.io die plattformspezifischen Unterschiede.
Quellen
Lieber betreiben lassen?
Sie möchten PaaS & Cloud Exit nicht selbst betreiben? WZ-IT übernimmt Einrichtung, Betrieb und Wartung - datenschutzorientiert aus Deutschland.
Anfrage
PaaS-Migration einordnen
Beschreiben Sie Quelle, Anwendung und gewünschtes Ziel. Wir prüfen den Migrationsweg für Runtime, Daten, Delivery und anschließenden Betrieb.
Häufig gestellte Fragen
Antworten auf die wichtigsten Fragen
Nicht unverändert. Viele Next.js-, Node.js- und containerisierbare Anwendungen lassen sich gut übertragen. Vercel-spezifische Functions, Edge-Runtimes, Datenprodukte, Preview-Logik und Integrationen müssen jedoch einzeln geprüft und gegebenenfalls ersetzt werden.
Nein. Hetzner ist ein möglicher Infrastrukturprovider. Coolify ist eine selbst gehostete Plattform für Builds, Deployments, Domains und Anwendungsverwaltung und kann auf Hetzner oder anderer geeigneter Infrastruktur betrieben werden.
Ja. Next.js dokumentiert Self-Hosting ausdrücklich. Für produktiven Betrieb müssen jedoch Reverse Proxy, Cache-Verhalten, persistente Daten, mehrere Instanzen, Image Optimization und die tatsächlich genutzten Framework-Funktionen berücksichtigt werden.
Ja, wenn die Zielplattform mit dem Git-Repository und dem vorgesehenen Branch-Modell verbunden wird. Builds, Health Checks, Freigaben, Staging und Rollback werden dabei neu definiert und getestet.
Bei einer zustandslosen Anwendung kann die Umschaltung kurz sein. Datenbanken, Storage, laufende Jobs, DNS-TTL und Schreibzugriffe bestimmen den tatsächlichen Cutover. Deshalb wird die Zielumgebung vor der Umschaltung vollständig getestet.
Die PaaS- und Cloud-Migration beginnt bei 1.990 Euro netto. Der konkrete Umfang hängt von Runtime, Vercel-Diensten, Daten, Umgebungen, Integrationen und dem gewünschten Betriebsmodell ab.
