Laravel Cloud élargit son terrain de jeu : la plateforme peut désormais héberger des applications Next.js et Nuxt aux côtés d’un backend Laravel, y compris lorsque les projets partagent un même dépôt. Pour une équipe qui gérait jusque-là son API d’un côté et son interface sur un autre service, ce changement réduit les allers-retours entre plateformes : les déploiements, les réglages d’accès et la facturation sont regroupés dans le même environnement. Le résultat recherché est un déploiement simplifié, sans imposer pour autant une architecture unique au frontend et au backend.

Concrètement, chaque partie reste une application indépendante. Une boutique fictive, Atelier Nord, peut ainsi conserver son API Laravel dans un dossier et placer sa vitrine Next.js dans un autre, puis créer deux applications Laravel Cloud reliées au même dépôt. Le frontend et le backend ont chacun leurs variables d’environnement, leurs domaines et leurs paramètres de capacité ; ils peuvent donc évoluer selon leur trafic respectif. Cette organisation convient aussi à Nuxt et aux dépôts monorepo, tout en laissant accessibles les dossiers partagés pendant la compilation. Avant la mise en production, quelques choix restent toutefois essentiels : déterminer comment l’interface est rendue, quelles variables peuvent être exposées au navigateur et où résident les données. Réunir l’hébergement cloud facilite l’exploitation, mais ne remplace pas ces décisions d’architecture.

En bref

• Laravel Cloud prend en charge les applications Next.js et Nuxt en plus des backends Laravel.
• Un dépôt partagé peut alimenter plusieurs applications, chacune configurée depuis son propre dossier racine.
• Frontend et backend disposent de paramètres distincts pour les environnements, les domaines et la mise à l’échelle.
• La plateforme ajoute notamment Nginx, des ports configurables et des journaux d’accès visibles dans le tableau de bord.
• Les équipes doivent toujours gérer avec soin les variables publiques, les migrations et l’emplacement des données.

Laravel Cloud déploie Next.js et Nuxt depuis un même dépôt

Le fonctionnement s’appuie sur la prise en charge des monorepos. Lorsqu’un dépôt contient plusieurs projets, Laravel Cloud détecte les applications présentes et propose de sélectionner le dossier à déployer. Pour Atelier Nord, l’équipe crée une application Cloud pour Laravel, puis une seconde pour le frontend Next.js, en choisissant à chaque fois le bon répertoire racine.

Cette séparation évite de traiter tout le dépôt comme un seul bloc. Chaque application est une ressource distincte, avec ses propres variables d’environnement, instances, options de mise à l’échelle, domaines et services associés. Les dossiers voisins restent disponibles pendant la compilation : un frontend peut donc s’appuyer sur des paquets partagés, même si seul son propre répertoire est lancé comme application.

Le bénéfice est particulièrement visible quand les usages diffèrent. Une API peut connaître des pics provoqués par des intégrations, tandis que la vitrine reçoit un trafic plus régulier ; les deux composants peuvent alors être dimensionnés indépendamment. Pour comprendre le parcours de configuration, les équipes peuvent consulter le présentation officielle du déploiement de Next.js et Nuxt sur Laravel Cloud ainsi que les instructions de déploiement Next.js.

Des réglages adaptés aux frameworks JavaScript

Laravel Cloud adapte les options proposées au framework détecté. Next.js ou Nuxt ne sont donc pas configurés comme un backend PHP : chaque application dispose de ses propres réglages d’exécution, sans obliger l’équipe à fusionner artificiellement ses besoins avec ceux de Laravel. Les deux frameworks apparaissent également dans le sélecteur de création d’application, ce qui rend les possibilités de la plateforme plus claires dès le départ.

Cette distinction aide à garder une chaîne de livraison lisible. Dans l’exemple d’Atelier Nord, une modification du parcours d’achat côté Nuxt peut être déployée sans modifier les paramètres de l’API, tandis qu’une évolution du backend n’exige pas de reconfigurer le frontend. Un même dépôt ne signifie donc pas une application monolithique : il sert plutôt de point de départ commun à plusieurs unités autonomes.

