Quand l'hébergement clé en main devient un frein à la croissance
Les plateformes PaaS ont une promesse séduisante : pousser du code, le reste est géré. Cette simplicité a un prix qui reste raisonnable au démarrage, puis explose dès que l'application grossit. Un worker supplémentaire, plus de RAM, une base de données en haute disponibilité : chaque ajout déclenche une nouvelle ligne de facturation, souvent disproportionnée par rapport à la ressource réelle consommée. La migration vers un VPS ou un serveur dédié s'impose alors, mais elle amenait jusqu'ici un choix inconfortable : adopter Kubernetes, avec sa courbe d'apprentissage abrupte, ou rédiger soi-même des scripts de déploiement fragiles. Kamal 2, développé par 37signals, propose une troisième voie.
Ce qu'est Kamal 2 et ce qu'il change pour les équipes PHP
Kamal 2 est un outil de déploiement qui orchestre des conteneurs Docker sur n'importe quel serveur accessible en SSH. Pas de control plane à maintenir, pas de certificats Kubernetes à renouveler : une configuration YAML, une connexion SSH, et l'outil s'occupe du reste. Il gère le déploiement sans interruption de service grâce à un proxy intégré (Kamal Proxy, remplaçant de Traefik dans cette version), les rollbacks, les variables d'environnement chiffrées et les accessoires (base de données, Redis, etc.) en tant que services annexes.
Pour une stack Laravel typique, cela se traduit par :
- Un
Dockerfile unique combinant PHP-FPM et Nginx dans une image Alpine légère
- Un fichier
config/deploy.yml décrivant l'image, les serveurs cibles et les services annexes
- Des secrets gérés via
.kamal/secrets, chiffrés et versionnés séparément
La compatibilité est large : Hetzner, DigitalOcean, OVHcloud, serveur bare metal, peu importe, tant que SSH est accessible et que Docker tourne sur la machine cible.
Construire l'image Docker pour Laravel en production
Un déploiement Kamal commence par une image Docker solide. Pour Laravel, l'image doit embarquer PHP-FPM, Nginx, les extensions PHP nécessaires (notamment pdo_pgsql si PostgreSQL est utilisé) et les assets compilés. L'image est construite sur une base Alpine pour limiter le poids final, avec Supervisor pour piloter PHP-FPM et Nginx dans le même conteneur.
Quelques points d'attention pour une image de production :
- Copier d'abord
composer.json et composer.lock avant le reste du code pour tirer parti du cache de couches Docker lors des rebuilds
- Exécuter
composer install --no-dev --optimize-autoloader pour exclure les dépendances de développement
- Compiler les assets avec Vite dans une étape distincte si un multi-stage build est utilisé, afin de ne pas embarquer Node.js dans l'image finale
- Configurer les permissions sur
storage/ et bootstrap/cache/ pour que PHP-FPM puisse y écrire
L'image résultante est poussée vers un registre (GitHub Container Registry, Docker Hub ou un registre privé) avant chaque déploiement.
Configurer et lancer le déploiement
Le fichier config/deploy.yml est le cœur de Kamal. On y déclare le nom du service, l'image Docker à utiliser, les adresses IP des serveurs cibles, et les accessoires comme la base de données PostgreSQL ou Redis. Les variables sensibles (mot de passe de base de données, clé d'application Laravel) sont référencées via des secrets et jamais écrites en clair dans ce fichier.
Pour les workers de queue Laravel, Kamal permet de définir des rôles de serveurs distincts : un groupe pour les requêtes web, un autre dédié uniquement à php artisan queue:work. Cette séparation est explicite dans la configuration et ne nécessite aucun service tiers.
Le premier déploiement s'effectue avec kamal setup, qui installe Docker sur les serveurs, configure le proxy et démarre les conteneurs. Les déploiements suivants utilisent kamal deploy, qui reconstruit l'image, la pousse sur le registre, puis effectue le remplacement des conteneurs sans interruption de service grâce à un health check configuré dans le YAML.
Kamal gère également les commandes ponctuelles via kamal app exec, ce qui permet de lancer php artisan migrate --force en production de façon contrôlée, ou d'ouvrir un shell dans un conteneur pour du débogage.
Ce que ça change pour vous
Si vous pilotez une application web et que votre facture d'hébergement augmente chaque trimestre sans que votre trafic n'ait doublé, c'est souvent le signe que la plateforme fait payer la commodité à un tarif croissant. Migrer vers un serveur classique avec les bons outils permet de retrouver un coût prévisible, proportionnel aux ressources réellement utilisées. Kamal 2 rend cette migration accessible à une équipe de développeurs sans exiger de compétences en administration système avancée. Le site continue de fonctionner pendant les mises à jour, les mots de passe restent protégés, et votre équipe garde la main sur l'infrastructure sans dépendre d'une interface propriétaire.
Article rédigé à partir de la publication originale de Michael Laweh sur dev.to, republié sur klytron.com.
