Prijzen van Laravel Cloud en Forge vs. je eigen server: wat één app kost

Laravel Cloud rekent rekenkracht per seconde af en stopt daarmee zolang je app slaapt. De app valt pas in slaap na een rustige periode die even lang duurt als de slaaptime-out. Elke geplande taak houdt hem weer zo lang wakker, dus een taak om de 5 minuten bij een time-out van 5 minuten laat de omgeving nooit slapen. Plan je elke minuut iets in, dan betaal je alsof de app altijd aanstaat, tot het maximum van Cloud van 28 dagen per instance per maand.

Kan je app het grootste deel van de dag slapen, staat er niets vaker gepland dan de time-out en draaien de jobs op een beheerde queue? Dan rekent het Starter-abonnement van Laravel Cloud alleen rekenkracht af voor de tijd dat de app wakker is, plus de abonnementskosten, de operaties van de queue en de opslag en back-ups van de database. Elke rekening hieronder gaat ervan uit dat je app nooit slaapt. Bestaat je app uit een set Docker-containers in plaats van één Laravel-app, dan berekent wat een container die altijd aanstaat kost op Fly.io, Cloud Run of Fargate hetzelfde probleem voor containerplatforms waar je per gebruik betaalt.

Wat één Laravel-app gebruikte op onze testserver (geen DreamHost-server)

We hebben een nieuwe Laravel 13-app op een testserver gezet, in één container die is gebouwd met de eigen pakketten van Debian 13. Die draaide dezelfde drie programma's die de LAMP Stack VPS meelevert, maar dan de eigen Apache, MariaDB en PHP 8.4 van Debian 13, niet de LAMP-image van DreamHost. Supervisor hield één queue-worker draaiende en één cron-regel startte de scheduler. De server had 2 vCPU, net als Stack 4 en Stack 8.

Bij 200 verzoeken per seconde steeg de p95 van die pagina naar 160 ms, nog steeds zonder fouten. De loadgenerator deelde toen dezelfde twee cores, dus op een server waar dat niet zo is, verwachten we iets betere cijfers. Een kale Laravel-route zonder databaseaanroep bleef tot 400 verzoeken per seconde onder de 17 ms op het 95e percentiel. Ter vergelijking: S3 hieronder gaat uit van 3 miljoen verzoeken per maand, gemiddeld zo'n 1,2 per seconde.

Zelfs bij die piek van 572 MiB zou de 4 GB van Stack 4 volgens onze berekening ongeveer 3 GB vrij laten. Maar je productie-app heeft meer code en data dan onze verse installatie, en als je workers toevoegt voor een drukkere queue, neemt elke worker ongeveer 55 MiB in beslag. Voor productie raden we Stack 8 aan, met twee keer zoveel geheugen als Stack 4.

Wat de app kost in drie formaten

De rekeningen hieronder gebruiken de prijzen van Laravel voor de regio US East (Virginia). Elke rekening gaat ervan uit dat je app op elk uur reageert en elke minuut een taak inplant, zodat rekenkracht en database de hele maand wakker blijven. We hebben het gebruikstegoed van $5 dat bij elk betaald abonnement hoort, ervan afgetrokken. Voor back-ups namen we de lage schatting, met snapshotopslag gelijk aan de data. S1 draait de worker op de eigen instance van 1 GiB van de app. Afgaand op onze testserver, waar de hele app inclusief database piekte op 572 MiB, heeft die instance daar ruimte voor. S2 en S3 zetten jobs op een beheerde queue, die volgens de documentatie van Laravel een aparte worker vervangt.

Zelfs de kleine rekening van S1 ligt boven de reguliere maandprijs van Stack 8, en het verschil groeit snel: S2 is ruim drie keer zo hoog. S3, ongeveer 11 keer zo hoog, betaalt voor twee replica's en een cache voor verkeer van gemiddeld zo'n 1,2 verzoeken per seconde, ver onder de 100 per seconde die onze testserver aankon. Op de server zou je geen Valkey-cache toevoegen, want Laravel 13 slaat cache, sessies en de queue standaard op in de database. Gebruik je Forge, tel dan bij alle drie de $12 per maand van Hobby op bij de serverprijs.

Het voorbeeld in de eigen documentatie van Laravel voor een Medium SaaS application valt lager uit, op ongeveer $53,90 per maand, omdat het de tarieven van US East (Ohio) gebruikt, de abonnementskosten weglaat en de rekenkracht 's nachts en in het weekend laat slapen.

In S1 en S2 kost de database meer dan de app-instance die hij bedient. Laravel MySQL blijft ook opslag en back-ups factureren terwijl de database slaapt. Back-ups kunnen oplopen tot $3,50 per maand als elke dagelijkse snapshot volledig is. Uitgaand dataverkeer is hier gratis, omdat de Flex 1 GiB-instance van S1 100 GB per maand bevat. Bij S3 is uitgaand dataverkeer de grootste gebruiksregel, omdat twee Pro-replica's maar 200 GB tegoed krijgen en de overige 800 GB $80,00 kosten. Op de LAMP Stack VPS betaal je niet per GB voor bandbreedte. Die is ongelimiteerd, zonder kosten voor overschrijding, onder de fair-use-voorwaarden van DreamHost.

