Tarifs de Laravel Cloud et Forge ou votre propre serveur : ce que coûte une application

Laravel Cloud facture le calcul à la seconde et cesse de le facturer pendant que votre application est en veille. Elle ne se met en veille qu'après une période d'inactivité égale à son délai de mise en veille. Chaque tâche planifiée la réveille pour une nouvelle période de même durée : une tâche toutes les 5 minutes avec un délai de 5 minutes ne laisse donc jamais l'environnement se mettre en veille. Si vous planifiez une tâche chaque minute, vous êtes facturé comme si l'application tournait en continu, jusqu'au plafond de Cloud de 28 jours par instance et par mois.

Si votre application peut rester en veille la majeure partie de la journée, sans rien de planifié plus souvent que son délai de mise en veille et avec ses jobs sur une file d'attente gérée, le plan Starter de Laravel Cloud ne facture le calcul que pour le temps où elle est active, plus l'abonnement au plan, les opérations de la file d'attente ainsi que le stockage et les sauvegardes de la base de données. Toutes les factures ci-dessous partent du principe que votre application ne se met jamais en veille. Si votre application est un ensemble de conteneurs Docker plutôt qu'une seule application Laravel, l'article le coût d'un conteneur toujours actif sur Fly.io, Cloud Run ou Fargate chiffre le même problème sur des plateformes de conteneurs facturées à l'usage.

Ce qu'une application Laravel a consommé sur notre serveur de test (pas un serveur DreamHost)

Nous avons déployé une nouvelle application Laravel 13 sur un serveur de test, dans un seul conteneur construit à partir des paquets de Debian 13. Elle exécutait les trois mêmes programmes que ceux fournis avec le LAMP Stack VPS, mais il s'agissait des versions d'Apache, de MariaDB et de PHP 8.4 de Debian 13, et non de l'image LAMP de DreamHost. Supervisor maintenait un worker de file d'attente en marche, et une ligne cron exécutait le planificateur. Le serveur disposait de 2 vCPU, comme Stack 4 et Stack 8.

À 200 requêtes par seconde, le p95 de cette page est monté à 160 ms, toujours sans erreur. Le générateur de charge partageait alors les deux mêmes cœurs, nous nous attendrions donc à un résultat un peu meilleur sur un serveur où ce n'est pas le cas. Une route Laravel simple, sans appel à la base de données, est restée sous 17 ms au 95e centile jusqu'à 400 requêtes par seconde. Pour comparaison, le scénario S3 ci-dessous suppose 3 millions de requêtes par mois, soit environ 1,2 par seconde en moyenne.

Même avec ce pic de 572 Mio, les 4 Go de Stack 4 laisseraient environ 3 Go libres, d'après nos calculs. Mais votre application en production contiendra plus de code et de données que notre installation neuve, et si vous ajoutez des workers pour une file d'attente plus chargée, chacun occupe environ 55 Mio. Pour la production, nous vous conseillerions Stack 8, qui offre deux fois la mémoire de Stack 4.

Ce que coûte l'application à trois tailles

Les factures ci-dessous utilisent les tarifs de Laravel pour sa région US East (Virginie). Chacune suppose que votre application répond à toute heure et planifie une tâche chaque minute, de sorte que le calcul et la base de données restent actifs tout le mois. Nous avons déduit le crédit d'utilisation de 5 $ inclus dans chaque plan payant. Pour les sauvegardes, nous avons retenu l'hypothèse basse, avec un stockage des snapshots égal aux données. S1 exécute le worker sur l'instance de 1 Gio de l'application elle-même. À en juger par notre serveur de test, où l'application entière, base de données comprise, a culminé à 572 Mio, cette instance a la place nécessaire. S2 et S3 placent les jobs sur une file d'attente gérée qui, selon la documentation de Laravel, remplace un worker dédié.

