Python auf Nodion deployen

Python Schritt für Schritt deployen

1. Eine Dependency-Datei committen Nodion wählt den Installer nach der ersten Datei, die es findet: poetry.lock (Poetry), Pipfile.lock (Pipenv), requirements.txt (pip), danach eine einzelne pyproject.toml, installiert mit pip install . (oder mit Poetry, wenn sie einen Abschnitt [tool.poetry] hat). Eine uv.lock wird ignoriert, und eine Pipfile ohne Lock-Datei installiert gar nichts.
2. Python-Version pinnen Nodion liest .python-version, dann runtime.txt, dann requires-python in der pyproject.toml; ohne diese Angaben bekommst du 3.13. Ein Bereich wie requires-python = ">=3.10" landet beim neuesten veröffentlichten Release, aktuell 3.15. Pinne also die Version, mit der du testest. .python-version

   3.13

3. Den Standard-Startbefehl kennen Nodion prüft deine Dependencies in dieser Reihenfolge: Django (mit manage.py) startet mit Gunicorn, FastAPI oder Starlette mit Uvicorn, Flask mit Gunicorn. Den Server ergänzt Nodion nicht, er gehört in deine Dependencies. Ohne Framework startet Nodion python app.py oder python main.py, und dieses Skript muss auf 0.0.0.0 und dem PORT lauschen, den Nodion setzt.
4. Alles andere per Procfile starten Eine web:-Zeile ersetzt den Default. Ohne Django, FastAPI, Flask, app.py oder main.py muss die Procfile einen Prozess festlegen, web: oder worker:; sonst bricht der Build mit einer Fehlermeldung ab, die sagt, was fehlt. Eine release:-Zeile läuft bei jedem Build einmal, bevor die neue Version startet, der richtige Ort für Migrationen. Procfile

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

5. App anlegen und pushen Lege eine Application aus deinem GitHub-, GitLab-, Bitbucket- oder Gitea-Repository in der Region EU Central an. Variablen, die dein Build liest, brauchen auf dem Tab Environment das Häkchen Build; alle anderen und angehängte Datenbanken wie DATABASE_URL gibt es nur zur Laufzeit. Danach baut jeder Push ein neues Release.

Gut zu wissen

• Worker und weitere ProzesstypenEine worker:-Zeile startet allein noch nichts: Leg auf dem Tab Processes einen Prozess mit demselben Namen und ohne Port an. Behalte daneben eine ausdrückliche web:-Zeile, denn ohne sie wird der erste Procfile-Eintrag außer release: zum Standardbefehl. Eine reine Worker-App wie ein Bot setzt stattdessen web auf 0 Instanzen.
• Die Erkennung liest auch Lock-DateienNodion sucht Django, FastAPI und Flask in requirements.txt, Pipfile, pyproject.toml, poetry.lock und Pipfile.lock. Lock-Dateien führen auch indirekte Dependencies auf; eine Bibliothek, die FastAPI mitbringt, etwa Gradio, kann also den FastAPI-Default auslösen. Eine web:-Zeile schafft Klarheit.
• uv-ProjekteDie Lock-Datei von uv wird nicht gelesen. Exportiere deine gelockten Versionen in eine requirements.txt, etwa mit uv export --no-emit-project -o requirements.txt, und committe sie; sonst installiert Nodion aus der pyproject.toml ohne Lock.

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

• Warum wir eigene Buildpacks auf Ubuntu 26.04 gebaut haben Unsere Buildpacks folgen der Cloud-Native-Buildpacks-Spezifikation, aber Stack, Language Packs und Runtime-Versionen sind unsere. Darum.
• Cloud Native Buildpacks erklärt Buildpacks machen aus deinem Quellcode ein Container-Image ohne Dockerfile. Was sie sind und wie sie funktionieren.

Python auf Nodion: Fragen und Antworten