De kosten van Forge komen bovenop een server

Forge kan via de optie Custom VPS werken op een server die je al huurt. Die server moet een verse installatie van Ubuntu 24.04 of 26.04 x64 zijn, met root-toegang via SSH. Forge installeert daarna zelf Nginx, PHP, de database en Redis. Bij DreamHost betekent dat een Ubuntu-VPS, verkocht tegen dezelfde Stack-prijzen als de LAMP Stack VPS. Het LAMP-image werkt niet, omdat Apache en MariaDB daarop bij levering al draaien. Twijfel je tussen de twee webservers, lees dan Apache of Nginx voor PHP.

Op een DreamHost-server kost Forge dus de abonnementskosten plus dezelfde Stack-prijs die je zou betalen om de app zelf te draaien. Daarvoor richt Forge de server in, deployt bij elke push en schrijft de Supervisor- en cron-regels, wat de meeste stappen hieronder dekt.

Wat je zelf draait op de LAMP-server

Onze testserver had deze vier stappen nodig bovenop Apache, MariaDB en PHP, zonder controlepaneel. Wil je toch een controlepaneel op de server, dan meet gratis cPanel-alternatieven op je eigen VPS wat HestiaCP, CloudPanel en Virtualmin aan geheugen en schijfruimte kosten. De paden gaan ervan uit dat je app in /var/www/app staat en draait als www-data.

1. Installeer Composer en Supervisor

   Beide staan in het eigen pakketarchief van Debian 13. Sla er een over als je server die al heeft.

   bashKopiëren

   sudo apt install composer supervisor

2. Voeg de queue-worker toe aan Supervisor

   Sla dit op als /etc/supervisor/conf.d/laravel-worker.conf. Het is het eigen voorbeeld van Laravel, met het pad, de gebruiker en het aantal workers aangepast voor één app. We hebben het log verplaatst naar /var/log, omdat Supervisor op onze testserver weigerde te starten zolang de logmap in de app nog niet bestond.

   iniKopiëren

   [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

   Laad het daarna met sudo supervisorctl reread, sudo supervisorctl update en sudo supervisorctl start "laravel-worker:*".

3. Voeg de cronregel van de scheduler toe

   Sla deze regel op als /etc/cron.d/laravel. Het is de enige cron-regel van Laravel, met het pad en de gebruiker ingevuld.

   bashKopiëren

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

4. Rol uit met een script

   Voer dit voor elke release uit vanuit de app-map. In onze drie runs duurde alles na de codewijziging ongeveer 1,5 seconde, het grootste deel composer install. Zo lang stond de site in onderhoudsmodus. De eerste deploy van een verse app duurde in onze twee runs 19 en 29 seconden, grotendeels doordat Composer pakketten downloadde.

   bashKopiëren

   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

Wanneer welke optie zinvol is

Op het formaat van S1 valt de rekening van Laravel Cloud iets hoger uit dan het reguliere maandtarief van Stack 8. Een app die zo klein is, past ook op Stack 4, die bij onze hoogste meting ongeveer 3 GB vrij houdt. De grotere verschillen beginnen bij S2, waar Stack 8 ruimte heeft om de app te laten groeien.

De support van DreamHost is 24/7 beschikbaar, en de hardware, het netwerk en de connectiviteit worden allemaal ondersteund door het team van DreamHost. Jij beheert het besturingssysteem, de software en de configuratie, wat hier de app betekent. In onze test werden Composer, Supervisor en cron één keer ingesteld, en elke release daarna was één script. Daarna bestaan de maandelijkse klusjes uit het installeren van OS-updates en controleren of de back-ups zijn gelukt.

Hoe we de app hebben getest en de prijzen hebben gelezen

DreamHost las de prijspagina's van Laravel Cloud, Forge en DreamHost op 20 oktober 2026 en hun documentatie tussen 19 en 21 oktober, en voerde de test uit op 20 oktober. We hebben elk DreamHost-abonnement, elke prijs en elke functie op deze pagina op 22 oktober 2026 opnieuw gecontroleerd aan de hand van de pagina's van DreamHost.

De testserver was een arm64-VM met 2 vCPU en 8 GB met Ubuntu 24.04, met de app in één container gebouwd met pakketten van Debian 13. Het was geen DreamHost-server en ook niet de LAMP-image van DreamHost, en de VPS-abonnementen van DreamHost draaien op AMD EPYC-processors.

De container draaide de pakketten Apache 2.4, PHP 8.4 en MariaDB 11.8 van Debian 13, met Laravel 13.38. In rust gebruikte MariaDB 123 MiB, Apache en PHP 123 MiB en de worker 55 MiB; die procescijfers delen geheugen, dus samen komen ze hoger uit dan het totaal van 208 MiB.

Elke belastingstap duurde één minuut. Bij de getimede redeploys verving een lokale codewijziging git pull. Er draaide niets op Laravel Cloud of Forge, dus hun kolommen zijn gebaseerd op gepubliceerde tarieven. De test laat echt verkeer, HTTPS, PHP-FPM of een server met 4 GB niet rechtstreeks zien.

Veelgestelde vragen over de kosten van Laravel-hosting