Vom Git-Repository in die Produktion: Dockup-Deployment-Leitfaden

Ein Git-Repository in die Produktion zu bringen, erfordert mehr, als ein Remote zu verbinden und auf „Deploy“ zu drücken. Die Plattform muss das Service-Ziel, den Branch, die Build-Methode, den Startbefehl, den Listening-Port, die Umgebung, die Health-Gate-Bedingung und den Recovery-Weg kennen. Dockup macht diese Entscheidungen explizit und unterstützt sowohl automatische Nixpacks-Builds als auch Dockerfiles aus dem Repository.

Dieser Leitfaden beginnt mit einem Repository, das noch nie deployed wurde, und endet mit einer verifizierten URL, Deployment-Historie, Logs und einem getesteten Rollback-Befehl.

Was sollte vor dem ersten Production-Deployment geprüft werden?

Stelle sicher, dass das Repository ohne nicht dokumentierten lokalen Zustand deploybar ist. Ein sauberer Clone sollte alles enthalten, was zum Installieren der Dependencies und zum Starten der Anwendung erforderlich ist – mit Ausnahme von Secrets.

Verwende diese Checkliste:

Prüfung	Erwartetes Ergebnis
Standard-Branch	Der vorgesehene Production-Branch ist vorhanden
Dependency-Lockfile	Für reproduzierbare Installationen committed
Startprozess	Bindet an den konfigurierten Port und 0.0.0.0
Health-Route	Liefert Erfolg ohne externe Seiteneffekte
Datenbankmigrationen	Verfügen über einen expliziten, sicheren Ausführungsplan
Secrets	Außerhalb von Git gespeichert
Persistente Dateien	Verwenden ein Volume statt des Container-Dateisystems
Rollback	Das vorherige Deployment kann erneut ausgeführt werden

Installiere die CLI und authentifiziere dich:

npm install -g dockup-cli
export DOCKUP_TOKEN="<TOKEN>"
dockup whoami --json

Liste vorhandene Services auf, bevor du etwas erstellst:

dockup services --json

So verhinderst du doppelte Ressourcen und bestätigst die genaue Konvention für Workspace und Ziel.

Wie unterstützt Dockup create Git-Deployments?

Der übliche Befehl für das erste Deployment erstellt den Service, deployed ihn, wartet auf das Ergebnis und verknüpft das aktuelle Verzeichnis:

dockup create api \
  --repo https://github.com/acme/api \
  --project production \
  --branch main \
  --deploy \
  --wait \
  --link \
  --json

Das resultierende Ziel ist production/api. Der .dockup-Link ermöglicht es späteren Befehlen, diesen Service aufzulösen, wenn sie innerhalb des Repositorys ausgeführt werden. In der Production-Dokumentation sollte dennoch immer das vollständige Ziel angegeben werden.

Nach einem unterbrochenen Provisioning-Versuch solltest du die Services auflisten und das genaue Ziel überprüfen, bevor du die Erstellung erneut ausführst:

dockup services --json

Falls production/api bereits existiert, fahre fort, indem du den Status und die Deployment-Historie prüfst. So verhinderst du, dass ein unklarer Netzwerkstatus zu einem doppelten Service führt. Halte Zugangsdaten für das Repository außerhalb von Source Control und Command-Output.

Wie wählt Dockup zwischen Nixpacks und Dockerfile?

Wenn das Repository ein Dockerfile enthält, verwendet Dockup dieses. Andernfalls erkennt Nixpacks die Anwendung und erstellt automatisch einen Build. Dadurch ist die explizite Container-Definition im Repository maßgeblich.

Nixpacks ist eine gute erste Wahl, wenn die Anwendung gängigen Konventionen ihres Ökosystems folgt und keine Anpassungen auf Betriebssystemebene benötigt. Ein Dockerfile ist sinnvoll, wenn du ein bestimmtes Base-Image, Systempakete, einen Multi-Stage-Build, einen benutzerdefinierten Runtime-User oder exakt definierte Copy-Grenzen benötigst.

Du musst kein leeres Dockerfile hinzufügen, nur um „production-ready“ zu wirken. Ein fehlerhaftes Dockerfile kann weniger reproduzierbar sein als ein konventioneller automatischer Build. Verwende den Entscheidungsprozess in Nixpacks vs Dockerfile.

Überprüfe den Service nach der Erstellung:

dockup info production/api --json

Die Antwort enthält Repository-URL, Branch, Deployment-Typ, Port, Build- und Start-Einstellungen, Environment-Keys, Custom Domains und Daten zum neuesten Deployment.

Wenn die erkannten Befehle überschrieben werden müssen, verwende dokumentierte Einstellungen:

dockup set production/api \
  --build "npm ci && npm run build" \
  --start "npm start" \
  --port 3000 \
  --json

Die Einstellungen werden beim nächsten Deployment angewendet.

Wie konfiguriert man Production-Umgebung und Health?

Füge normale Werte und Secrets getrennt hinzu:

dockup env set NODE_ENV=production \
  -s production/api \
  --json

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

