Référence paas.toml
Le fichier paas.toml en détail. Toutes les sections, leurs clés, leurs valeurs par défaut, leurs effets.
Le fichier paas.toml à la racine de votre repo configure votre app de manière déclarative. Il est optionnel : la plateforme détecte les défauts raisonnables. Mais dès que vous avez plusieurs process, du scaling, ou une release task, il devient utile.
Exemple minimal
Le fichier le plus basique pour une app web. La plateforme détecte le langage automatiquement.
type = "web"
command = "gunicorn app:app --bind 0.0.0.0:$PORT"
Section [build]
Personnalise le build. Optionnelle.
buildpack = "auto" # ou "heroku/python"
include = ["src/", "Pipfile*"]
exclude = ["tests/", "*.md"]
env = { NODE_ENV = "production" }
| Clé | Description |
|---|---|
| buildpack | "auto" (détection) ou un buildpack explicite. Liste sur /docs/buildpacks. |
| include | Globs des fichiers à inclure dans le build. Par défaut tout sauf .git/ |
| exclude | Globs à exclure |
| env | Variables d'environnement disponibles uniquement pendant le build |
Section [[processes]]
Liste des process types. 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"
[[processes]]
type = "worker"
command = "celery -A config worker --loglevel=info"
[[processes]]
type = "cron-cleanup"
command = "python manage.py cleanup"
schedule = "0 3 * * *" # 3h du matin tous les jours
| Clé | Description |
|---|---|
| type | web, worker, ou nom personnalisé pour cron |
| command | Commande à exécuter |
| schedule | Cron expression (uniquement pour les types personnalisés cron) |
| port | Port HTTP pour les process web. Défaut : $PORT injecté par la plateforme |
Section [scaling]
Configure le scaling auto par type de process. Par défaut, manuel à 1 instance.
min = 2
max = 8
target_cpu = 70 # scale up si CPU moyen > 70 %
target_rps = 200 # ou si requêtes par seconde > 200
[scaling.worker]
min = 1
max = 4
target_queue_depth = 100 # scale selon la profondeur de queue
Section [resources]
Réserve de la mémoire au-delà du gabarit standard, pour les applications lourdes (GitLab, JVM, ERP). Validé jusqu’à 8 Gi.
memory = "8Gi" # jusqu'à 8 Gi
La section [resources] est prise en compte uniquement en déploiement depuis les sources (git push). En déploiement par image, l’application reste sur le gabarit standard — voir les tailles de dynos.
Section [healthcheck]
Configure la sonde de santé HTTP de vos process web. Tant que la sonde ne répond pas, l’instance ne reçoit pas de trafic.
http_path = "/health" # défaut : "/"
initial_delay_seconds = 5
period_seconds = 10 # intervalle entre deux sondes
failure_threshold = 3 # échecs tolérés avant redémarrage
Applications à démarrage long
Le budget de démarrage vaut period_seconds × failure_threshold. Pour une application qui met plusieurs minutes à démarrer, augmentez ces valeurs — tout se déclare ici, aucune intervention du support n’est nécessaire :
http_path = "/-/readiness"
period_seconds = 30
failure_threshold = 30 # 30 × 30 s = budget de 15 minutes
Si votre application restreint son endpoint de santé par IP source (GitLab avecmonitoring_whitelist, par exemple), autorisez127.0.0.0/8et10.42.0.0/16: les sondes de la plateforme proviennent de ce réseau interne. Sans cette autorisation, l’endpoint répond 404 aux sondes et l’instance n’est jamais considérée prête.
Section [observability]
tracing = true # auto-instrumentation OpenTelemetry
sample_rate = 0.1 # 10 % des traces collectées
log_level = "info"
metrics_path = "/metrics" # endpoint Prometheus custom
Section [release]
Commande exécutée à chaque release, avant le routage du trafic. Idéal pour les migrations de base de données.
command = "python manage.py migrate --noinput"
timeout = 600 # secondes
on_failure = "rollback" # ou "abort", "warn"
Si la commande release échoue, par défaut la release est annulée et l'ancienne version reste en production. Vous pouvez changer ce comportement avec on_failure.