Skip to content

Funktionsweise

Ihre Anwendung vorbereiten

  1. Lesen Sie den Port aus process.env.PORT

    Legen Sie den Port nicht im Code fest. Lauschen Sie auf 0.0.0.0, niemals auf localhost. Wenn ignoriert: Der Router liefert an den deklarierten Port, und niemand antwortet. Besucher erhalten einen 502, obwohl der Container gesund ist.

  2. Migrationen beim Start ausführen, nicht beim Build

    Ein migrate deploy vor dem Start des Servers. Während das Image gebaut wird, gibt es keine Datenbank, mit der man sich verbinden könnte. Wenn ignoriert: Die Datenbank bleibt ohne Tabellen, und die App liefert bei der ersten Abfrage einen Fehler. Das war der häufigste Fehler bei echten Migrationen.

  3. Bei fehlgeschlagener Migration laut scheitern

    Schlägt migrate fehl, muss der Prozess mit der Meldung im Log beendet werden — und nicht trotzdem starten. Wenn ignoriert: Die App bleibt online und liefert Fehler, das Dashboard zeigt Grün, und niemand merkt es, bis sich ein Kunde beschwert.

  4. NEXT_PUBLIC_*-Variablen sind Build-Argumente

    In Next.js werden sie beim Build in das Bundle geschrieben. Deklarieren Sie jede als ARG und übernehmen Sie sie vor der Build-Zeile als ENV. Wenn ignoriert: Der Entwicklungswert bleibt für immer eingebettet. Die Produktionsseite ruft weiterhin localhost auf.

  5. Nichts Wichtiges auf der Container-Festplatte

    Uploads, Bilder, Anhänge: in den S3-Speicher schicken. Die Container-Festplatte verschwindet, wenn die Kopie neu erstellt wird. Wenn ignoriert: Die Dateien verschwinden bei der nächsten Bereitstellung, ohne Warnung und ohne Möglichkeit, sie wiederherzustellen.

  6. Zustand nicht nur im Prozessspeicher halten

    Sitzungen, Warteschlangen, gemeinsamer Cache: in die Datenbank oder in Redis. Mit mehr als einer Kopie hat jeder Prozess seinen eigenen Speicher. Wenn ignoriert: Nutzer verlieren ihre Sitzung, sobald eine Anfrage bei einer anderen Kopie landet, und Schreibvorgänge verschwinden ohne Fehlermeldung.

  7. Ein eingebauter Scheduler verlangt eine einzige Kopie

    Wenn die App einen internen Cron hat, sagen Sie das der Person, die bereitstellt. Die Alternative ist, die Aufgabe in einen eigenen Dienst auszulagern. Wenn ignoriert: Doppelte Abbuchungen, doppelt versendete Nachrichten, versehentlich gesperrte Kunden.

  8. Auf / etwas antworten

    Jede Antwort unter 500 genügt — auch eine Weiterleitung zum Login. Daran erkennt die Plattform, dass die App läuft. Wenn ignoriert: Die App gilt als ausgefallen, und der Eigentümer erhält eine Ausfallmeldung für einen Ausfall, den es nicht gibt.

  9. Logs auf stdout, nicht in eine Datei

    Schreiben Sie in die Standardausgabe. Öffnen Sie keine Logdatei im Container. Wenn ignoriert: Das Log steckt auf einer Festplatte fest, die niemand erreicht — genau dann, wenn Sie es brauchen.

  10. Jedes Geheimnis kommt aus der Umgebung

    API-Schlüssel, Token-Geheimnisse, Zugangsdaten Dritter: nur aus Umgebungsvariablen. Niemals committen, niemals mit einem funktionierenden Standardwert. Wenn ignoriert: Das Geheimnis gelangt ins Repository und funktioniert für jeden, der den Code klont.

  11. Monorepo: ein Dienst pro Programm, im selben Projekt

    Website und API aus demselben Repository werden zwei Dienste desselben Projekts, jeder mit eigenem Dockerfile und Port. Legen Sie keine zwei Projekte an. Wenn ignoriert: Bei zwei Projekten müssen Geheimnisse von Hand kopiert werden — und an dem Tag, an dem eines geändert wird und das andere nicht, wird das Token nicht mehr akzeptiert und niemand versteht, warum.

  12. Dockerfile: Pfad angeben, Kontext im Stammverzeichnis lassen

    Geben Sie im Monorepo den vollständigen Pfad zum Dockerfile des Dienstes an. Der Kontext bleibt im Stammverzeichnis, damit die gemeinsame Lockfile gefunden wird. Wenn ignoriert: Der Build bricht mit „open Dockerfile: no such file or directory“ ab, obwohl das Repository ein Dockerfile hat.

Ihre Anwendung vorbereiten · Devora Cloud · Devora Cloud