Versión en español aquí.
Spoiler: It’s not just about saving money—though my wallet isn’t complaining.
Picture this: you've built a shiny Laravel app—your magnum opus, a digital Swiss Army knife with features so sharp they could cut through butter... or user feedback. But there's a catch. Every month, you're stuck paying for an EC2 instance that’s as underutilized as a gym membership after January. Meanwhile, scaling feels like trying to parallel park a cruise ship during a hurricane.
Been there? I have too.
Three years ago, I did something that most developers would call madness: I deployed PHP on AWS Lambda. "PHP? On serverless? That's like putting pineapple on pizza!" they said.
But here I am, three years later, eating my pineapple pizza with pride. Let me tell you why serverless Laravel is the cloud upgrade you didn't know you needed.
1. The Problem with Traditional Laravel Hosting
(or: Why my EC2 instances were having an existential crisis)
Before serverless, my Laravel app lived on EC2. For the uninitiated, EC2 is Amazon’s version of a virtual private server, where you rent a slice of a machine to run your code. Sounds nice, right? Until reality hits you harder than a rogue composer update.
a) First there is: The Cost of Breathing
Running an EC2 instance is like owning a Tesla you keep running 24/7, just in case you feel like driving. My app wasn’t always busy, but that didn’t stop the meter from ticking. Between EC2 instances, load balancers, and shared storage, I was shelling out around $110/month for a server stack that spent most of its time idling. My wallet? Doing a Titanic impression.
I know, it’s not much in the grand scheme of things, but as a solo developer/entrepreneur, every dollar counts.
b) Then is: The Scaling Nightmares
EC2 instances are like that one friend who overreacts to everything.
- Traffic spike? "I'll crash now, thanks!"
- Traffic hush? "I’ll keep burning your money anyway!"
Managing autoscaling felt like teaching a fish to juggle—it's possible, but at what cost? Manually tweaking scaling groups, configuring load balancers, and praying I didn’t overprovision felt like a second job I never applied for.
c) And lastly DevOps: The Unpaid Intern
Nobody told me Laravel development came with a side of sysadmin responsibilities:
- Applying security patches.
- Debugging nginx/apache configs at 3 AM.
- Whispering sweet nothings to
sudocommands, hoping they’d work this time.
I didn't sign up for this life.
That’s when I started exploring alternatives, and serverless stood out as the perfect fit for solving these headaches.
2. AWS Serverless: PHP’s Cloud Glow-Up
Let’s clear up a myth: serverless doesn't mean "no servers". It just means the servers are someone else's problem. In this case, AWS does the heavy lifting while I focus on what I actually enjoy—coding.
a) Lambda: The Event-Driven Wizard
AWS Lambda is like a superhero that only shows up when you need it. It executes your code in response to events—HTTP requests, SQS messages, cron jobs, you name it. And when the job's done, it disappears faster than a free pizza at a dev meetup.
- No idle costs: Pay only for execution time (measured in milliseconds).
- Auto-scaling magic: Got a 100,000 requests spike? Lambda handles them without breaking a sweat (or your bank account).
- Stateless by design: It's like a clean slate every time—a design that forces you to think modularly.
b) Managed Services: The Unsung Heroes
Serverless isn't just Lambda—it's an ecosystem. AWS replaces your DIY infrastructure with managed services that "just work":
- Database: Serverless-friendly options like Aurora Serverless (MySQL/Postgres) for SQL lovers.
- S3: Store your files without worrying about running out of disk space.
- SQS: Decouple long-running jobs and process them asynchronously.
c) The PHP Paradox
I have to admit it: PHP wasn't born for serverless. It's like asking a fish to climb a tree—it'll complain, but it'll eventually get there. Laravel, traditionally reliant on PHP-FPM, needed some love to thrive in Lambda's ephemeral world:
- Sessions: Move them to an external database, like MySQL or Redis.
-
File storage: Reroute all storage operations to S3, using Laravel’s
Storagefacade. - Queue handling: Set up SQS as the default queue driver for async task execution.
- Caching: Leverage external services like Redis or DynamoDB instead of local storage.
- Boot time optimization: Minimize cold starts by trimming fat (unused dependencies).
-
Environment variables: Replace
.envfiles with AWS Secrets Manager or Parameter Store for secure and centralized configuration management.
Keep in mind that serverless isn't just about swapping out servers for Lambda functions. It’s about rethinking your architecture—letting AWS handle the operational pain points while you focus on building.
3. How Serverless Unlocks Laravel’s Full Potential
So, does serverless Laravel actually deliver on its promises?
Serverless isn't just a buzzword—it's a game-changer. The beauty of serverless Laravel lies in its ability to solve the pain points of traditional hosting while enabling faster, more scalable, and cost-effective solutions. But the real magic happens when you dive into how these benefits come together. Let’s break it down.
a) Cold Starts: Separating Fact from Fiction
Cold starts occur when Lambda initializes a new instance. Think of it as PHP waking up from a nap. Critics treat them like the apocalypse, but they’re manageable:
- Reality: Typical cold starts with PHP + Laravel are ~3-5 seconds.
-
Solutions:
- Laravel Octane: Keeps the app alive between requests, reducing boot times. The subsequent requests are processed in ~200ms or less.
- Provisioned Concurrency: AWS pre-warms instances for critical endpoints (costs extra, but worth it for critical endpoints).
For most apps, sub-3s delays during low traffic are acceptable. Most users won't notice a cold start, especially during peak traffic loads when Lambda stays warm.
b) Scaling Without Tears
Scaling in traditional hosting often feels like fighting a never-ending battle. With serverless, scaling becomes effortless—no more tweaking auto-scaling rules or crossing your fingers during a traffic surge. AWS Lambda eliminates the guesswork, scaling horizontally by default.
Here's an example:
- Scenario: Your app goes viral 🚀 yey!.
- Old EC2 Setup: It starts getting latency, you scramble to log into AWS, manually adjust instance counts, and hope for the best 🫠. Oh, and don't forget to balance those instances properly across availability zones.
- New Lambda Setup: AWS automatically spins up as many instances as needed, handling thousands of concurrent requests without you lifting a finger. You grab popcorn and watch CloudWatch metrics like it’s a Netflix series 🍿.
This isn’t just convenience—it’s peace of mind. While you focus on celebrating your app's success, Lambda does the heavy lifting. And the best part? You’re billed only for the compute time you use, not for the idle capacity you might need "just in case".
c) Cost Efficiency: The Real MVP
Serverless doesn't just save money—it’s like having a $5 buffet where you only pay for what you eat.
- My old EC2 setup: ~$110 /month.
- 4x EC2 t3.small instances: $60.00
- 1x Load Balancer: $16.40
- 1x EBS (shared storage between EC2 instances): $7.80
- 1x RDS MySQL instance (db.t4g.medium): ~26.00
- Lambda: ~$34 /month (a 60% saving!).
- Lambda, API Gateway ~2.5M requests (~500ms / 512MB memory) /month: $4.80
- Managed services (S3, SQS, CloudWatch): ~$2.90
- RDS MySQL instance (db.t4g.medium): ~26.00
| Resource | EC2 Cost | Lambda Cost |
|---|---|---|
| Compute | $60.00 | $4.50 |
| Networking (LB, API Gateway) | $16.40 | $0.30 |
| Storage | $7.80 | $2.90 |
| Database | $26.00 | $26.00 |
| TOTAL | $110.20 | $33.70 |
In short, serverless doesn’t just save money—it frees up mental bandwidth. The fewer resources I waste worrying about over-provisioning, the more I can focus on building something amazing.
At that time, I was still using a MySQL instance as database engine. Later posts will explore migrating the database engine to DynamoDB to cut costs further.
d) Maintenance Freedom: Say Goodbye to Ops Nightmares
Serverless freed me from the shackles of server maintenance. Here’s how:
- No more manual updates: AWS handles server patching, operating system updates, and runtime upgrades, meaning you’re always running on secure, up-to-date infrastructure.
- Simplified configurations: With services like API Gateway and S3, the complexity of managing nginx configs and custom deployments becomes a thing of the past.
- Elastic capacity: Forget overpaying for unused server resources or scrambling to provision more during traffic spikes. Lambda automatically scales to meet demand and stops billing when idle.
- Focus on features, not firefighting: The time I once spent applying patches or debugging production issues now goes into building features and improving user experience.
Serverless doesn't just reduce maintenance; it removes the operational distractions that keep you from coding.
4. But, "Is Serverless Laravel for Everyone?"
As revolutionary as serverless Laravel is, it's not a one-size-fits-all solution. For some apps, the stateless, event-driven nature of serverless can feel like a dream come true. For others, it might feel like trying to fit a square peg into a round hole. Before you jump on the serverless bandwagon, let’s take a step back and evaluate whether it’s the right fit for your project.
a) Statelessness: The Double-Edged Sword
Laravel loves stateful operations like storing files locally and caching sessions in the filesystem. To go serverless you must change:
- Sessions: Use databases (MySQL/Postgres), or Redis—no more filesystem reliance.
- Files: Reroute uploads to S3, or bypass Laravel entirely via pre-signed S3 URLs.
- Logs: Configure Laravel to stream them to CloudWatch.
-
Configuration: Move
.envvariables to AWS Secrets Manager or Parameter Store for centralized management. - Queues: Migrate jobs to AWS SQS for scalable queueing and message handling.
b) Vendor Lock-In Considerations
AWS services are magical, but they’re also proprietary:
- Migrating from SQS to Redis queues? Have fun rewriting code.
- Want to move from Lambda to Docker? Grab a coffee—it’ll be a long night.
c) When Not to Go Serverless
Serverless isn’t a silver bullet for every workload, you should consider avoiding it if:
- You need WebSockets: While achievable with services like API Gateway + WebSocket APIs or third-party tools like Ably, it adds complexity.
- Your app has heavy computational workloads: Tasks like AI/ML inference or video encoding may hit Lambda’s 15-minute timeout.
- You rely on stateful services: Applications that assume a persistent disk or server state can be costly to refactor.
5. What’s Next?
Serverless Laravel has the potential to transform the way you build and deploy applications, but the real magic is in the implementation. Are you ready to make the leap and give your Laravel app the serverless treatment? Stay tuned for Part 2, where I'll walk you through the exact steps to bring this architecture to life.
Question for you: What’s your biggest serverless fear? Share below—I’ll tackle the top 3 in Part 2!
Top comments (1)
My biggest fear for these headless things is that the cost will skyrocket due to carelessness
(I clarify that I know absolutely nothing about serverless, but I hear lambda and I get scared
😣 mostly because of my pure ignorance)
For example, the post talks about a budget of 34 dollars per month
My fear is that the end of the month comes and you have a bill of 3,000 USD or more...
Something that doesn't happen with fixed instances of amount x per minute computed per month...