Deploy Docker op Nodion

Docker stap voor stap deployen

1. Luister op 0.0.0.0 en geef de poort op met EXPOSE Nodion bouwt je Dockerfile ongewijzigd en start de CMD of het ENTRYPOINT van de image. PORT stelt Nodion niet in: je server luistert op alle interfaces op een vaste poort, en EXPOSE vertelt het aanmaakformulier welke poort dat is. Multi-stage builds werken; alleen de laatste stage draait. 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. Maak de app aan Maak in het dashboard een applicatie aan vanuit je GitHub-, GitLab-, Bitbucket- of Gitea-repository en kies de branch en de regio EU Central. Staat er een Dockerfile in de repository, dan selecteert het formulier vooraf de Dockerfile-strategie en neemt het de poort over uit EXPOSE. Stel in een monorepo de Base directory (de buildcontext) en de naam van de Dockerfile in.
3. Geef buildwaarden door als build args Variabelen met de optie Build op het tabblad Environment komen als Docker build args in de build terecht, dus declareer ze met ARG in de stage die ze leest. Alle andere variabelen, en gekoppelde databases zoals DATABASE_URL, bestaan pas als de container draait. Dockerfile

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

4. Draai migraties één keer per deployment Stel je migratiecommando in als release command van de app: het draait bij elke deployment één keer vanuit de nieuwe image, voordat de nieuwe versie start, en als het mislukt, stopt de deployment en blijft de draaiende versie live. Je stelt het in met het API-veld release_command; in het dashboard verschijnt het veld voorlopig pas in de app-instellingen als previewomgevingen aanstaan. Migraties draaien in het entrypoint of het startcommando kan ook, maar dan draait elke instantie ze bij elke start.
5. Push om te deployen Elke push naar de branch bouwt een nieuwe image in Frankfurt. Het verkeer gaat over naar die image zodra het webproces op het pad van de health check (standaard /) antwoordt met 2xx of 3xx. Een Docker-HEALTHCHECK in de image wordt genegeerd.

Goed om te weten

• Geen PORT-variabeleLeest je server PORT, stel de variabele dan zelf in, met ENV PORT=8000 in de Dockerfile of als variabele op het tabblad Environment, en houd hem gelijk aan de poort van het webproces.
• Kant-en-klare imagesSla de Git-build over en deploy een image uit Docker Hub, de GitHub Container Registry, de Nodion-registry of een private registry waarvan je de inloggegevens in Nodion hebt opgeslagen. Voor poort en health check gelden dezelfde regels.
• USER, .dockerignore en de commitDe USER van de image wordt gerespecteerd, een .dockerignore in de buildcontext wordt toegepast en .git gaat nooit mee naar de build. Declareer ARG NODION_GIT_SHA om de commithash in de image te schrijven.

Wat Nodion voor je regelt

• Deploys zonder downtime Push naar je branch en Nodion bouwt een nieuwe release. Het verkeer schakelt over zodra de nieuwe instanties hun health check doorstaan; een mislukte release laat de draaiende versie staan. Apps met een lokaal volume herstarten in plaats daarvan, omdat de schijf bij één instantie hoort.
• Databases naast de app Managed PostgreSQL, pgvector, MySQL, Valkey en ClickHouse in dezelfde regio. Gekoppelde databases komen binnen als DATABASE_URL, REDIS_URL of CLICKHOUSE_URL.
• Previews per pull request Zet previews aan en pull requests uit je repository krijgen een eigen app met een eigen URL en nieuwe, lege databases, automatisch of handmatig aangemaakt. Forks en pull requests van bots worden overgeslagen.
• Workers, cronjobs en schalen Draai workers als extra processen van dezelfde app, plan jobs op het tabblad Cron en schaal elk proces naar maximaal 16 instanties.
• Releasestap Met buildpacks draait een release:-regel in het Procfile bij elke nieuwe build. Dockerfile-apps, en redeploys of rollbacks naar een eerdere image, gebruiken een releasecommando dat op de app zelf is ingesteld en dat ook voorrang heeft op de Procfile-regel. Bij statische sites draait een releasestap in een image die alleen de gebouwde bestanden bevat.
• Logs en metrics Build-, release- en runtimelogs plus metrics voor CPU, geheugen, schijf en netwerk van elke instantie in het dashboard.
• Domeinen en HTTPS Een standaardhostnaam met HTTPS vanaf de eerste deploy; je eigen domeinen krijgen automatisch certificaten.

Verder lezen

• Dockerfile vs buildpacks: welke moet je gebruiken? Allebei maken ze van je code een containerimage. Het verschil is wie de buildstappen schrijft, en dat bepaalt controle, onderhoud en beveiligingsupdates.
• Alternatieven voor Railway in Europa: 5 opties vergeleken Containers en databases op basis van verbruik, bij een bedrijf in de EU of in een EU-regio: vijf alternatieven voor Railway vergeleken op facturatie, databases en locatie.

Docker op Nodion: vragen en antwoorden