Déployer une application Symfony sans changer de framework ni réécrire son code devient possible sur Laravel Cloud. La plateforme, jusqu’ici associée aux projets Laravel, prend désormais en charge Symfony et lui ouvre la même infrastructure cloud managée, les mêmes offres et les mêmes tarifs. Pour les équipes, cela ajoute une option entre l’administration de serveurs maison et le recours à un hébergeur spécialisé facturé par projet ou par utilisateur.

La mise en ligne s’appuie sur la configuration existante : Laravel Cloud détecte le composant symfony/framework-bundle dans le fichier composer.json et adapte l’environnement aux commandes, aux files d’attente et aux processus en arrière-plan de Symfony. Une agence qui gère plusieurs applications peut ainsi centraliser déploiement, supervision et facturation, sans imposer à ses développeurs les conventions Laravel. L’intérêt est concret : moins de temps consacré aux certificats SSL, aux correctifs système et à la capacité des serveurs, davantage de temps pour faire évoluer les fonctionnalités.

En bref : Symfony rejoint Laravel Cloud sans réécriture

• Aucun changement de code requis pour déployer une application Symfony prise en charge.
• La plateforme automatise l’hébergement cloud, les certificats SSL, la configuration du serveur et les déploiements sans interruption.
• Les environnements de prévisualisation créés pour les demandes de fusion facilitent les revues d’équipe et les démonstrations aux clients.
• Les ressources Flex peuvent se mettre en veille quand elles sont inutilisées ; les files d’attente managées sont disponibles via un paquet dédié.
• Le plan Starter est affiché à 5 dollars par mois, avec 5 dollars de crédits d’usage mensuels et un premier mois gratuit.

Déployer une application Symfony sur Laravel Cloud sans modifier son code

Le fonctionnement repose sur la détection automatique du projet. Lorsque Laravel Cloud repère symfony/framework-bundle dans composer.json, il configure la prise en charge des usages courants de Symfony, notamment les commandes, les files de messages et les processus en arrière-plan. La structure de l’application reste intacte : nul besoin d’adopter les conventions Laravel pour profiter de la plateforme.

Concrètement, une équipe peut connecter son dépôt GitHub, GitLab ou Bitbucket, puis conserver les commandes de construction et de déploiement par défaut ou les ajuster à ses besoins. Chaque nouvelle poussée sur la branche configurée déclenche un déploiement sans interruption de service. La présentation officielle de cette prise en charge Symfony détaille cette approche, tandis que la documentation des environnements d’exécution précise les versions de PHP disponibles : 8.2, 8.3, 8.4 et 8.5, cette dernière étant proposée par défaut dans les nouveaux environnements.

Pour rendre l’exemple concret, une petite agence qui maintient un outil de réservation en Symfony peut relier son dépôt et créer un environnement de production sans reprendre son application. Si elle attache une base de données depuis l’interface, la variable DATABASE_URL est injectée automatiquement : l’équipe évite ainsi de recopier les identifiants manuellement.

Des environnements de prévisualisation pour chaque demande de fusion

Les équipes qui livrent régulièrement peuvent associer un environnement isolé à chaque pull request. Chaque proposition de modification dispose alors de sa propre URL, ce qui permet de tester une fonctionnalité réelle sans fusionner d’abord le code dans une branche de préproduction. À la fermeture de la demande, cet environnement temporaire est supprimé automatiquement.

Dans le cas de l’agence, le client peut essayer une nouvelle étape du parcours de réservation depuis un lien dédié, tandis que les développeurs continuent de travailler sur la version principale. Cette organisation réduit les allers-retours de démonstration et rend les validations plus concrètes.

Infrastructure cloud managée, supervision et maîtrise des coûts

La différence principale avec un serveur administré en interne se situe autour du code. Laravel Cloud prend en charge le provisionnement, la configuration de Nginx, les certificats SSL, les correctifs du système et les décisions de mise à l’échelle. La plateforme fournit aussi des métriques, des journaux et des statistiques HTTP pour suivre la performance et repérer plus rapidement un incident.

Les ressources Flex peuvent descendre à zéro lorsqu’une application est inactive, puis se réveiller en moins de 500 millisecondes à l’arrivée d’une requête. C’est utile pour un environnement de test ou une application peu fréquentée, car la capacité inutilisée ne continue pas à tourner comme un serveur réservé en permanence. Des plafonds de dépenses par organisation et des alertes à 50 %, 80 %, 90 % et 100 % aident à suivre le budget avant la facture de fin de mois.

Le plan Starter annoncé coûte 5 dollars par mois et inclut 5 dollars de crédits d’usage mensuels, un nombre illimité d’applications et d’utilisateurs, ainsi qu’un premier mois gratuit. Ce tarif constitue un point d’entrée pour évaluer le service ; le coût réel dépend ensuite des ressources consommées et du plan choisi.

La plateforme propose également Valkey, compatible avec les clients Redis, avec des identifiants de connexion injectés automatiquement. Les tâches planifiées demandent toutefois une attention particulière : elles fonctionnent sur une capacité Pro toujours active ou sur Flex lorsque la mise en veille automatique est désactivée, afin que l’application soit disponible à l’heure prévue.

Files d’attente Symfony et tâches en arrière-plan

Les files d’attente managées pour Symfony passent par le paquet laravel/symfony-on-cloud, qui fournit un transport adapté à Symfony Messenger. Les workers, isolés du cluster principal de l’application, peuvent monter en capacité quand les messages s’accumulent puis revenir à zéro lorsque la file est vide. L’objectif est de facturer le calcul effectivement utilisé plutôt qu’une capacité de traitement réservée en permanence.

Par exemple, une boutique Symfony peut placer l’envoi des confirmations de commande dans une file de messages. Si plusieurs commandes arrivent en même temps, les workers absorbent le pic ; une fois la file traitée, ils s’arrêtent. Les tâches échouées sont visibles dans le tableau de bord et peuvent être relancées depuis celui-ci, tandis que la gestion des processus et le redémarrage des workers après déploiement sont pris en charge par la plateforme.

Le code du bundle Symfony officiel pour les files managées permet d’examiner cette intégration. Pour les équipes qui veulent comprendre la logique d’autoscaling des workers, ce guide sur les files d’attente gérées sur Laravel Cloud apporte un complément utile.

Quand Laravel Cloud devient une option pertinente pour Symfony

Les projets Symfony disposent désormais d’une troisième voie entre les serveurs autogérés et les plateformes spécialisées facturées selon le nombre de projets ou de membres. Le choix dépend toujours des besoins : une équipe ayant des exigences particulières sur le système d’exploitation ou l’architecture peut préférer garder un contrôle étendu, tandis qu’une équipe qui souhaite réduire les tâches d’exploitation peut apprécier une infrastructure managée conçue pour PHP.

La facturation et les accès centralisés prennent aussi leur intérêt lorsqu’une organisation gère plusieurs applications, Symfony comme Laravel. Les équipes peuvent les réunir dans une même organisation Laravel Cloud pour partager la supervision et les contrôles d’accès, sans fusionner leurs bases de code. Ce fonctionnement répond notamment aux agences qui livrent et maintiennent des projets distincts.

Pour examiner d’autres scénarios de mise en ligne sur la plateforme, ce retour sur la conception d’une infrastructure cloud évolutive complète les informations propres à Symfony. La nouveauté ne rend pas tous les hébergements équivalents : elle donne simplement aux équipes Symfony davantage de choix pour arbitrer entre contrôle, coûts et temps consacré à l’exploitation.