Fai il deploy di Python su Nodion

Deploy di Python passo dopo passo

1. Fai il commit di un solo file delle dipendenze Nodion sceglie l'installer in base al primo file che trova: poetry.lock (Poetry), Pipfile.lock (Pipenv), requirements.txt (pip), poi un pyproject.toml da solo, installato con pip install . (o con Poetry se ha una sezione [tool.poetry]). Un uv.lock viene ignorato e un Pipfile senza il suo lock file non installa nulla.
2. Fissa la versione di Python Nodion legge .python-version, poi runtime.txt, poi requires-python in pyproject.toml; se non trova nessuna di queste indicazioni, usa la 3.13. Un intervallo come requires-python = ">=3.10" seleziona la release più recente pubblicata, al momento la 3.15, quindi fissa la versione con cui fai i test. .python-version

   3.13

3. Conosci il comando di avvio predefinito Nodion controlla le tue dipendenze in quest'ordine: Django (con manage.py) parte con Gunicorn, FastAPI o Starlette con Uvicorn, Flask con Gunicorn. Nodion non installa il server, quindi aggiungilo alle dipendenze. Senza un framework, Nodion esegue python app.py o python main.py, e quello script deve restare in ascolto su 0.0.0.0 e sulla porta PORT impostata da Nodion.
4. Avvia tutto il resto con un Procfile Una riga web: sostituisce il comando predefinito. Senza Django, FastAPI, Flask, app.py o main.py, il Procfile deve definire un processo, web: o worker:; altrimenti la build si ferma con un errore che indica cosa manca. Una riga release: viene eseguita una volta per ogni build, prima che parta la nuova versione: è il posto giusto per le migrazioni. Procfile

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

5. Crea l'app e fai push Crea un'applicazione dal tuo repository GitHub, GitLab, Bitbucket o Gitea nella regione EU Central. Le variabili lette dalla build devono avere l'opzione Build nella scheda Environment; tutte le altre, e i database collegati come DATABASE_URL, esistono solo a runtime. Da quel momento ogni push crea una nuova release.

Da sapere

• Worker e altri tipi di processoUna riga worker: da sola non avvia nulla: nella scheda Processes aggiungi un processo con lo stesso nome e senza porta. Tieni accanto una riga web: esplicita, perché senza di essa la prima voce del Procfile diversa da release: diventa il comando predefinito. Un'app fatta solo di worker, come un bot, imposta invece web a 0 istanze.
• Il rilevamento legge anche i lock fileNodion cerca Django, FastAPI e Flask in requirements.txt, Pipfile, pyproject.toml, poetry.lock e Pipfile.lock. I lock file elencano anche le dipendenze indirette, quindi una libreria che si porta dietro FastAPI, come Gradio, può attivare il comando predefinito di FastAPI. Una riga web: risolve la questione.
• Progetti uvIl lock file di uv non viene letto. Esporta le versioni bloccate in un requirements.txt, per esempio con uv export --no-emit-project -o requirements.txt, e fanne il commit; altrimenti Nodion installa da pyproject.toml senza lock.

Cosa gestisce Nodion per te

• Deploy senza downtime Fai push sul tuo branch e Nodion crea una nuova release. Il traffico passa alle nuove istanze solo quando superano l'health check; una release fallita lascia attiva quella in esecuzione. Le app con un volume locale invece si riavviano, perché il disco appartiene a una sola istanza.
• Database accanto all'app PostgreSQL, pgvector, MySQL, Valkey e ClickHouse gestiti, nella stessa regione. I database collegati arrivano come DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Anteprime per ogni pull request Attiva le anteprime: ogni pull request del tuo repository riceve un'app dedicata, con un proprio URL e database nuovi e vuoti, creata automaticamente o manualmente. Le pull request dai fork e quelle dei bot vengono ignorate.
• Worker, cron job e scalabilità Esegui i worker come processi aggiuntivi della stessa app, pianifica i job nella scheda Cron e scala ogni processo fino a 16 istanze.
• Fase di release Con i buildpack, la riga release: del Procfile viene eseguita a ogni nuova build. Le app con Dockerfile, così come i redeploy e i rollback a un'immagine precedente, usano un comando di release impostato sull'app stessa, che ha anche la precedenza sulla riga del Procfile. Nei siti statici, la fase di release gira in un'immagine che contiene solo i file generati dalla build.
• Log e metriche Nella dashboard trovi log di build, release e runtime, oltre alle metriche di CPU, memoria, disco e rete per ogni istanza.
• Domini e HTTPS Un hostname predefinito con HTTPS dal primo deploy; i tuoi domini ricevono i certificati in automatico.

Per approfondire

• Perché abbiamo creato i nostri buildpack su Ubuntu 26.04 I nostri buildpack seguono la specifica Cloud Native Buildpacks, ma lo stack, i buildpack dei linguaggi e le versioni dei runtime sono nostri. Ecco perché.
• Cloud Native Buildpacks: cosa sono e come funzionano I buildpack trasformano il tuo codice sorgente in un'immagine container senza Dockerfile. Cosa sono e come funzionano.

Python su Nodion: domande e risposte