Despliega Python en Nodion

Despliega Python paso a paso

1. Haz commit de un solo archivo de dependencias Nodion elige el instalador según el primer archivo que encuentra: poetry.lock (Poetry), Pipfile.lock (Pipenv), requirements.txt (pip) y, por último, un pyproject.toml sin otro archivo de instalación, que se instala con pip install . (o con Poetry si tiene una sección [tool.poetry]). Un uv.lock se ignora, y un Pipfile sin su lockfile no instala nada.
2. Fija la versión de Python Nodion lee .python-version, después runtime.txt y después requires-python en pyproject.toml; si no hay ninguno, obtienes la 3.13. Un rango como requires-python = ">=3.10" selecciona la versión publicada más reciente, ahora mismo la 3.15, así que fija la versión con la que haces tus pruebas. .python-version

   3.13

3. Conoce el comando de inicio por defecto Nodion revisa tus dependencias en este orden: Django (con manage.py) arranca con Gunicorn, FastAPI o Starlette con Uvicorn y Flask con Gunicorn. Nodion no añade el servidor por ti, así que inclúyelo en tus dependencias. Sin framework, Nodion ejecuta python app.py o python main.py, y ese script tiene que escuchar en 0.0.0.0 y en el PORT que define Nodion.
4. Arranca todo lo demás con un Procfile Una línea web: sustituye al comando por defecto. Sin Django, FastAPI, Flask, app.py ni main.py, el Procfile tiene que definir un proceso, web: o worker:; si no, la build se detiene con un error que indica qué falta. Una línea release: se ejecuta una vez por build antes de que arranque la nueva versión: es el sitio para las migraciones. Procfile

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

5. Crea la app y haz push Crea una aplicación desde tu repositorio de GitHub, GitLab, Bitbucket o Gitea en la región EU Central. Las variables que lee tu build necesitan la opción Build en la pestaña Environment; todas las demás, y las bases de datos vinculadas como DATABASE_URL, solo existen en runtime. A partir de ahí, cada push genera una nueva release.

A tener en cuenta

• Workers y otros tipos de procesoUna línea worker: no arranca nada por sí sola: en la pestaña Processes, añade un proceso con el mismo nombre y sin puerto. Mantén a su lado una línea web: explícita, porque sin ella la primera entrada del Procfile que no sea release: pasa a ser el comando por defecto. Una app que solo tiene workers, como un bot, pone en cambio web a 0 instancias.
• La detección también lee los lockfilesNodion busca Django, FastAPI y Flask en requirements.txt, Pipfile, pyproject.toml, poetry.lock y Pipfile.lock. Los lockfiles también incluyen las dependencias indirectas, así que una librería que incluye FastAPI como dependencia, como Gradio, puede activar el comando por defecto de FastAPI. Una línea web: lo resuelve.
• Proyectos con uvEl lockfile de uv no se lee. Exporta tus versiones fijadas a un requirements.txt, por ejemplo con uv export --no-emit-project -o requirements.txt, y haz commit de él; si no, Nodion instala desde pyproject.toml sin lockfile.

Lo que Nodion gestiona por ti

• Despliegues sin downtime Haz push a tu rama y Nodion construye una nueva release. El tráfico pasa a las nuevas instancias cuando superan el health check; si una release falla, la que está en marcha sigue activa. En cambio, las apps con un volumen local se reinician porque el disco pertenece a una sola instancia.
• Bases de datos junto a la app PostgreSQL, pgvector, MySQL, Valkey y ClickHouse gestionados en la misma región. Al vincular una base de datos, sus datos de conexión llegan como DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Previews por pull request Activa las previews: cada pull request de tu repositorio tendrá su propia app, con URL y bases de datos nuevas y vacías. Puedes crearla automáticamente o a mano. Se omiten las pull requests de forks y bots.
• Workers, cron jobs y escalado Ejecuta workers como procesos adicionales de la misma app, programa tareas en la pestaña Cron y escala cada proceso hasta 16 instancias.
• Paso de release Con buildpacks, una línea release: del Procfile se ejecuta con cada nueva build. Las apps con Dockerfile, así como los redeploys o rollbacks a una imagen anterior, usan un comando de release definido en la propia app, que además tiene prioridad sobre la línea del Procfile. En los sitios estáticos, el paso de release se ejecuta en una imagen que solo contiene los archivos generados por la build.
• Logs y métricas Logs de build, release y runtime, además de métricas de CPU, memoria, disco y red de cada instancia, en el dashboard.
• Dominios y HTTPS Un nombre de host predeterminado con HTTPS desde el primer despliegue; tus propios dominios reciben certificados automáticamente.

Para seguir leyendo

• Por qué hemos creado buildpacks propios sobre Ubuntu 26.04 Nuestros buildpacks siguen la especificación de Cloud Native Buildpacks, pero el stack, los buildpacks de lenguaje y las versiones de runtime son nuestros. Te contamos por qué.
• Cloud Native Buildpacks: qué son y cómo funcionan Los buildpacks convierten tu código fuente en una imagen de contenedor sin Dockerfile. Te explicamos qué son y cómo funcionan.

Python en Nodion: preguntas y respuestas