Déployer Symfony sur VPS : guide complet 2024

Un hébergement mutualisé impose la version PHP du serveur, désactive les extensions jugées « dangereuses » et interdit l'installation de processus persistants. Symfony 7 requiert PHP 8.2 au minimum — une contrainte que de nombreux mutualisés ne satisfont pas encore. Sur VPS, vous choisissez PHP 8.3 dès le premier jour, activez OPcache avec une configuration fine, et installez ext-redis, ext-intl ou ext-amqp selon vos besoins.

Les workers asynchrones (Symfony Messenger) exigent un processus qui tourne en fond, géré par Supervisor ou systemd. Sur mutualisé, ce processus est tout simplement impossible. Sur VPS, il démarre en une commande et redémarre automatiquement après un crash. Pour une application Symfony qui traite des emails transactionnels, des notifications push ou de l'import de fichiers, c'est une différence non négociable.

Système d'exploitation : Ubuntu 24.04 LTS ou Debian 12. Ces deux distributions bénéficient des dépôts ondrej/php et d'un support long terme compatible avec les cycles de maintenance de Symfony.

PHP : version 8.3 recommandée (minimum 8.2 pour Symfony 7). Extensions requises : php8.3-cli, php8.3-fpm, php8.3-mbstring, php8.3-xml, php8.3-curl, php8.3-zip, php8.3-intl, php8.3-opcache. Ajoutez php8.3-redis si vous utilisez Redis, php8.3-pgsql pour PostgreSQL.

Composer : version 2.x obligatoire. Composer 1.x ne supporte pas les contraintes de packages modernes.

Base de données : MySQL 8.0+ ou PostgreSQL 16+. Pour une app Symfony standard, 1 Go de RAM suffit pour MySQL ; PostgreSQL recommande 2 Go pour les plans de requête optimaux.

Nginx : 1.24+ depuis les dépôts officiels Ubuntu ou nginx.org.

RAM minimale :
- 1 Go : développement ou app légère sans queues
- 2 Go : production avec Symfony Messenger et un transport Redis
- 4 Go : workers multiples, Redis, sessions haute fréquence

Ports à ouvrir : 80 (HTTP), 443 (HTTPS), 22 (SSH). Fermez tout le reste.

Créez le fichier /etc/nginx/sites-available/symfony-app avec ce bloc server minimal, puis activez-le avec un symlink vers sites-enabled/.

server {
    listen 80;
    server_name votre-domaine.com;
    root /var/www/symfony-app/current/public;
    index index.php;

    location / {
        try_files $uri /index.php$is_args$args;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
    }

    location ~ /\.ht {
        deny all;
    }
}

Activez le site et testez la configuration avant de recharger nginx :
ln -s /etc/nginx/sites-available/symfony-app /etc/nginx/sites-enabled/ && nginx -t && systemctl reload nginx

Pour HTTPS, utilisez Certbot : certbot --nginx -d votre-domaine.com. Certbot modifie automatiquement le bloc server pour rediriger HTTP vers HTTPS et configurer les certificats Let's Encrypt.

Symfony lit .env, puis .env.local, puis .env.prod.local. En production, toute valeur sensible doit être dans .env.local — jamais commitée dans le dépôt git.

Variables essentielles en production :

APP_ENV=prod
APP_DEBUG=false
APP_SECRET=<64-chars-hex-aléatoire>
DATABASE_URL="mysql://dbuser:[email protected]:3306/symfony_prod"
MAILER_DSN=smtp://user:[email protected]:587
MESSENGER_TRANSPORT_DSN=redis://127.0.0.1:6379/messages

APP_SECRET doit être généré aléatoirement : openssl rand -hex 32. Ne jamais réutiliser la valeur par défaut du projet.

APP_DEBUG=false est critique : en mode debug, Symfony expose les traces de pile complètes, les variables de template et les requêtes SQL dans le navigateur — une fuite d'information sévère en production.

