Laravel Cloud and Forge pricing vs your own server: what one app costs

Laravel Cloud bills compute by the second and stops billing compute while your app sleeps. It falls asleep only after a quiet stretch as long as its sleep timeout. Each scheduled task wakes it for that long again, so a task every 5 minutes on a 5-minute timeout never lets the environment sleep. If you schedule something every minute, you're billed as always on, up to Cloud's cap of 28 days per instance a month.

If your app can sleep most of the day, with nothing scheduled more often than its timeout and jobs on a managed queue, Laravel Cloud's Starter plan bills compute only for the time it's awake, plus the plan fee, the queue's operations and the database's storage and backups. Every bill below assumes your app never sleeps. If your app is a set of Docker containers rather than one Laravel app, what an always-on container costs on Fly.io, Cloud Run or Fargate prices the same never-sleeps problem on pay-per-use container platforms.

What one Laravel app used on our test server (not a DreamHost server)

We deployed a fresh Laravel 13 app to a test server, in one container built from Debian 13's own packages. It ran the same three programs the LAMP Stack VPS ships, but they were Debian 13's own Apache, MariaDB and PHP 8.4, not DreamHost's LAMP image. Supervisor kept one queue worker running, and one cron line ran the scheduler. The server had 2 vCPU, the same as Stack 4 and Stack 8.

At 200 requests a second that page's p95 rose to 160 ms, still error-free. The load generator was sharing the same two cores by then, so we'd expect a little better on a server where it isn't. A bare Laravel route with no database call stayed under 17 ms at the 95th percentile up to 400 requests a second. For scale, S3 below assumes 3 million requests a month, which average about 1.2 a second.

Even at that 572 MiB peak, Stack 4's 4 GB would leave about 3 GB free, by our arithmetic. But your production app will carry more code and data than our fresh install, and if you add workers for a busier queue, each takes about 55 MiB. For production, we'd put you on Stack 8, with twice Stack 4's memory.

What the app costs at three sizes

The bills below use Laravel's prices for its US East (Virginia) region. Each one assumes your app answers at any hour and schedules a task every minute, so compute and the database stay awake all month. We subtracted the $5 usage credit that comes with every paid plan. For backups we took the low case, with snapshot storage equal to the data. S1 runs the worker on the app's own 1 GiB instance. Judging by our test server, where the whole app, database included, peaked at 572 MiB, that instance has room for it. S2 and S3 put jobs on a managed queue, which Laravel's docs say replaces a dedicated worker.

Even the small S1 bill sits above Stack 8's regular monthly price, and the gap widens fast: S2 is over three times it. S3, at about 11 times, pays for two replicas and a cache to serve traffic that averages about 1.2 requests a second, far under the 100 a second our test server handled. You wouldn't add a Valkey cache on the server, because Laravel 13 stores cache, sessions and the queue in the database by default. If you use Forge, add Hobby's $12 a month to the server's price for any of the three.

Laravel's own docs example for a Medium SaaS application comes out lower, at about $53.90 a month, because it uses US East (Ohio) rates, leaves out the plan fee and lets compute sleep nights and weekends.

In S1 and S2 the database costs more than the app instance it serves. Laravel MySQL also keeps billing storage and backups while it sleeps. Backups could reach $3.50 a month if every daily snapshot were full size. Data out is free here because S1's Flex 1 GiB instance includes 100 GB a month. By S3, data out is the largest usage line, because two Pro replicas get only a 200 GB allowance and the other 800 GB cost $80.00. On the LAMP Stack VPS you don't pay for bandwidth by the GB. It's unmetered with no overage fees, under DreamHost's fair use terms.

Forge's fee comes on top of a server

Forge can work on a server you already rent through its Custom VPS option. That server must be a fresh Ubuntu 24.04 or 26.04 x64 install with root SSH access. Forge then installs Nginx, PHP, the database and Redis itself. At DreamHost that means an Ubuntu VPS, sold at the same Stack prices as the LAMP Stack VPS. The LAMP image won't do, since it arrives with Apache and MariaDB already running. If you're weighing the two web servers, see Apache or Nginx for PHP.

So on a DreamHost server, Forge costs its fee plus the same Stack price you'd pay to run the app yourself. For that fee, Forge sets up the server, deploys on push and writes the Supervisor and cron entries, which covers most of the steps below.

What you run yourself on the LAMP server

Our test server needed these four steps on top of Apache, MariaDB and PHP, with no control panel. If you'd like a panel on the server anyway, free cPanel alternatives on your own VPS measures what HestiaCP, CloudPanel and Virtualmin cost in memory and disk. The paths assume your app lives in /var/www/app and runs as www-data.

1. Install Composer and Supervisor

   Both are in Debian 13's own package archive. Skip either one if your server already has it.

   bashCopy

   sudo apt install composer supervisor

2. Add the queue worker to Supervisor

   Save this as /etc/supervisor/conf.d/laravel-worker.conf. It's Laravel's own example with the path, user and worker count changed for one app. We moved the log to /var/log, because our test server's Supervisor refused to start while the log folder inside the app didn't exist yet.

   iniCopy

   [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

   Then load it with sudo supervisorctl reread, sudo supervisorctl update and sudo supervisorctl start "laravel-worker:*".

3. Add the scheduler's cron line

   Save this line as /etc/cron.d/laravel. It's Laravel's one cron entry with the path and user filled in.

   bashCopy

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

4. Deploy with a script

   Run this from the app folder for each release. In our three runs, everything after the code change took about 1.5 seconds, most of it composer install. The site sat in maintenance mode for that time. The first deploy of a fresh app took 19 and 29 seconds in our two runs, most of it Composer downloading packages.

   bashCopy

   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

When each one makes sense

At S1's size, the Laravel Cloud bill comes out a little above Stack 8's regular monthly rate. An app that small also fits Stack 4, which keeps about 3 GB free at our highest reading. The bigger gaps start at S2, where Stack 8 has room for the app to grow.

DreamHost support is available 24/7, and the hardware, network and connectivity are all supported by DreamHost's team. You manage the OS, software and configuration, which here means the app. In our run, Composer, Supervisor and cron were set up once, and each release after that was one script. After that, the monthly chores are applying OS updates and checking that the backups ran.

How we tested the app and read the prices

DreamHost read Laravel Cloud's, Forge's and DreamHost's pricing pages on October 20, 2026, and their docs between October 19 and 21, and ran the test on October 20. We rechecked every DreamHost plan, price and feature on this page against DreamHost's pages on October 22, 2026.

The test server was an arm64 VM with 2 vCPU and 8 GB running Ubuntu 24.04, with the app in one container built from Debian 13 packages. It wasn't a DreamHost server or DreamHost's LAMP image, and DreamHost's VPS plans run on AMD EPYC processors.

The container ran Debian 13's Apache 2.4, PHP 8.4 and MariaDB 11.8 packages, with Laravel 13.38. At idle, MariaDB held 123 MiB, Apache and PHP 123 MiB and the worker 55 MiB; those process figures share memory, so they add up to more than the 208 MiB total.

Each load step ran for one minute. In the timed redeploys, a local code change stood in for git pull. Nothing ran on Laravel Cloud or Forge, so their columns come from published rates. The run doesn't show real traffic, HTTPS, PHP-FPM or a 4 GB server directly.

Laravel hosting cost FAQs