Django

• Detectado a partir de requirements.txt, pyproject.toml ou de um manage.py que importa o Django.
• Release: python manage.py migrate --no-input.
• Web: gunicorn na $PORT — defina seu módulo WSGI no comando de start se ele não for wsgi:application.
• Workers: Celery (celery -A <project> worker, com o projeto lido de DJANGO_SETTINGS_MODULE), Celery Beat, RQ, Huey, Dramatiq e Django-Q são oferecidos quando aparecem como dependências.
• Banco de dados: psycopg → Postgres, com DATABASE_URL injetado.

Processos: um codebase, vários papéis

web, worker e um processo agendado beat são a mesma imagem iniciada com um comando diferente — o modelo de processos do 12-factor, e não aplicações separadas para manter sincronizadas entre si. Declare você mesmo em um Procfile:

web: gunicorn myproject.wsgi:application --bind 0.0.0.0:$PORT
worker: celery -A myproject worker --loglevel=info
beat: celery -A myproject beat --loglevel=info

ou pule o Procfile e deixe a detecção oferecer o worker para você, a partir de qualquer biblioteca de jobs presente nas suas dependências. Adicione mais na aba Workers da aplicação, ou escale o que já existe pela CLI:

railyard scale my-app worker=2

Veja Workers e jobs agendados para cron.

Arquivos estáticos

python manage.py collectstatic --noinput roda automaticamente na etapa de build — a mesma convenção usada pelo buildpack Python do Heroku — então WhiteNoise ou qualquer configuração de STATIC_ROOT já funciona, sem precisar de um passo no Dockerfile ou de um hook de pré-deploy. Uma aplicação que não usa django.contrib.staticfiles não é afetada, e uma falha aqui não bloqueia o resto do build. Defina DISABLE_COLLECTSTATIC=1 para desativar.

Configuração e secrets

DATABASE_URL é injetado automaticamente a partir do seu add-on de Postgres; REDIS_URL também é, assim que suas dependências fixarem um cliente Redis (redis, django-redis, rq) — aponte o broker e o result backend do Celery para ele você mesmo. Todo o resto — DJANGO_SETTINGS_MODULE, SECRET_KEY, feature flags — é uma variável de ambiente comum em Variáveis, ou railyard env:set my-app KEY=VALUE pela CLI, então a mesma imagem roda sem alterações do staging até a produção: paridade entre dev e produção, não um branch definido no momento do build. Aponte para um banco de dados ou Redis rodando como serviço próprio no Canvas com ${{redis.RAILYARD_PRIVATE_URL}} — resolvido por ambiente. Veja Variáveis e secrets.

Faça o deploy

• A partir de um repositório: cole a URL do Git, ou escolha pelo seletor depois de conectar o GitHub — o Railyard lê requirements.txt/pyproject.toml, preenche o gunicorn, o comando de release com migrate e DATABASE_URL, e faz deploy a cada push.
• Pela CLI: railyard create my-app https://github.com/me/my-app --addons postgres,redis, ou railyard git:remote && git push railyard main de dentro do repositório.
• Com um clique: adicione o botão de deploy ao seu README, ou publique no catálogo de templates para qualquer pessoa poder lançar com os add-ons e variáveis já preenchidos.