Django
Despliega Django con Postgres, workers de Celery o RQ, collectstatic y migraciones.
Paso a paso: Desplegar Django en DigitalOcean · Desplegar Django en Hetzner · Desplegar Django en Vultr · Desplegar Django en OVHcloud · Desplegar Django en Scaleway · Desplegar Django en UpCloud
- Se detecta a partir de
requirements.txt,pyproject.tomlo unmanage.pyque 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 eswsgi:application. - Workers: se ofrecen Celery (
celery -A <project> worker, el proyecto se lee deDJANGO_SETTINGS_MODULE), Celery Beat, RQ, Huey, Dramatiq y Django-Q cuando son dependencias. - Base de datos:
psycopg→ Postgres, conDATABASE_URLinyectada.
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 yDATABASE_URL, y despliega con cada push. - Desde la CLI:
railyard create my-app https://github.com/me/my-app --addons postgres,redis, orailyard git:remote && git push railyard maindesde 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.