Deploy Docker on Nodion

Deploy Docker step by step

1. Listen on 0.0.0.0 and EXPOSE the port Nodion builds your Dockerfile as it is and starts the image's CMD or ENTRYPOINT. It does not set PORT: your server listens on all interfaces on a fixed port, and EXPOSE tells the create form which one. Multi-stage builds work; the final stage is what runs. 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. Create the app In the dashboard, create an application from your GitHub, GitLab, Bitbucket or Gitea repository, pick the branch and the region EU Central. With a Dockerfile in the repository, the form preselects the Dockerfile strategy and fills in the port from EXPOSE. In a monorepo, set the base directory (the build context) and the Dockerfile name.
3. Pass build-time values as build args Variables with the Build flag on the Environment tab reach the build as Docker build args, so declare them with ARG in the stage that reads them. All other variables, and attached databases such as DATABASE_URL, exist only once the container runs. Dockerfile

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

4. Run migrations once per deploy Set your migration command as the app's release command: it runs once per deploy from the new image, before the new version starts, and if it fails the deploy stops while the running version stays live. Set it with the API field release_command; in the dashboard the field currently shows in the app settings only once preview environments are turned on. Running migrations in the entrypoint or start command works too, but then every instance runs them on every start.
5. Push to deploy Every push to the branch builds a new image in Frankfurt. Traffic moves to it once the web process answers the health check path (default /) with 2xx or 3xx. A Docker HEALTHCHECK in the image is ignored.

Good to know

• No PORT variableIf your server reads PORT, set it yourself, with ENV PORT=8000 in the Dockerfile or as a variable on the Environment tab, and keep it equal to the port of the web process.
• Prebuilt imagesSkip the Git build and deploy an image from Docker Hub, the GitHub Container Registry, the Nodion registry or a private registry whose credentials you saved in Nodion. The same port and health check rules apply.
• USER, .dockerignore and the commitThe image's USER is honored, a .dockerignore in the build context applies, and .git is never sent to the build. Declare ARG NODION_GIT_SHA to write the commit hash into the image.

What Nodion runs for you

• Deploys without downtime Push to your branch and Nodion builds a new release. Traffic switches once the new instances answer their health check; a failed release leaves the running one in place. Apps with a local volume restart instead, because the disk belongs to one instance.
• Databases next to the app Managed PostgreSQL, pgvector, MySQL, Valkey and ClickHouse in the same region. Attached databases arrive as DATABASE_URL, REDIS_URL or CLICKHOUSE_URL.
• Previews per pull request Turn on previews and pull requests from your repository get their own app with its own URL and fresh, empty databases, created automatically or by hand. Forks and bot pull requests are skipped.
• Workers, cron jobs and scaling Run workers as extra processes of the same app, schedule jobs on the Cron tab, and scale every process to up to 16 instances.
• Release step With buildpacks, a Procfile release: line runs with every new build. Dockerfile apps, and redeploys or rollbacks to an earlier image, use a release command set on the app itself, which also takes precedence over the Procfile line. On static sites a release step runs in an image that holds only the built files.
• Logs and metrics Build, release and runtime logs plus CPU, memory, disk and network metrics for every instance in the dashboard.
• Domains and HTTPS A default hostname with HTTPS from the first deploy; your own domains get certificates automatically.

Further reading

• Dockerfile vs Buildpacks: Which One Should You Use? Both turn your code into a container image. What differs is who writes the build steps, and that decides control, maintenance and security updates.
• Railway Alternatives in Europe: 5 Options Compared Containers and databases billed by usage, with a company or region in the EU: five Railway alternatives compared by billing, databases and location.

Docker on Nodion: questions and answers