Moving from Laravel Forge and AWS to Laravel Cloud saved DropInBlog 50% in infra costs

DropInBlog was born in 2015 to solve one problem: clients had a site they liked and just needed a blog on it, and the only real option was bolting on WordPress. So Jesse Schoberg and his co-founders built a blog platform you could drop into any site.

Ten years later, that idea powers more than 2,000 blogs and 150 million requests a month, and the whole project runs on a two-person engineering team. The team had been using Laravel Forge to provision an autoscaling setup on AWS, but Forge did not handle the autoscaling piece itself, so that layer was still on them. When Laravel Cloud arrived, the case for consolidating into one Laravel platform made itself.

The entire migration took three weeks, from decision to fully running on Cloud. Here’s what changed for DropInBlog since the move:

• 50% reduction in infrastructure cost compared to the previous Laravel Forge and autoscaling AWS setup.

• 200 to 300 ms drop in API response times after enabling Laravel Octane on the API environment.

• Zero-downtime deployments replacing manual AMI (Amazon Machine Image, a snapshot AWS uses to launch new EC2 instances) creation that used to drop the primary server for several seconds on every large release.

• Three million background jobs per month now running on managed queues without a dedicated infrastructure engineer.

See how Forge and Cloud stack up.

About DropInBlog

DropInBlog has been bootstrapped from day one. Its blogs host 275,000 posts across a customer base that runs from solo founders to mid-market ecommerce and SaaS teams. Customers plug in through SDKs for Laravel, React, Next.js, Astro, and Express; a rendered API; a raw API; or a Model Context Protocol (MCP) server, and the platform also runs on Shopify and BigCommerce.

The company has six full-time staff and seven contractors, fully remote across the US, Europe, and Asia. Jesse is based between Bangkok and Hong Kong. CTO Jason Mayfield, based in Wisconsin, leads engineering and is the architect behind the platform and the migration to Laravel Cloud.

Life on AWS: The DevOps tax on a two-person team

The pre-Cloud setup was autoscaling EC2 instances behind a load balancer, originally configured by a consultant and then managed in-house. That setup worked but also demanded time that a two-developer team did not have.

"The primary problem was DevOps time," Jesse said. "We are not DevOps by nature, so removing that burden was important to us."

There was no dramatic outage that forced the move. DropInBlog was already provisioning through Laravel Forge and shipped a first-party Laravel package for customers, so the ecosystem fit was there. What Forge did not do at the time was autoscaling, so that piece stayed on the team's plate. That’s what Laravel Cloud changed.

"We felt this was a much more sustainable solution for our small team going forward," Jason said.

Migrating to Laravel Cloud in three weeks

DropInBlog split the migration by workload: one environment for the app (the admin and user panel), another for the API that serves blog content to public sites.

The app went first as a hard cutover, then the team let it sit for a couple of weeks to prove itself. Sessions and local cache moved off AWS DynamoDB and Redis onto a single Laravel Valkey instance in Cloud.

The API followed, with a few low-traffic domains moved first, then everything else. A handful of caching quirks turned up early and were resolved through environment settings. The database stayed put, as the team didn’t need to move their PlanetScale database (105 GB) since Laravel Cloud connected to it seamlessly.

The trickiest part was queues: going from one autoscaling server to two separate environments meant adjusting a few jobs, so they ran correctly across the split. "We had to make a few adjustments to some of our jobs to work correctly, but nothing crazy," Jason said.

The process took only three weeks. "We weren't necessarily surprised, but the simplicity of setting up an environment and deploying could not have been easier," he added.

What changed for the team

The former AWS setup required manually building an AMI on every deployment of any real size. That process would sometimes drop the primary server for several seconds while the image was created. On Laravel Cloud, deployments are quick and reliable, and no one is baking images by hand anymore.

The cost outcome was the biggest surprise for the team. "Honestly, the cost savings," Jesse said, when asked what surprised him most about Cloud. "That wasn't an important factor when considering. We did expect it to be a little less, but not 50%." Cost reduction was not part of the evaluation. The team expected the invoice to come down a bit and instead saw it drop by half.

Next, the team will focus on migrating a small white-label workload on AWS. Its next growth push is Mention Boost™, which structures posts to be more likely to get cited by ChatGPT, Google AI Overviews, and other AI engines, using patterns tested across the 2,000+ blogs on the platform.

"As we expand what Mention Boost™ does, we expect queue volume to climb well past the three million jobs a month we run today," Jesse said, "and being able to scale managed queues without touching infrastructure is what makes that a non-issue."

Serving 150 million requests a month with two developers

DropInBlog handles roughly 150 million requests per month at the Cloudflare edge and 16 million per month at the origin on Laravel Cloud. Traffic spikes come from two directions: Q4 ecommerce peaks around Black Friday and Cyber Monday, and sports customers who live-blog games and drive sharp bursts of publishing and reads in short windows.

Because nearly all public traffic is served from Cloudflare's cache, most spikes never reach the origin. The origin's job is to be fast for the reads that do get through and reliable for the writes.

Octane for API response times

The API environment serves blog content directly to customers' public sites, so latency at the origin matters even with heavy edge caching. Turning on Laravel Octane dropped response times by 200 to 300 milliseconds.

Laravel Nightwatch for finding slow routes

DropInBlog was already using Laravel Nightwatch before the migration and kept it on afterward. It has been especially useful for surfacing slow API endpoints that would otherwise hide behind the cache.

Managed queues for three million jobs a month

The three million monthly background jobs cover the expected work: imports, emails, webhooks, cache invalidation. The more interesting workload is Blog Pilot™, which analyzes a customer's site, finds topic opportunities backed by real search volume and keyword difficulty data, and turns them into outlines ready to write. All of that runs through managed queues.

Try Laravel Cloud

Jesse's advice for another SaaS team looking at the same migration is short: "Stop procrastinating and make the move. It's easier than you think."

His team cut infrastructure costs by 50%, reduced API response times by 200 to 300 milliseconds, and moved three million monthly background jobs to managed queues, all with a two-person engineering team and no dedicated infrastructure hire.

If you are running Laravel on Forge and AWS today, the Laravel Cloud migration guide is the fastest way to see what your own setup would look like. For more migration stories from Forge to Cloud, the Filament team also detailed their migration process and shared how their request speed tripled.