Même la petite facture S1 dépasse le tarif mensuel normal de Stack 8, et l'écart se creuse vite : S2 représente plus de trois fois ce montant. S3, à environ 11 fois, paie deux réplicas et un cache pour servir un trafic d'environ 1,2 requête par seconde en moyenne, bien en dessous des 100 par seconde que notre serveur de test a gérées. Vous n'ajouteriez pas de cache Valkey sur le serveur, car Laravel 13 stocke par défaut le cache, les sessions et la file d'attente dans la base de données. Si vous utilisez Forge, ajoutez les 12 $ par mois du plan Hobby au prix du serveur, quel que soit le scénario.

L'exemple Medium SaaS application de la documentation de Laravel aboutit à un montant inférieur, environ 53,90 $ par mois, car il utilise les tarifs US East (Ohio), omet l'abonnement au plan et laisse le calcul en veille les nuits et les week-ends.

Dans S1 et S2, la base de données coûte plus cher que l'instance d'application qu'elle dessert. Laravel MySQL continue aussi de facturer le stockage et les sauvegardes pendant sa mise en veille. Les sauvegardes pourraient atteindre 3,50 $ par mois si chaque snapshot quotidien était complet. Le trafic sortant est gratuit ici, car l'instance Flex 1 GiB de S1 inclut 100 Go par mois. Avec S3, le trafic sortant devient le plus gros poste d'utilisation, car deux réplicas Pro n'ont droit qu'à 200 Go et les 800 Go restants coûtent 80,00 $. Sur le LAMP Stack VPS, vous ne payez pas la bande passante au Go : elle est illimitée, sans frais de dépassement, dans le cadre de la politique d'utilisation équitable de DreamHost.

Les frais de Forge s'ajoutent au prix d'un serveur

Forge peut fonctionner sur un serveur que vous louez déjà grâce à son option Custom VPS. Ce serveur doit être une installation neuve d'Ubuntu 24.04 ou 26.04 x64 avec un accès SSH root. Forge installe alors lui-même Nginx, PHP, la base de données et Redis. Chez DreamHost, cela signifie un VPS Ubuntu, vendu aux mêmes tarifs Stack que le LAMP Stack VPS. L'image LAMP ne convient pas, puisqu'elle arrive avec Apache et MariaDB déjà en marche. Si vous hésitez entre les deux serveurs web, consultez Apache ou Nginx pour PHP.

Sur un serveur DreamHost, Forge coûte donc son abonnement plus le même prix Stack que vous paieriez pour exécuter l'application vous-même. Pour ce prix, Forge configure le serveur, déploie à chaque push et écrit les entrées Supervisor et cron, ce qui couvre la plupart des étapes ci-dessous.

Ce que vous gérez vous-même sur le serveur LAMP

Notre serveur de test a nécessité ces quatre étapes en plus d'Apache, de MariaDB et de PHP, sans panneau de contrôle. Si vous souhaitez malgré tout un panneau sur le serveur, l'article les alternatives gratuites à cPanel sur votre propre VPS mesure ce que HestiaCP, CloudPanel et Virtualmin consomment en mémoire et en disque. Les chemins supposent que votre application se trouve dans /var/www/app et s'exécute en tant que www-data.

1. Installez Composer et Supervisor

   Les deux se trouvent dans l'archive de paquets de Debian 13. Ignorez celui que votre serveur possède déjà.

   bashCopier

   sudo apt install composer supervisor

2. Ajoutez le worker de file d'attente à Supervisor

   Enregistrez ceci sous /etc/supervisor/conf.d/laravel-worker.conf. Il s'agit de l'exemple de Laravel, avec le chemin, l'utilisateur et le nombre de workers adaptés à une seule application. Nous avons déplacé le journal vers /var/log, car le Supervisor de notre serveur de test refusait de démarrer tant que le dossier de journaux dans l'application n'existait pas encore.

   iniCopier

   [program:laravel-worker]
   process_name=%(program_name)s_%(process_num)02d
   command=php /var/www/app/artisan queue:work --sleep=3 --tries=3 --max-time=3600
   autostart=true
   autorestart=true
   stopasgroup=true
   killasgroup=true
   user=www-data
   numprocs=1
   redirect_stderr=true
   stdout_logfile=/var/log/laravel-worker.log
   stopwaitsecs=3600

   Chargez-le ensuite avec sudo supervisorctl reread, sudo supervisorctl update et sudo supervisorctl start "laravel-worker:*".

