Same app. Three platforms. Completely different bills, cold start penalties, scaling behaviours, and developer experience. If your team is about to make a hosting decision that will cost you months to undo, read this first.
A hosting decision for a Laravel application used to be one question: Forge or Vapor? Now there are three first-party options, each with a genuinely different philosophy, a different cost model, and different constraints that will shape how you build your application for years.
I’ve run the same SaaS application — a mid-sized B2B platform with API traffic, background jobs, scheduled tasks, and occasional traffic spikes — on all three platforms in the last eighteen months. Not toy projects. Real deployments with real bills and real incidents.
This is what I actually found.
The One-Paragraph Summary of Each
Laravel Forge is not a hosting platform. It’s a server management tool. You bring your own server (DigitalOcean, Hetzner, Vultr, AWS EC2, Linode), and Forge handles the provisioning — Nginx, PHP, MySQL, queues, SSL, deployments, cron jobs. You have root access. You own the machine. You control everything.
Laravel Vapor is serverless deployment on AWS Lambda. You push code; Vapor packages it, uploads it to Lambda, and runs it without you ever thinking about a server. Traffic spikes? Lambda scales automatically. Traffic drops to zero? You pay nearly nothing. The trade-off: Lambda’s constraints become your constraints.
Laravel Cloud is the newest addition, launched in February 2025 and with restructured pricing in August 2025. It’s a fully managed platform — connect your GitHub repository, set your environment variables, deploy. No server provisioning, no AWS knowledge required, built-in databases, queues, cache, preview environments, custom domains, and SOC 2 Type 2 certification. Plans start at $5/month (Starter with usage-based billing) and scale to $20/month (Growth with autoscaling).
Laravel Forge: The Honest Picture
What It Actually Is
Forge provisions servers. When you add a new site on Forge, it:
- SSHs into your server
- Installs Nginx, PHP, MySQL/PostgreSQL, Redis, Supervisor
- Configures the PHP-FPM pool
- Sets up SSL via Let’s Encrypt
- Configures zero-downtime deployment hooks
After that, every deployment runs git pull, composer install, php artisan migrate, and a Supervisor reload. Straightforward and fully under your control.
The Cost Reality
Forge subscription: $12/month (unlimited servers)
Servers (your choice):
DigitalOcean 1 vCPU / 1GB RAM: $6/month
DigitalOcean 2 vCPU / 2GB RAM: $18/month
Hetzner CX22 (2 vCPU / 4GB): €4.39/month (~$5/month)
AWS t3.small (2 vCPU / 2GB): ~$15/month
Typical small production setup:
1× app server (2GB RAM): $18/month
1× database server (2GB): $15/month
Forge subscription: $12/month
Total: $45/month + your time
The “your time” part is real. Forge removes the hardest parts of server management, but you still own:
- OS security updates (Forge handles package management but you need to stay on top of it)
- Database backups and restore testing
- Horizontal scaling decisions (when and how to add more servers)
- Server monitoring and alerting
Forge’s Genuine Strengths
Flexibility without limits. Forge runs anything: Laravel, Symfony, WordPress, Statamic, vanilla PHP, Node.js, static sites. Custom PHP extensions? Non-standard Nginx configuration? Root access to install whatever you need? All fine. No platform constraints.
Predictable costs. A $18/month DigitalOcean droplet costs $18/month at 100 requests/day and $18/month at 10,000 requests/day. The only variable cost is if you need to scale up servers — which you control.
Agencies and freelancers. One Forge subscription manages unlimited servers across unlimited clients. Spinning up a new WordPress or Laravel site for a client takes minutes. The ROI on the $12/month subscription is obvious when you’re managing ten or more client servers.
Long-running processes. Queue workers run continuously, can run indefinitely, and are managed by Supervisor exactly as you configure them. No 15-minute execution limits. No cold starts on background jobs. A job that takes 2 hours runs for 2 hours.
Forge’s Real Weaknesses
Manual scaling. Traffic spike at 3am? Your server either handles it or it doesn’t. Scaling up requires you to add a server, update your load balancer, and wait for the new server to be provisioned — during the spike. Forge Pro and Business have some autoscaling on AWS with load balancers, but it’s more complex to set up than Cloud or Vapor.
DevOps knowledge required. Not expert-level DevOps, but you need to understand what PHP-FPM is, why Supervisor manages queue workers, what Nginx config does, and how to debug a server that’s running out of memory. Forge makes this easier. It doesn’t eliminate the need to understand it.
Laravel Vapor: The Honest Picture
What It Actually Is
Vapor deploys your Laravel application to AWS Lambda — the same Lambda that runs at the heart of Netflix, Airbnb, and thousands of other companies. Each request spins up a Lambda function, executes your application, and terminates.
You pay per invocation and per millisecond of compute time. When no requests are coming in, you pay nothing. When traffic spikes, Lambda scales to thousands of concurrent executions instantly — no servers to provision.
The Cost Reality
Vapor subscription: $39/month (required — includes the Vapor dashboard)
AWS Lambda: ~$0.0000002 per request (essentially free at low traffic)
AWS RDS Aurora: from $0.10/hour → ~$73/month minimum
AWS ElastiCache: from $0.017/hour → ~$12/month minimum
AWS S3: ~$0.023/GB/month
Realistic small production setup:
Vapor subscription: $39/month
RDS Aurora Serverless: ~$30-50/month (small app)
ElastiCache: ~$15/month
Lambda + CloudFront: ~$5-20/month
Total: ~$89-124/month at low traffic
Medium traffic app (~50k requests/day):
All of the above: ~$100-200/month
Vapor’s pricing strength is genuine traffic spikes: if your traffic varies 20× between idle and peak, you pay for that peak only when it happens. For steady-state workloads, you pay a premium for elasticity you don’t actually use.
The Cold Start Problem
This is the most misunderstood aspect of Vapor. A Lambda cold start happens when a new function instance is needed — either because no warm instances exist or because traffic exceeded available instances. Laravel’s bootstrap process (loading the service container, config, routes, service providers) is heavier than a typical Lambda workload.
Typical cold start on Vapor: 800ms - 2,000ms
Warm request response time: 50-200ms
"Pre-warmed containers" configured in vapor.yml:
→ Keep N Lambda instances warm at all times
→ Eliminates cold starts for sustained traffic
→ But you pay for those Lambda instances even at 3am with no traffic
Pre-warmed containers mitigate cold starts but increase cost, because you pay for Lambda capacity whether it serves a request or not. The decision is: pay for cold starts occasionally, or pay continuously to avoid them. Neither is wrong — it depends on your traffic pattern.
Vapor’s Genuine Strengths
True elastic scaling. A flash sale, a viral Twitter thread, a major press mention — Lambda handles it without you touching anything. 10 requests or 10,000 requests in a second: Vapor scales automatically. This is not achievable on a single server, and achievable on Cloud only within the autoscaling limits of your plan.
AWS ecosystem access. If your application already uses SQS, SNS, EventBridge, Aurora, or other AWS services natively, Vapor integrates them cleanly. Everything lives in one AWS account. IAM roles, VPC configuration, CloudWatch logs — all available.
Pay for what you use. An app with very low and very unpredictable traffic genuinely costs almost nothing. A development environment, a staging environment, a new feature that hasn’t launched yet — you’re not paying for idle capacity.
Vapor’s Real Weaknesses
The 15-minute Lambda limit. AWS Lambda has a hard maximum execution time of 15 minutes. Long-running jobs — large data imports, complex report generation, video processing — won’t work without architectural changes. The standard solution is to break jobs into smaller chunks or use a Fargate-backed queue for long-running work. This is solvable, but it’s non-trivial.
Stateless filesystem. Lambda functions are ephemeral. If your app writes temporary files, handles uploads locally, or uses SQLite, you need to rethink those patterns. All file operations must go through S3. Local file caching is not available. storage/app doesn’t persist between requests.
AWS knowledge requirement. Vapor is opinionated but not simple. You need an AWS account, IAM roles configured correctly, understanding of how RDS and ElastiCache are provisioned, and familiarity with CloudWatch for debugging. When something goes wrong in production at 3am, you need to navigate the AWS console.
Not Laravel-native. Vapor requires added configurations, with apps demanding stricter Laravel conventions. Some Laravel packages assume a persistent filesystem. Some assume a long-running process with state. These don’t work on Lambda without modification.
Laravel Cloud: The Honest Picture
What It Actually Is
Laravel Cloud is the newest kid on the block. Announced by Taylor Otwell at Laracon US 2024 and officially launched in February 2025, it’s a fully managed platform for deploying Laravel apps. Think zero DevOps, no server provisioning, and built-in services like databases, storage, caching, queues, and domain management.
Unlike Vapor, Cloud does not run on Lambda. It runs on traditional containers — meaning no cold starts, no 15-minute execution limits, no stateless filesystem constraints. You get the managed experience without the serverless trade-offs.
The Cost Reality (Post August 2025 Pricing)
Laravel Cloud restructured pricing on August 13, 2025. The current plans are:
Starter: Free + usage. Hibernation is enabled by default, custom domains included, and automatic deployments.
Growth: $20/month + usage. Autoscaling (up to 10x), pro compute sizes, dedicated worker clusters, preview environments, and access to Web Application Firewall configuration.
Starter plan (hibernation enabled):
Platform fee: $0 base
Usage: ~$0-15/month for low-traffic apps
Multiple apps on one account at minimal cost
Growth plan:
Platform fee: $20/month
Usage: depends on compute and traffic
Includes: autoscaling, preview environments, WAF
Business plan: Contact sales
Includes: VPC peering, dedicated infrastructure, advanced DDoS
One developer in the announcement thread shared they’re running seven apps with decent traffic for $6/month total using scale-to-zero. The hibernation model — containers pause when no traffic arrives — makes Cloud genuinely affordable for side projects and low-traffic applications.
Cloud’s Genuine Strengths
Zero-friction deployment. With Cloud, it’s one step — connect your repository, configure your environment variables, deploy. No server provisioning (Forge), no serverless architecture review (Vapor). If you’re building fast and want to ship fast, that matters.
No cold starts. Cloud runs containers, not Lambda functions. There’s no bootstrap latency per request. Laravel Cloud offers predictable performance without cold starts — a genuine advantage over Vapor for apps where consistent response time matters.
Preview environments. On the Growth plan, every pull request gets its own deployment environment. QA, client review, and integration testing happen on a real environment before anything merges to main. This is a development workflow feature with no equivalent on Forge or Vapor at this ease.
SOC 2 and compliance. Cloud’s SOC 2 Type 2 certification, built-in WAF, and managed security posture simplify compliance for teams in regulated industries. Forge and Vapor are equally capable but require you to configure and maintain compliance yourself.
No AWS required. Unlike Vapor, Cloud requires no AWS account. No IAM role configuration, no AWS console, no CloudWatch. Connect GitHub, deploy.
Cloud’s Real Weaknesses
Less control. Cloud abstracts away the server entirely. Developers who want full server control — Forge gives you root access and complete flexibility. Cloud abstracts that away by design. If you need custom Nginx configs, non-standard PHP extensions, or specific OS-level tooling, Forge is still the better choice.
Hibernation latency. On the Starter plan with hibernation enabled, a container that has been idle wakes up when a request arrives. This is getting faster, but there’s still a wake-up delay for apps that go completely idle. For a professional production application that needs to be always responsive, the Growth plan (always-on) or a pre-warmed configuration is required.
Newer platform. Cloud launched in February 2025. Forge has been around since 2013. Vapor since 2019. Cloud has less track record, fewer community troubleshooting resources, and a shorter history of incident handling at scale. This matters for risk-averse teams.
Head-to-Head: The Real Comparisons
Developer Experience
| Forge | Vapor | Cloud | |
|---|---|---|---|
| Time to first deploy | 20-40 min | 30-60 min | 5-10 min |
| AWS account required | No (unless AWS EC2) | Yes | No |
| DevOps knowledge needed | Moderate | High | Minimal |
| Debugging production issues | SSH + logs | CloudWatch + Vapor dashboard | Cloud dashboard |
| Custom server config | Full control | Limited (Lambda constraints) | Not available |
| Preview environments | No (DIY) | Available | ✅ Built-in (Growth) |
Scaling
| Forge | Vapor | Cloud | |
|---|---|---|---|
| Horizontal scaling | Manual (add servers) | Automatic (Lambda) | Automatic (Growth plan) |
| Traffic spike handling | Depends on server size | Scales to thousands instantly | Up to 10x on Growth |
| Long-running jobs | Unlimited duration | 15 minutes max | No hard limit |
| Cold starts | None | Yes (mitigable) | None |
| Scale to zero | No | Yes | Yes (Starter with hibernation) |
Cost Model
| Forge | Vapor | Cloud | |
|---|---|---|---|
| Entry cost | ~$18 server + $12 Forge | $39 Vapor + AWS fees | $0 (Starter) |
| Cost at low traffic | Fixed server cost | Very low | Very low (hibernation) |
| Cost at high traffic | Fixed (upgrade server) | Pay per invocation | Usage-based |
| Cost predictability | High | Low (spiky workloads) | Medium |
| Multiple apps | Cheap (one server) | Each app = own AWS resources | Multiple apps on one account |
The Decision Framework
Choose Forge when:
- You need root access, custom PHP extensions, or non-standard server configuration
- You’re an agency managing many different client sites (different stacks, different requirements)
- Cost predictability at scale is more important than scaling convenience
- You have DevOps comfort or a DevOps person on the team
- Your application has long-running queue jobs that exceed 15 minutes
- You need to deploy non-Laravel applications on the same infrastructure
Choose Vapor when:
- Your traffic varies 20× or more between idle and peak and you want to pay only for what you use
- You’re already deeply invested in the AWS ecosystem (SQS, EventBridge, Aurora native integrations)
- Your team has AWS knowledge and uses AWS for other services
- You need enterprise-grade Lambda scaling for genuinely unpredictable traffic
- You’re building event-driven applications that benefit from native Lambda integration
Choose Cloud when:
- You want to ship fast with zero infrastructure overhead
- Your team doesn’t have DevOps expertise and doesn’t want to build it
- Preview environments per PR are a priority for your development workflow
- Compliance (SOC 2) needs to be handled for you, not by you
- Engineering time is more expensive than infrastructure cost — Cloud’s higher base cost buys back developer hours spent on DevOps
The Migration Cost Nobody Talks About
The most important thing in this post: the cost of switching platforms is high and should factor into your initial decision.
Migrating from Forge to Cloud or Cloud to Forge is relatively painless — your application doesn’t need to change, just your deployment target.
Migrating to or from Vapor is expensive:
- Moving to Vapor requires auditing your codebase for local filesystem writes, long-running jobs, and packages that assume persistent processes
- Moving from Vapor requires reconsidering your queue architecture and any AWS-native integrations you’ve built into the application
Picking a hosting platform is one of those decisions that feels minor early on and becomes very expensive to undo later. If you’re uncertain between Cloud and Forge, choose Cloud and migrate to Forge later — the reverse is cheaper and easier. If you’re uncertain between Vapor and Cloud, choose Cloud unless you have a specific reason to need Lambda scaling.
My Honest Assessment After Using All Three
Forge is the right choice for mature teams with specific needs. It’s not “default to Forge” — it’s “choose Forge when you know you need what it provides.” Long-running jobs, custom server configuration, cost predictability at scale, multi-stack deployments. If these describe your project, Forge is the right answer.
Vapor is the right choice for specific workload types. Event-driven architectures, genuinely unpredictable traffic, AWS-native integrations. For most Laravel SaaS applications, Vapor’s constraints (cold starts, 15-minute limit, stateless filesystem) cause more problems than its elasticity solves. The AWS requirement and learning curve are real costs.
Cloud is the right choice for most teams starting in 2026. Zero DevOps overhead, no cold starts, preview environments, SOC 2 handled, $0 entry for low-traffic apps. When in doubt, start with Cloud. It has the fewest constraints, the clearest path to production, and you can always move to Forge later if cost or control become the priority.
The exception to “start with Cloud”: if you have a specific reason to need Vapor’s Lambda scaling (genuinely variable traffic at large scale) or Forge’s control (custom server configuration), start there. Don’t build on Cloud and then try to squeeze a 30-minute queue job into a platform that wasn’t designed for it.
The Final Word
All three platforms are actively developed. Laravel has confirmed all three platforms continue to receive active development, and Vapor recently shipped support for the al2023 Lambda runtime ahead of the Amazon Linux 2 deprecation on June 30, 2026. This is not a question of which platform is dying — it’s a question of which one fits your specific constraints.
The constraints that matter:
Do you need root access or custom server config?
→ Forge
Do you need to handle 100x traffic spikes unpredictably?
→ Vapor
Do you want to ship today with zero DevOps overhead?
→ Cloud
Do you have long-running jobs (>15 min)?
→ Forge or Cloud (not Vapor)
Do you need SOC 2 compliance handled for you?
→ Cloud
Are you managing 10+ client sites with different stacks?
→ Forge
Are you deep in the AWS ecosystem already?
→ Vapor
Pick the platform that fits your constraints — not the one with the best marketing, not the one your Twitter timeline is excited about this week, and not the one you saw in the last tutorial. The wrong platform doesn’t just cost money. It shapes every architectural decision you make for the next two years.