Une infrastructure cloud pensée pour Next.js et Nuxt

La prise en charge des applications JavaScript s’accompagne d’évolutions techniques. Les applications multilangages passent désormais derrière Nginx, déjà utilisé par Laravel Cloud pour les applications PHP. Cette base commune permet de configurer les ports au lieu de dépendre uniquement d’une valeur imposée par un framework, et rend les journaux d’accès disponibles dans le tableau de bord.

Pour une équipe, ces journaux donnent davantage de visibilité sur les requêtes reçues par une application qui n’est pas en PHP. Si la page d’accueil d’Atelier Nord répond mal après une mise en production, l’équipe peut examiner les accès depuis le même espace d’administration que le reste de la plateforme. Laravel Cloud annonce également des temps de compilation JavaScript améliorés, un avantage utile lorsque les équipes publient fréquemment des ajustements d’interface.

Les ressources restent séparées, même si elles sont réunies sous une même organisation. Cela permet de centraliser les droits d’accès : une responsable technique peut gérer les autorisations des développeurs pour les différents projets depuis un seul endroit, plutôt que de maintenir des comptes distincts chez plusieurs hébergeurs. Les enjeux de capacité et de croissance sont détaillés dans ce guide consacré à une infrastructure Laravel Cloud évolutive.

Un déploiement simplifié, avec des choix à vérifier

La plateforme automatise une partie de la configuration, mais elle ne décide pas à la place de l’équipe comment l’application doit fonctionner. Avant le déploiement, il faut notamment vérifier le mode de rendu, le stockage des données et la façon dont les variables d’environnement atteignent le navigateur. Une variable destinée au frontend et rendue publique ne doit pas contenir de secret : les identifiants privés de l’API ou de la base de données doivent rester côté serveur.

Les migrations de base de données demandent également une attention particulière. Une nouvelle version du frontend peut être déployée en parallèle d’une évolution du backend ; prévoir l’ordre des changements limite les incompatibilités temporaires. Les guides dédiés à Nuxt sur Laravel Cloud précisent les réglages propres à ce framework, tout comme le guide Next.js accompagne la configuration de son environnement et de ses données.

Pour une première mise en ligne, l’équipe peut connecter son dépôt, créer l’application correspondant au backend, puis ajouter une autre application en sélectionnant le dossier du frontend. Elle configure ensuite les domaines et les variables nécessaires avant de vérifier les deux déploiements. Ce parcours constitue une base concrète pour réunir les applications web sans confondre leurs responsabilités.

Une seule plateforme pour gérer le frontend et le backend

Le regroupement intéresse autant les personnes qui développent que celles qui administrent les accès et les coûts. Une équipe n’a plus besoin de coordonner deux tableaux de bord et deux chaînes de livraison pour chaque publication, ni de comparer manuellement l’adresse de l’API attendue par le frontend avec celle réellement exposée par le backend. L’objectif est une gestion commune, avec une facturation centralisée sur Laravel Cloud.

La prise en charge des frontends est proposée sur les différents forfaits sans frais supplémentaire lié à cette fonctionnalité ; les ressources consommées restent à prendre en compte dans la facture habituelle. Une agence qui héberge plusieurs vitrines Next.js ou Nuxt peut, par exemple, regrouper leur administration sous une même organisation plutôt que multiplier les espaces de gestion. Pour une petite équipe, l’intérêt est surtout opérationnel : moins de services à apprendre et moins de réglages dispersés.

Les équipes qui découvrent la plateforme peuvent commencer par le guide de déploiement d’une application Laravel, puis ajouter leur interface dans un second dossier du dépôt. Pour décider si cette organisation correspond à leurs besoins, elles peuvent aussi lire une analyse des points à vérifier avant de déployer Next.js ou Nuxt : regrouper l’infrastructure simplifie le pilotage, mais les choix de configuration et d’architecture restent déterminants.