3. Ajoutez la ligne cron du planificateur

   Enregistrez cette ligne sous /etc/cron.d/laravel. C'est l'unique entrée cron de Laravel, avec le chemin et l'utilisateur renseignés.

   bashCopier

   * * * * * www-data cd /var/www/app && php artisan schedule:run >> /dev/null 2>&1

4. Déployez avec un script

   Exécutez ce script depuis le dossier de l'application à chaque version. Lors de nos trois essais, tout ce qui suivait la modification du code a pris environ 1,5 seconde, principalement composer install. Le site est resté en mode maintenance pendant ce temps. Le premier déploiement d'une nouvelle application a pris 19 et 29 secondes lors de nos deux essais, essentiellement le temps que Composer télécharge les paquets.

   bashCopier

   php artisan down --retry=5
   git pull
   composer install --no-dev \
     --optimize-autoloader --no-interaction
   php artisan migrate --force
   php artisan optimize
   php artisan queue:restart
   php artisan up

Quand choisir chaque option

Au niveau de S1, la facture Laravel Cloud dépasse légèrement le tarif mensuel normal de Stack 8. Une application aussi petite tient aussi sur Stack 4, qui garde environ 3 Go libres à notre pic mesuré. Les écarts plus importants commencent avec S2, où Stack 8 laisse à l'application de la marge pour grandir.

Le support de DreamHost est disponible 24 h/24, 7 j/7, et le matériel, le réseau et la connectivité sont entièrement pris en charge par l'équipe de DreamHost. Vous gérez le système d'exploitation, les logiciels et la configuration, c'est-à-dire ici l'application. Lors de notre test, Composer, Supervisor et cron ont été configurés une seule fois, puis chaque version n'a nécessité qu'un script. Ensuite, les tâches mensuelles consistent à appliquer les mises à jour du système et à vérifier que les sauvegardes ont bien tourné.

Comment nous avons testé l'application et relevé les prix

DreamHost a consulté les pages de tarifs de Laravel Cloud, de Forge et de DreamHost le 20 octobre 2026, ainsi que leur documentation entre le 19 et le 21 octobre, et a effectué le test le 20 octobre. Nous avons revérifié chaque plan, prix et fonctionnalité DreamHost de cette page sur les pages de DreamHost le 22 octobre 2026.

Le serveur de test était une VM arm64 dotée de 2 vCPU et de 8 Go sous Ubuntu 24.04, avec l'application dans un seul conteneur construit à partir de paquets Debian 13. Il ne s'agissait ni d'un serveur DreamHost ni de l'image LAMP de DreamHost, et les plans VPS de DreamHost fonctionnent sur des processeurs AMD EPYC.

Le conteneur exécutait les paquets Apache 2.4, PHP 8.4 et MariaDB 11.8 de Debian 13, avec Laravel 13.38. Au repos, MariaDB occupait 123 Mio, Apache et PHP 123 Mio et le worker 55 Mio ; ces chiffres par processus partagent de la mémoire, leur somme dépasse donc le total de 208 Mio.

Chaque palier de charge a duré une minute. Lors des redéploiements chronométrés, une modification locale du code a remplacé git pull. Rien n'a été exécuté sur Laravel Cloud ni sur Forge : leurs colonnes proviennent des tarifs publiés. Le test ne mesure pas directement le trafic réel, HTTPS, PHP-FPM ni un serveur de 4 Go.

FAQ sur le coût de l'hébergement Laravel