Pour les projets utilisant Symfony Secrets Vault (.env.vault), les secrets chiffrés peuvent être committés sans risque ; seule la clé de déchiffrement (SYMFONY_DECRYPTION_SECRET) reste dans .env.local.

Symfony Messenger permet de différer les tâches lourdes (envoi d'email, génération PDF, webhooks) dans une queue traitée de façon asynchrone. Sur VPS, Supervisor garantit que le worker tourne en permanence et redémarre après un crash.

Installez Supervisor :
apt install -y supervisor

Créez /etc/supervisor/conf.d/symfony-messenger.conf :

[program:symfony-messenger]
command=/var/www/symfony-app/current/bin/console messenger:consume async --time-limit=3600
user=deploy
autostart=true
autorestart=true
startretries=3
redirect_stderr=true
stdout_logfile=/var/log/supervisor/symfony-messenger.log
stdout_logfile_maxbytes=10MB
stdout_logfile_backups=5

L'option --time-limit=3600 force le worker à se relancer toutes les heures, libérant la mémoire accumulée. Supervisor s'occupe du redémarrage automatique.

Activez et démarrez le worker :
supervisorctl reread && supervisorctl update && supervisorctl start symfony-messenger

Pour surveiller l'état : supervisorctl status symfony-messenger

Côté Symfony, configurez le transport Redis dans config/packages/messenger.yaml :

framework:
    messenger:
        transports:
            async:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                retry_strategy:
                    max_retries: 3
                    delay: 1000

1. The environment variable "APP_SECRET" is not set.
APP_SECRET est absent du fichier .env.local sur le serveur. Vérifiez que le fichier existe dans {{deploy_path}}/shared/ et qu'il contient bien cette variable. Deployer crée un symlink vers ce fichier partagé à chaque release — si le symlink est cassé, Symfony ne lit pas .env.local.

2. Erreur 500 silencieuse — logs vides
Avec APP_DEBUG=false, Symfony n'affiche rien dans le navigateur et écrit dans var/log/prod.log. Lisez ce fichier en temps réel : tail -f /var/www/symfony-app/current/var/log/prod.log. Une permission refusée sur var/cache/ ou var/log/ est la cause la plus fréquente — corrigez avec chown -R deploy:www-data var/ depuis le répertoire de la release courante.

3. Connection refused sur la base de données
DATABASE_URL pointe vers 127.0.0.1 mais MySQL écoute sur localhost (socket Unix) — ou l'inverse. Testez la connexion directement : mysql -u dbuser -p -h 127.0.0.1 symfony_db. Si MySQL n'écoute pas sur TCP, ajoutez bind-address = 127.0.0.1 dans /etc/mysql/mysql.conf.d/mysqld.cnf et redémarrez.

4. There are no commands defined in the "cache" namespace
Ce message trompeur signifie souvent que Symfony ne peut pas écrire dans var/cache/. Le processus PHP-FPM tourne sous www-data, mais le répertoire appartient à deploy sans permissions d'écriture pour le groupe. Solution : chmod -R 775 var/cache var/log && chown -R deploy:www-data var/.

Si vous préférez éviter les heures de configuration manuelle, le template symfony-stack du Marketplace ServOrbit installe et configure automatiquement tout le socle décrit dans ce guide : PHP 8.3-FPM, Composer, nginx optimisé pour Symfony, Redis, Supervisor et les permissions correctes. Le VPS est opérationnel en moins de 5 minutes, avec un accès SSH root immédiat pour personnaliser votre déploiement.

Le template configure également les variables d'environnement essentielles via un formulaire guidé au moment de la commande — APP_SECRET généré aléatoirement, DATABASE_URL pré-remplie avec les credentials MySQL créés pour votre instance.

Vous gardez un contrôle total : le VPS vous appartient, il n'y a aucun lock-in, et vous pouvez utiliser Deployer PHP exactement comme décrit ci-dessus dès la première connexion SSH.