Secret-Werte werden bei der Auflistung der Umgebung maskiert. Sie können gesetzt oder ersetzt werden, der gespeicherte Wert wird jedoch nicht zurückgegeben.

Änderungen an der Umgebung erfordern ein erneutes Deployment, da der laufende Prozess nachträglich keine neue Umgebung erhalten kann. Der vollständige Lebenszyklus wird unter Environment-Variablen und Secrets erklärt.

Konfiguriere ein Health Gate, das die Readiness abbildet:

dockup health production/api \
  --path /healthz \
  --interval 5 \
  --timeout 3 \
  --retries 5 \
  --json

Dockup verwendet einen Blue-Green-Flow ohne Downtime und leitet erst dann Traffic an das neue Deployment weiter, wenn die Readiness erfolgreich ist. Wenn kein HTTP-Pfad konfiguriert ist, kann das Gate auf die Readiness des TCP-Ports zurückfallen.

Eine Health-Route sollte prüfen, ob der Anwendungsprozess bereit ist, Requests zu verarbeiten. Vermeide destruktive Prüfungen oder aufwendige vollständige Systemtests. Tiefe Dependency-Checks können zu falschen Ausfällen führen, wenn ein optionaler Service beeinträchtigt ist.

Wie deployed, überwacht und verifiziert man eine Production-Umgebung?

Löse das Release aus und warte auf einen finalen Status:

dockup deploy production/api --wait --json

Das Standard-Timeout beträgt 900 Sekunden. Exit 0 bedeutet Erfolg. deploy_failed und deploy_timeout liefern Ergebnisse ungleich null, sodass Shell-Skripte und CI-Systeme korrekt stoppen.

Um den Build als NDJSON zu verfolgen:

dockup logs production/api --build -f --json

Der Stream endet bei Erfolg oder Fehler. Wenn der Build erfolgreich ist, der Container aber abstürzt, prüfe die Runtime-Logs:

dockup logs production/api --json

Nach einem erfolgreichen Release solltest du den Plattformstatus und das öffentliche Verhalten überprüfen:

dockup status production/api --json
dockup uptime production/api --hours 24 --json
dockup security production/api --json

Uptime-Probes laufen jede Minute und melden die durchschnittliche Antwortzeit sowie die p95-Antwortzeit. Der Security-Scan prüft Image-CVEs und die Konfiguration. Ergänze einen anwendungsspezifischen Smoke-Test für den tatsächlichen Business-Endpunkt. Die Plattform-Readiness ist notwendig, aber nicht ausreichend.

Die ausführliche Methode zur Protokollanalyse findest du unter Build- und Runtime-Logs debuggen.

Wie führt man automatische Deployments und Previews ein?

Führe das erste Production-Release manuell und mit ausreichend Beobachtung durch, um jede Grenze zu überprüfen. Sobald Build, Health Gate und Rollback-Weg bekannt sind, aktiviere Deployments bei Pushes:

dockup auto-deploy production/api --on --json

Automatische Deployments sollten einem geschützten Branch und einer Code-Review-Richtlinie folgen. Ein Push löst ein Production-Deployment aus, daher werden Repository-Berechtigungen zu Infrastruktur-Berechtigungen.

Pull-Request- und Branch-Previews stellen isolierte URLs und Umgebungen bereit:

dockup pr-preview production/api --on --json
dockup preview branch feature/login production/api --json

In einem Projekt mit privatem Networking treten Previews dem Projektnetzwerk bei. Sie können dieselbe Production-Datenbank unter <slug>.internal erreichen, aber Dockup erstellt für das Preview automatisch einen schreibgeschützten Datenbankbenutzer. Das Preview kann Daten in Production-Form inspizieren, ohne sie zu verändern.

Dadurch entfallen Datenschutzpflichten nicht. Der Zugriff auf Previews sollte weiterhin beschränkt und auditiert werden und nur dort erfolgen, wo das Lesen von Production-Daten zulässig ist.

Wie rollt man ein fehlerhaftes Deployment zurück?

Sichere vor der Wiederherstellung zunächst die Belege. Lies bei einem Build-Fehler die Build-Logs und bei einem Absturz die Runtime-Logs. Liste anschließend die Deployment-Historie auf:

dockup deployments production/api -n 20 --json

Wähle eine Deployment-ID aus, deren Status und Zeitstempel bekannt sind, und führe sie erneut aus:

dockup rollback <deploymentId> production/api --json

Ein Rollback sollte eine explizite Incident-Maßnahme sein. Dokumentiere die ID des fehlgeschlagenen Deployments, die ausgewählte Recovery-ID, den Grund und die anschließende Fehlerbehebung. Wenn eine Datenbankmigration nicht abwärtskompatibel ist, stellt ein reines Application-Rollback möglicherweise keine Kompatibilität wieder her. Das Migrationsdesign muss daher Bestandteil des Release-Plans sein.

Der Leitfaden für Deployments ohne Downtime erklärt den Traffic-Cutover. Die Dockup CLI-Referenz dokumentiert alle Command-Flags.

