Django

Django

Despliega Django con Postgres, workers de Celery o RQ, collectstatic y migraciones.

  • Se detecta a partir de requirements.txt, pyproject.toml o un manage.py que importa Django.
  • Release: python manage.py migrate --no-input.
  • Web: gunicorn en $PORT; define tu módulo WSGI en el comando de inicio si no es wsgi:application.
  • Workers: se ofrecen Celery (celery -A <project> worker, el proyecto se lee de DJANGO_SETTINGS_MODULE), Celery Beat, RQ, Huey, Dramatiq y Django-Q cuando son dependencias.
  • Base de datos: psycopg → Postgres, con DATABASE_URL inyectada.

Procesos: un mismo código, varios roles

web, worker y un proceso beat programado son la misma imagen iniciada con un comando distinto: el modelo de procesos de 12-factor, no apps separadas que haya que mantener sincronizadas entre sí. Decláralos tú mismo en un 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

o salta el Procfile y deja que la detección te ofrezca el worker según la librería de trabajos en segundo plano que tengas en tus dependencias. Agrega más desde la pestaña Workers de la app, o escala lo que ya existe desde la CLI:

railyard scale my-app worker=2

Consulta Workers y tareas programadas para cron.

Archivos estáticos

python manage.py collectstatic --noinput se ejecuta automáticamente en el paso de build — la misma convención que usa el buildpack de Python de Heroku — así que WhiteNoise o cualquier configuración de STATIC_ROOT funciona sin necesidad de un paso en el Dockerfile ni un hook de pre-deploy. Una app que no usa django.contrib.staticfiles no se ve afectada, y un fallo aquí no bloquea el resto del build. Define DISABLE_COLLECTSTATIC=1 para desactivarlo.

Configuración y secretos

DATABASE_URL se inyecta automáticamente desde tu complemento de Postgres; REDIS_URL también, en cuanto tus dependencias fijen un cliente de Redis (redis, django-redis, rq) — apunta tú mismo el broker y el result backend de Celery hacia ella. Todo lo demás — DJANGO_SETTINGS_MODULE, SECRET_KEY, feature flags — es una variable de entorno normal en Variables, o railyard env:set my-app KEY=VALUE desde la CLI, así la misma imagen corre sin cambios desde staging hasta producción: paridad dev/prod, no una rama en tiempo de build. Apunta a una base de datos o Redis que corra como su propio servicio en el canvas con ${{redis.RAILYARD_PRIVATE_URL}} — resuelto por entorno. Consulta Variables y secretos.

Despliégalo

  • Desde un repositorio: pega la URL de Git, o elígelo del selector una vez que conectes GitHub — Railyard lee requirements.txt/pyproject.toml, completa gunicorn, el comando de release de migrate y DATABASE_URL, y despliega con cada push.
  • Desde la CLI: railyard create my-app https://github.com/me/my-app --addons postgres,redis, o railyard git:remote && git push railyard main desde dentro del repositorio.
  • Con un clic: agrega el botón de despliegue a tu README, o publícalo en el catálogo de plantillas para que cualquiera pueda lanzarlo con sus complementos y variables ya completados.