Deploy Python on Nodion

Deploy Python step by step

1. Commit one dependency file Nodion picks the installer by the first file it finds: poetry.lock (Poetry), Pipfile.lock (Pipenv), requirements.txt (pip), then a pyproject.toml on its own, installed with pip install . (or Poetry if it has a [tool.poetry] section). A uv.lock is ignored, and a Pipfile without its lock file installs nothing.
2. Pin the Python version Nodion reads .python-version, then runtime.txt, then requires-python in pyproject.toml; without any of them you get 3.13. A range such as requires-python = ">=3.10" resolves to the newest published release, currently 3.15, so pin the version you test with. .python-version

   3.13

3. Know the default start command Nodion checks your dependencies in this order: Django (with manage.py) starts with Gunicorn, FastAPI or Starlette with Uvicorn, Flask with Gunicorn. The server is not added for you, so list it in your dependencies. Without a framework, Nodion runs python app.py or python main.py, and that script has to listen on 0.0.0.0 and the PORT Nodion sets.
4. Start everything else with a Procfile A web: line replaces the default. Without Django, FastAPI, Flask, app.py or main.py, the Procfile must define a process, web: or worker:; otherwise the build stops with an error that says what is missing. A release: line runs once per build before the new version starts, the place for migrations. Procfile

   web: gunicorn myapp.wsgi --bind 0.0.0.0:$PORT
   release: alembic upgrade head

5. Create the app and push Create an application from your GitHub, GitLab, Bitbucket or Gitea repository in the region EU Central. Variables your build reads need the Build flag on the Environment tab; all others, and attached databases such as DATABASE_URL, exist only at runtime. From then on, every push builds a new release.

Good to know

• Workers and other process typesA worker: line does not start anything on its own: add a process with the same name and no port on the Processes tab. Keep an explicit web: line next to it, because without one the first Procfile entry other than release: becomes the default command. A worker-only app such as a bot sets web to 0 instances instead.
• Detection reads lock files tooNodion looks for Django, FastAPI and Flask in requirements.txt, Pipfile, pyproject.toml, poetry.lock and Pipfile.lock. Lock files also list indirect dependencies, so a library that pulls in FastAPI, such as Gradio, can trigger the FastAPI default. A web: line settles it.
• uv projectsuv's lock file is not read. Export your locked versions to a requirements.txt, for example with uv export --no-emit-project -o requirements.txt, and commit it; otherwise Nodion installs from pyproject.toml without a lock.

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

• Why We Built Our Own Buildpacks on Ubuntu 26.04 Our buildpacks follow the Cloud Native Buildpacks spec, but the stack, the language packs and the runtime versions are ours. Here is why.
• Cloud Native Buildpacks Explained Buildpacks turn your source code into a container image without a Dockerfile. What they are, and how they work.

Python on Nodion: questions and answers