Process types
Les quatre types de process supportés (web, worker, cron, release) et les process one-off. Comment les déclarer, comment ils scalent.
Une app peut avoir plusieurs process types. Chacun joue un rôle précis dans le cycle de vie de votre application. Les types sont déclarés dans paas.toml ou dans un Procfile compatible Heroku.
web
Le process qui sert le trafic HTTP. Doit écouter sur le port défini par la variable d'environnement $PORT. Au moins un web est attendu pour qu'une URL soit exposée.
type = "web"
command = "gunicorn config.wsgi:application --bind 0.0.0.0:$PORT"
Le scaling automatique fonctionne sur le type web à partir de signaux CPU, RAM, ou requêtes par seconde.
worker
Process en arrière-plan, sans port HTTP. Pour les jobs asynchrones (Celery, Sidekiq, BullMQ, GoodJob, …).
type = "worker"
command = "celery -A config worker --loglevel=info"
Le scaling auto peut être configuré sur la profondeur de queue : si la file dépasse 100 jobs, on ajoute une instance, jusqu'à un max configurable.
cron
Process exécuté périodiquement selon une expression cron. Le nom du type doit commencer par cron-.
type = "cron-cleanup"
command = "python manage.py cleanup"
schedule = "0 3 * * *"# 3h du matin
Cron expressions standard, fuseau horaire Europe/Paris par défaut. Configurable via la clé timezone.
release
Commande exécutée à chaque déploiement, avant le routage du trafic vers la nouvelle version. Idéale pour les migrations de base de données.
command = "python manage.py migrate --noinput"
timeout = 600
Si la release échoue, par défaut le déploiement est annulé. La version précédente reste en production. Vous pouvez changer ce comportement avec on_failure = "warn".
Process one-off
Les commandes interactives à la demande (consoles Django/Rails, shells de maintenance, migrations exceptionnelles) ne sont pas encore exposées par la CLI. Pour l'instant, utilisez le release process du paas.toml pour les opérations qui doivent tourner avant le démarrage du web : migrations, seeds, warm-up de cache.
L'API d'exécution interactive est sur la roadmap. En attendant, déclarez vos commandes ponctuelles dans release ou utilisez un endpoint protégé interne à votre app.