Pourquoi self-héberger Symfony sur un VPS ?
Symfony exige une configuration PHP précise : extensions (intl, opcache, pdo), version de PHP, réglages de mémoire et droits sur les dossiers var/cache et var/log. Un hébergement mutualisé impose souvent des versions figées et désactive des extensions essentielles, tandis qu'un PaaS masque la couche PHP-FPM. Sur un VPS, vous choisissez PHP 8.2/8.3, activez et réglez OPcache et le preloading pour des gains de performance majeurs, et configurez PHP-FPM (nombre de processus, pm.max_children) selon votre charge. Vous maîtrisez aussi MySQL ou PostgreSQL et le cache Redis pour les sessions et Doctrine. Pour une application Symfony en production, ce niveau de contrôle conditionne directement le temps de réponse.
Bénéfices concrets d'un Symfony auto-hébergé
- Choix de la version de PHP et de toutes les extensions requises sans restriction.
- OPcache et preloading Symfony activés pour des temps de réponse nettement réduits.
- Réglage fin de PHP-FPM (
pm.max_children, workers) selon la RAM disponible. - Base MySQL/PostgreSQL et cache Redis sous votre contrôle, avec sauvegardes planifiées.
- Exécution des commandes console et du Messenger (workers) en continu via systemd ou Supervisor.
- Déploiements atomiques avec liens symboliques, sans interruption de service.
Prérequis matériels et logiciels
Une application Symfony avec base de données tourne confortablement sur 2 vCPU et 2 Go de RAM ; montez à 4 Go si vous ajoutez Redis, Elasticsearch ou des workers Messenger. Installez PHP 8.2+ avec FPM et les extensions intl, opcache, pdo_mysql, mbstring, xml, ainsi que Composer 2. Nginx sert de frontal, MySQL 8 ou PostgreSQL comme base. Vous pouvez tout conteneuriser avec Docker (image php:8.3-fpm) ou installer nativement. Un domaine pointé vers le VPS est nécessaire pour le TLS. Prévoyez l'environnement APP_ENV=prod et la génération des assets via AssetMapper ou Webpack Encore.
Déployer Symfony étape par étape
Préparer le serveur et le code
En SSH, installez PHP-FPM 8.3, les extensions et Composer (ou Docker). Clonez le dépôt et créez .env.local avec APP_ENV=prod, APP_SECRET et DATABASE_URL. Lancez composer install --no-dev --optimize-autoloader.
Compiler le cache et les assets
Exécutez php bin/console cache:clear --env=prod puis cache:warmup. Compilez les assets avec php bin/console asset-map:compile (AssetMapper) ou npm run build (Encore). Vérifiez les droits sur var/.
Migrer la base de données
Lancez php bin/console doctrine:migrations:migrate --no-interaction pour appliquer le schéma. Configurez une connexion Redis pour les sessions et le cache Doctrine si votre application en a besoin.
Configurer Nginx et PHP-FPM
Pointez la racine Nginx vers public/, routez toutes les requêtes vers index.php via try_files, et transmettez les .php au socket PHP-FPM avec fastcgi_pass. Réglez pm.max_children en fonction de la RAM et activez OPcache dans php.ini.
Sécuriser avec un certificat SSL
Obtenez un certificat Let's Encrypt via Certbot pour votredomaine.ma, forcez le HTTPS et activez le renouvellement automatique. Bloquez l'accès direct aux dossiers config/, src/ et var/ au niveau de Nginx.
Superviser les workers Messenger
Si vous utilisez le composant Messenger, déclarez un service systemd ou Supervisor qui exécute php bin/console messenger:consume async en continu, avec redémarrage automatique. Planifiez un cron pour messenger:stop-workers après déploiement afin de recharger le nouveau code.
Activez le preloading de Symfony en pointant opcache.preload vers var/cache/prod/App_KernelProdContainer.preload.php dans votre php.ini. Le conteneur de services et les classes du framework sont alors chargés une fois en mémoire au démarrage de PHP-FPM, ce qui élimine une part importante du coût d'autoloading à chaque requête et réduit sensiblement la latence en production.
