Comment déployer une application Symfony sur un VPS (étape par étape)

Ce guide explique comment déployer une application Symfony 6.4 en production sur un VPS. Il couvre Ubuntu/Debian et Rocky/AlmaLinux/RHEL, la pile web (NGINX/Apache + PHP‑FPM), TLS (Let’s Encrypt), la gestion de configuration et des secrets, les migrations, plusieurs stratégies de déploiement (Git pull, releases « zero‑downtime », Docker), ainsi que la sécurité, la performance, le monitoring/logging et le CI/CD. L’objectif est de fournir des instructions claires et reproductibles pour « tous les candidats possibles ».

Pré‑requis

VPS avec SSH et utilisateur non‑root (sudo).
Domaine pointant vers l’IP du VPS (DNS A/AAAA).
Git installé localement et sur le serveur; accès au dépôt (clé SSH/token).
Projet Symfony 6.4 avec Composer et Doctrine Migrations.

Conseil: Dimensionnez CPU/RAM/disque/IOPS/swap selon « vos exigences applicatives ». Commencez petit, surveillez, puis augmentez.

Préparation du serveur

Utilisateur de déploiement & SSH

Mises à jour, firewall, utilitaires

Installer PHP, Composer, NGINX/Apache

Préparer l’application

Configurer NGINX (recommandé)

HTTPS (Let’s Encrypt)

Gestion de config & secrets

Utiliser .env.local (non commité) et/ou Environment= systemd pour les workers.
Jamais de secrets dans Git; préférer Vault/sops/secret manager en CI/CD.

Recommandations d’infrastructure

Comparaison entre les hébergeurs Hébergeur Options disponibles Fonctionnalités clés Avantages Inconvénients DigitalOcean

Droplets (VPS)
Managed DB/Redis
Spaces/CDN
1‑Click images
Snapshots/Backups
Monitoring/Alerts
UX simple
Docs claires
Bon réseau
Moins d'options HF
Prix moyens
Linodes (VPS)
Managed DB/K8s
Object Storage
IPv6 natif
StackScripts
Bon support
Rapport perf/prix
Réseau fiable
Facturation simple
Moins de régions
Moins d'add‑ons
Cloud Compute
High Frequency
Bare Metal
Beaucoup de régions
ISO custom
Snapshots
Bonnes perfs CPU
Offres variées
Déploiement rapide
Support variable
Backups en option

Dimensionnement (selon « vos exigences applicatives »)

Critère Valeur recommandée Justification Petite application 1–2 vCPU, 1–2 Go RAM, 25–40 Go SSD, swap 1–2 Go Démarrage frugal, coûts maîtrisés; surveiller la charge et évoluer si nécessaire. Moyenne 2–4 vCPU, 4–8 Go RAM Activer OPcache, cache HTTP et éventuellement CDN pour absorber le trafic. Élevée 4–8 vCPU, 8–16 Go RAM Base de données managée, Redis et workers dédiés pour la scalabilité.

Workflows de déploiement

Git pull sur serveur (simple).
Releases « zero‑downtime » (symlink current → release).
Docker/docker‑compose (images construites en CI).

CI/CD (GitHub Actions — exemple)

Performance

OPcache activé (validate_timestamps=0); recharger FPM à chaque release.
Cache HTTP et CDN; minification/bundling; gzip/brotli dans NGINX.
Doctrine: éviter N+1, index, profiling; Redis pour cache/sessions si nécessaire.

Monitoring & logging

APM (Datadog/New Relic) ou Prometheus/Grafana; Uptime et alertes 5xx/latence.
Centralisation des logs (journald, Loki, ELK); Sentry pour erreurs applicatives.