Docker auf Nodion deployen

Docker Schritt für Schritt deployen

1. Auf 0.0.0.0 lauschen und den Port per EXPOSE angeben Nodion baut dein Dockerfile so, wie es ist, und startet CMD oder ENTRYPOINT des Images. PORT setzt Nodion nicht: Dein Server lauscht auf allen Interfaces auf einem festen Port, und EXPOSE sagt dem Formular, welcher das ist. Multi-Stage-Builds funktionieren; es läuft die letzte Stage. Dockerfile

   FROM python:3.13-slim
   WORKDIR /app
   COPY requirements.txt .
   RUN pip install --no-cache-dir -r requirements.txt
   COPY . .
   EXPOSE 8000
   CMD ["gunicorn", "app:app", "--bind", "0.0.0.0:8000"]

2. App anlegen Lege im Dashboard eine Application aus deinem GitHub-, GitLab-, Bitbucket- oder Gitea-Repository an, wähle Branch und Region EU Central. Liegt ein Dockerfile im Repository, wählt das Formular die Strategie Dockerfile und übernimmt den Port aus EXPOSE. In einem Monorepo setzt du das Base Directory (den Build-Kontext) und den Namen des Dockerfiles.
3. Build-Werte als Build Args übergeben Variablen mit dem Häkchen Build auf dem Tab Environment kommen als Docker Build Args in den Build; deklarier sie mit ARG in der Stage, die sie liest. Alle anderen Variablen und angehängte Datenbanken wie DATABASE_URL gibt es erst, wenn der Container läuft. Dockerfile

   FROM node:24-slim AS build
   ARG VITE_API_URL
   WORKDIR /app
   COPY . .
   RUN npm ci && npm run build

4. Migrationen einmal pro Deploy ausführen Am besten trägst du deinen Migrationsbefehl als Release Command der App ein: Er läuft bei jedem Deploy einmal aus dem neuen Image, bevor die neue Version startet, und scheitert er, stoppt der Deploy und die laufende Version bleibt live. Im Entrypoint oder Startbefehl geht es auch, dann migriert aber jede Instanz bei jedem Start. Den Release Command setzt du über das API-Feld release_command; im Dashboard erscheint das Feld in den App-Einstellungen derzeit erst, wenn Preview-Environments eingeschaltet sind.
5. Pushen und deployen Jeder Push auf den Branch baut ein neues Image in Frankfurt. Der Traffic wechselt, sobald der Web-Prozess auf dem Health-Check-Pfad (Standard /) mit 2xx oder 3xx antwortet. Ein Docker-HEALTHCHECK im Image wird ignoriert.

Gut zu wissen

• Keine PORT-VariableLiest dein Server PORT, setz die Variable selbst, mit ENV PORT=8000 im Dockerfile oder auf dem Tab Environment, und halte sie gleich dem Port des Web-Prozesses.
• Fertige ImagesOhne Git-Build deployst du ein Image aus Docker Hub, der GitHub Container Registry, der Nodion Registry oder einer privaten Registry, deren Zugangsdaten du in Nodion hinterlegt hast. Es gelten dieselben Regeln für Port und Health Check.
• USER, .dockerignore und der CommitDer USER des Images gilt, eine .dockerignore im Build-Kontext wird beachtet, und .git geht nie in den Build. Mit ARG NODION_GIT_SHA schreibst du den Commit-Hash ins Image.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Dockerfile vs Buildpacks: was solltest du nutzen? Beide machen aus deinem Code ein Container-Image. Der Unterschied ist, wer die Build-Schritte schreibt, und das entscheidet über Kontrolle, Wartung und Security-Updates.
• Railway-Alternativen in Europa: 5 Optionen im Vergleich Container und Datenbanken nach Verbrauch, mit Unternehmen oder Region in der EU: fünf Railway-Alternativen nach Abrechnung, Datenbanken und Standort.

Docker auf Nodion: Fragen und Antworten