Faça deploy de Python na Nodion

Faça deploy de Python passo a passo

1. Faça commit de um único ficheiro de dependências A Nodion escolhe o instalador pelo primeiro ficheiro que encontra: poetry.lock (Poetry), Pipfile.lock (Pipenv), requirements.txt (pip) e, por fim, um pyproject.toml sozinho, instalado com pip install . (ou com o Poetry, se tiver uma secção [tool.poetry]). Um uv.lock é ignorado, e um Pipfile sem o respetivo lockfile não instala nada.
2. Fixe a versão de Python A Nodion lê .python-version, depois runtime.txt e depois requires-python em pyproject.toml; se não existir nenhum deles, é usada a 3.13. Um intervalo como requires-python = ">=3.10" resolve-se para a versão publicada mais recente, atualmente a 3.15, por isso fixe a versão com que faz os testes. .python-version

   3.13

3. Conheça o comando de arranque por omissão A Nodion verifica as suas dependências por esta ordem: o Django (com manage.py) arranca com o Gunicorn, o FastAPI ou o Starlette com o Uvicorn, e o Flask com o Gunicorn. O servidor não é adicionado automaticamente, por isso inclua-o nas suas dependências. Sem framework, a Nodion executa python app.py ou python main.py, e esse script tem de escutar em 0.0.0.0 e na porta PORT definida pela Nodion.
4. Arranque tudo o resto com um Procfile Uma linha web: substitui o comando por omissão. Sem Django, FastAPI, Flask, app.py nem main.py, o Procfile tem de definir um processo, web: ou worker:; caso contrário, o build é interrompido com um erro que indica o que falta. Uma linha release: é executada uma vez por build, antes de a nova versão arrancar: é o sítio certo para as migrações. Procfile

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

5. Crie a aplicação e faça push Crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea na região EU Central. As variáveis que o seu build lê precisam da opção Build no separador Environment; todas as outras, e as bases de dados associadas como DATABASE_URL, só existem em runtime. A partir daí, cada push faz o build de uma nova release.

A ter em conta

• Workers e outros tipos de processoUma linha worker: não arranca nada por si só: no separador Processes, adicione um processo com o mesmo nome e sem porta. Mantenha ao lado uma linha web: explícita, porque sem ela a primeira entrada do Procfile que não seja release: passa a ser o comando por omissão. Uma aplicação só com workers, como um bot, define antes web com 0 instâncias.
• A deteção também lê os lockfilesA Nodion procura Django, FastAPI e Flask em requirements.txt, Pipfile, pyproject.toml, poetry.lock e Pipfile.lock. Os lockfiles também listam as dependências indiretas, por isso uma biblioteca que traz o FastAPI consigo, como o Gradio, pode ativar o comando por omissão do FastAPI. Uma linha web: resolve a questão.
• Projetos uvO lockfile do uv não é lido. Exporte as versões fixadas para um requirements.txt, por exemplo com uv export --no-emit-project -o requirements.txt, e faça commit desse ficheiro; caso contrário, a Nodion instala a partir do pyproject.toml sem lockfile.

O que a Nodion gere por si

• Deploys sem downtime Faça push para o seu branch e a Nodion cria uma nova release. O tráfego só muda quando as novas instâncias passam no health check; se uma release falhar, a que está em execução mantém-se. Em vez disso, as aplicações com um volume local são reiniciadas, porque o disco pertence a uma única instância.
• Bases de dados junto à aplicação PostgreSQL, pgvector, MySQL, Valkey e ClickHouse geridos, na mesma região. As bases de dados associadas chegam como DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Pré-visualizações por pull request Ative as pré-visualizações e cada pull request do seu repositório passa a ter uma aplicação própria, com URL próprio e bases de dados novas e vazias, criada automática ou manualmente. Os forks e os pull requests de bots são ignorados.
• Workers, cron jobs e escalabilidade Execute workers como processos adicionais da mesma aplicação, agende tarefas no separador Cron e escale cada processo até 16 instâncias.
• Etapa de release Com buildpacks, uma linha release: do Procfile é executada a cada novo build. As aplicações com Dockerfile, bem como os redeploys ou rollbacks para uma imagem anterior, usam um comando de release definido na própria aplicação, que também tem prioridade sobre a linha do Procfile. Nos sites estáticos, a etapa de release é executada numa imagem que contém apenas os ficheiros gerados pelo build.
• Logs e métricas Logs de build, release e runtime, além de métricas de CPU, memória, disco e rede de cada instância, no dashboard.
• Domínios e HTTPS Um hostname atribuído por omissão com HTTPS desde o primeiro deploy; os seus próprios domínios recebem certificados automaticamente.

Para saber mais

• Porque criámos os nossos próprios buildpacks no Ubuntu 26.04 Os nossos buildpacks seguem a especificação Cloud Native Buildpacks, mas a stack, os buildpacks de linguagem e as versões de runtime são nossos. Eis porquê.
• Cloud Native Buildpacks: o que são e como funcionam Os buildpacks transformam o seu código-fonte numa imagem de contentor sem Dockerfile. O que são e como funcionam.

Python na Nodion: perguntas e respostas