Dokumentation für den Abschluss des ersten Deployments

Halte am Ende des Workflows vom Git-Repository in die Produktion Folgendes fest:

• Exaktes project/service-Ziel.
• Repository und Production-Branch.
• Build-Methode: Nixpacks oder Dockerfile.
• Build- und Startbefehle, sofern überschrieben.
• Listening-Port und Health-Pfad.
• Deployment-ID und finaler Status.
• Production-URL und Plan für die Custom Domain.
• Uptime- und Security-Verifizierung.
• Rollback-Deployment-ID oder Auswahlregel.

Dieser Eintrag macht das zweite Deployment zu einem routinemäßigen Vorgang statt zu einer weiteren Entdeckungsreise.

Application State vom Container-Image trennen

Das beschreibbare Dateisystem innerhalb eines Service-Containers sollte als ersetzbar betrachtet werden. Ein neues Deployment erstellt eine neue Version und ein Rollback führt ein älteres Image erneut aus. Dateien, die nur im alten Container geschrieben wurden, sind daher keine dauerhafte Strategie für Datenhaltung.

Verwende Managed Databases für relationale Daten, Dokumentdaten oder Cache-Zustände und binde ein Volume für Dateien ein, die Deployments überdauern müssen. Bestätige die Mount-Pfade vor dem ersten Production-Release. Ein containerisiertes Upload-Verzeichnis, das nie gemountet wurde, kann bis zum nächsten Deployment unauffällig funktionieren – und dann werden die Daten entfernt.

Lies Persistente Volumes und Snapshots, bevor du von Benutzern erzeugte Dateien verschiebst. Für den Datenbankzustand solltest du das datenbankspezifische Backup-System verwenden, statt einen laufenden Volume-Snapshot als transaktionskonsistentes Backup zu behandeln.

Den ersten Monat schätzen, ohne eine fixe Instance-Rechnung zu erfinden

Dockup misst CPU-, RAM- und Festplattenverbrauch pro Minute und zieht die Nutzung vom Plan-Guthaben ab. Der Free-Plan umfasst ein Startguthaben von 10 $ und bis zu drei Deployments. Der empfohlene Pro-Plan kostet 20 $ pro Monat und enthält ein Nutzungsguthaben von 20 $.

Nachdem der Service echten Traffic verarbeitet, prüfe seinen CPU-, RAM- und Festplattenverbrauch in app.dockup.ai. Verwende den beobachteten Verbrauch pro Minute – nicht ein geschätztes Maximum –, um zu entscheiden, ob Service, Datenbank oder persistenter Speicher angepasst werden müssen.

Ein sauberes zweites Deployment verifizieren

Nimm nach dem ersten Release eine harmlose, geprüfte Änderung vor und deploye erneut. So bestätigst du, dass Repository-Verknüpfung, Annahmen zum Build-Cache, Health Gate, Umgebung und Historie als fortlaufender Prozess funktionieren und nicht nur bei einer einmaligen Bereitstellung.

Das Ziel explizit halten

Dokumentiere den finalen String project/service.

Die Release-URL festhalten

Dokumentiere die Production-URL neben der Deployment-ID.

Den nächsten Trigger bestätigen

Dokumentiere, ob zukünftige Releases manuell erfolgen oder optional Deploy-on-Push verwenden. So bleiben Repository-Berechtigungen, Branch-Schutz und Production-Erwartungen auch nach dem ersten Deployment aufeinander abgestimmt.

Mit einem verifizierbaren Deployment starten

Wähle ein kleines Repository mit einem klaren Startbefehl und einer Health-Route. Dokumentiere nach dem ersten erfolgreichen Release das exakte Ziel und die Rollback-ID.

Jetzt kostenlos auf app.dockup.ai starten. Der Free-Plan kostet 0 $ pro Monat, enthält ein Startguthaben von 10 $ und unterstützt einen Workspace, drei Datenbanken und drei Deployments.

FAQ

Kann Dockup ein Repository ohne Dockerfile deployen?

Ja. Wenn kein Dockerfile vorhanden ist, verwendet Dockup Nixpacks, um die Anwendung automatisch zu erkennen und zu bauen.

Was bewirkt dockup create --link?

Der Befehl schreibt einen .dockup-Link in das aktuelle Verzeichnis, sodass spätere Befehle das zugehörige Projekt-/Service-Ziel auflösen können.

Warum sollte das erste Deployment --wait verwenden?

Dadurch bleibt der Befehl verbunden, bis das Deployment Erfolg, Fehler oder Timeout erreicht, und liefert einen Exit-Code zurück, der das finale Ergebnis korrekt abbildet.

Werden Änderungen an Environment-Variablen sofort angewendet?

Nein. Sie werden beim nächsten Deployment auf einen neuen Container angewendet. Nach einer Änderung an der Umgebung musst du den Service daher erneut deployen.

Wie rollt Dockup eine Anwendung zurück?

Liste die Deployment-Historie auf, ermittle die bekannte ID eines vorherigen Deployments und verwende dockup rollback mit dieser ID und dem exakten Service-Ziel.