Category: Laravel Cloud

Laravel now ships with three first-party hosting products. Which means a question that used to have one obvious answer — “where do I deploy this?” — now has three very different answers depending on what you’re building, how your team is structured, and what you want to own versus hand off.

This post is for technical founders and CTOs who need to make that call cleanly. No hand-waving. Just the real tradeoffs between Forge, Vapor, and Cloud, and a clear decision framework for 2026.

Short Version (If You’re in a Hurry)

If you need a decision right now:

Now let’s go deeper on each one.

Laravel Forge: Baseline

Forge has been around since 2013. It’s the most mature of the three and the one most Laravel developers have used at some point.

Here’s what it actually is: a server provisioning and management tool. Forge doesn’t host your app, it configures and manages VPS servers on your cloud provider of choice (DigitalOcean, AWS, Linode, Vultr, Hetzner). You own the server. Forge handles the Nginx config, SSL, queue workers, scheduled tasks, and deployments.

What makes it good:

Full control is the real value proposition. You choose the server size, the cloud provider, the database setup. You can SSH in and do anything. For teams with someone who knows Linux and doesn’t mind infrastructure work, Forge gives you the best price-to-performance ratio of any Laravel hosting option especially on providers like Hetzner where a capable server costs a fraction of AWS equivalent.

Forge also handles zero-downtime deployments natively, manages multiple servers from one dashboard, and lets you run multiple sites on the same server. It’s genuinely well-built for what it does.

Real tradeoffs:

You’re renting a server that runs 24/7 whether you’re getting traffic or not. At low traffic, that’s inefficient. At unpredictable traffic spikes, you’re either over-provisioned (wasting money) or under-provisioned (slow response times). Scaling requires you to provision new servers, configure load balancing, and manage horizontal scaling yourself or set up auto-scaling manually through your cloud provider.

The other constraint is operational overhead. Forge automates the provisioning, but someone on your team still needs to monitor servers, handle failures, and manage backups. For a startup with no dedicated DevOps, that’s a meaningful hidden cost.

Forge is the right call when:

• You have a traditional app with relatively predictable traffic
• You have someone on the team comfortable with servers
• Cost control matters and you want the cheapest path per request at scale
• You need full root access and custom server configurations
• You’re running a database-heavy app where serverless cold starts would be painful

Typical cost: $12–$20/month Forge subscription + your server costs (as low as $6/month on Hetzner for a small app, up to hundreds on AWS at scale).

Laravel Vapor: Serverless for Laravel

Vapor launched in 2019 and was a genuinely interesting bet, take a framework built for traditional servers and make it run seamlessly on AWS Lambda. For a certain class of applications, it’s still the best option in the Laravel ecosystem.

What makes it good:

You pay for what you use. If your app gets zero traffic at 3 AM, you pay nothing for those hours. If it gets a 10,000-request spike at noon, it scales instantly to handle it without you touching anything. There’s no server to provision, no Nginx config to worry about, no queue worker processes to monitor.

Vapor also handles assets on CloudFront (CDN), databases on RDS, caches on ElastiCache, and queues through SQS all AWS-native infrastructure, all managed through the Vapor dashboard. For apps that need to scale unpredictably and quickly, this is genuinely powerful.

The operational simplicity for teams without DevOps is real. You push code, Vapor deploys it. That’s most of what you need to know.

Real tradeoffs:

Serverless has constraints that matter for Laravel specifically:

Cold starts. Lambda functions spin up on demand, and there’s a startup latency when a function hasn’t been called recently. Laravel’s bootstrap process loading the service container, config, routes is heavier than a Node.js function. Vapor has gotten better at managing this, but cold starts are still a real thing for infrequently-hit endpoints.

The 15-minute execution limit. Lambda functions have a hard ceiling on execution time. Long-running queue jobs, heavy report generation, or anything that takes more than 15 minutes won’t work without architectural changes.

File system access. Lambda is stateless and ephemeral, you can’t write to the local disk in the traditional sense. If your app writes temporary files, handles uploads locally, or uses SQLite, you need to rethink those patterns.

AWS vendor lock-in. Vapor is AWS-only. Your database is RDS, your cache is ElastiCache, your storage is S3. If you ever want to move away from AWS, you’re untangling a lot of infrastructure.

Cost at scale. Serverless is cheaper than an idle server at low traffic. But at sustained high traffic, Lambda invocations add up. For a high-throughput app running 24/7, a provisioned server on Forge or Cloud is often cheaper per request.

Vapor is the right call when:

• Traffic is genuinely spiky and unpredictable (marketing sites, event-driven apps, tools that get Product Hunt traffic)
• Your team has zero DevOps and wants to hand all infrastructure management to AWS
• You need instant auto-scaling without any configuration
• Your workloads fit within Lambda’s execution model (short jobs, stateless handlers)

Typical cost: $39/month Vapor subscription + AWS usage costs (varies widely could be $20/month for a small app, could be $500+ for a high-traffic one).

Laravel Cloud: New Default

Laravel Cloud launched in 2024 and is the most interesting development in the Laravel hosting space in years. It’s not Forge (you don’t manage servers) and it’s not Vapor (it’s not serverless Lambda). It sits in the middle and that middle is where most modern web apps actually live.

What makes it good:

Cloud runs your app in containers that auto-scale based on traffic. You don’t manage servers, but you also don’t have serverless constraints. There are no cold starts. There’s no 15-minute execution limit. Your app runs like it always has, it just lives in an environment that scales up and down automatically.

The experience is closer to modern PaaS platforms like Railway or Render, but built specifically for Laravel by the people who build Laravel. The deploy experience is clean: connect your repository, configure your environment, push code. Cloud handles the containers, the load balancing, the scaling, and the infrastructure.

The integration with the Laravel ecosystem is the real differentiator. Pulse works natively. Horizon is first-class. Queues, scheduled tasks, and broadcasting are all configured from the same dashboard. There’s no hunting for the right AWS service or translating Laravel concepts into cloud infrastructure primitives.

What Cloud means for your workflow:

Traditional hosting (Forge) requires you to manage infrastructure. Serverless (Vapor) requires you to adapt your code to serverless constraints. Cloud requires neither. You write Laravel the way you always have, and the hosting environment handles the rest.

For founders and CTOs who want to stay focused on product rather than infrastructure, this is a significant unlock.

Real tradeoffs:

Cloud is newer. Forge has 10+ years of production hardening. Vapor has been running serious workloads since 2019. Cloud’s maturity will grow, but if you’re running a critical system today, that track record matters.

Cost at scale is still being established. Cloud’s pricing is designed to be competitive, but as with any managed platform, you pay a premium for the abstraction compared to raw VPS on Forge. For high-throughput apps where margin matters, the math needs to be done carefully.

Control is also limited by design. You’re running in Cloud’s container environment, you can configure your app, but you can’t SSH into the underlying infrastructure or install arbitrary system packages.

Cloud is the right call when:

• You want managed infrastructure without serverless constraints
• Your team shouldn’t be spending time on DevOps
• You’re starting a new Laravel app and want the cleanest path to production
• You need auto-scaling but don’t want to architect around Lambda limitations
• You’re building with LaraCopilot (Cloud is the native deploy target)

Typical cost: Starting from around $20/month for small apps, scaling with usage. Laravel has positioned this competitively against Vapor.

Real Comparison: What Actually Matters

Past the feature list, here are the five decisions that actually determine which platform is right:

1. Ops ownership

Forge: Your team owns the servers. Forge automates setup, but you’re responsible for what happens on those servers.

Vapor: AWS owns the infrastructure. Vapor owns the configuration. You own the code and deployment config.

Cloud: Laravel’s team owns the infrastructure. You own the code and environment config.

If you have no one who wants to manage infrastructure, Forge is the wrong choice. Cloud and Vapor both take that off your plate entirely.

2. Traffic patterns

Predictable, steady traffic: Forge wins on cost. A right-sized server running constantly is efficient.

Spiky, unpredictable traffic: Vapor or Cloud. Auto-scaling means you don’t overprovision for the peaks or underperform during them.

Sustained high traffic 24/7: Run the numbers carefully. Forge with a well-sized server or Cloud at scale can be cheaper than Lambda invocations adding up on Vapor.

3. Application architecture

Traditional Laravel app (sessions, file storage, long-running jobs): Forge or Cloud. Vapor requires architectural changes for these patterns.

API-heavy, stateless, short-lived handlers: All three work, but Vapor’s strengths shine here.

Unknown at this stage: Cloud. It imposes fewer constraints than Vapor and less ops overhead than Forge.

4. Team size and expertise

Solo founder or small startup (1–5 people): Vapor or Cloud. No one should be spending nights dealing with server incidents.

Mid-size team with a DevOps person: Forge becomes viable again. The control is worth it if you have someone to use it.

Enterprise / large team: Often Forge for control, or a custom AWS setup with Vapor for serverless workloads. Cloud’s managed approach is also compelling for teams that want to consolidate.

5. Cost ceiling

At low traffic: Vapor and Cloud can be cheaper than a Forge server running idle.

At medium traffic: Similar across all three with different tradeoffs.

At high, sustained traffic: Forge with a well-configured server or multi-server setup typically wins on pure cost. You’re trading money for engineering time.

Migration: Can You Switch?

One question CTOs often ask: if we start on X, can we move to Y later?

Forge → Cloud: Relatively straightforward. Your app code doesn’t change. You’re moving to a different hosting environment. The main work is updating deployment scripts and environment config.

Forge → Vapor: More work. Serverless constraints may require code changes — file handling, long-running jobs, session management. Plan for a few days of adaptation work minimum.

Vapor → Cloud: Probably the smoothest migration path. Moving from serverless to Cloud removes Lambda constraints rather than adding them. Your app’s architecture translates well.

Cloud → Forge: Straightforward. If you eventually want more control or a specific cost profile, moving to Forge is an infrastructure configuration change, not a code change.

The least reversible choice is Forge → Vapor (because of the code changes serverless requires). Starting on Cloud gives you the most flexibility to move in either direction later.

Where LaraCopilot Fits

If you’re using LaraCopilot to build your app, Cloud is the native deploy target. The reason is architectural alignment: LaraCopilot generates standard Laravel applications without serverless constraints, so Cloud’s container-based auto-scaling is the right environment.

More practically: the path from “app generated in LaraCopilot” to “app running in production” should be as short as possible. 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. A deployment model that adds friction between “built” and “live” is a speed tax you don’t want to pay.

You can read more about the one-click deployment flow here: How LaraCopilot Deploys to Laravel Cloud

Decision Framework

Use this when making the call:

Start here: Does your team have someone who wants to manage servers?

• No → Go to Cloud or Vapor
  • Does your app have serverless-unfriendly patterns (long jobs, file system writes, sessions)?
    • Yes → Cloud
    • No → Evaluate Vapor (better for spiky traffic) vs Cloud (fewer constraints)
• Yes → Go to Forge or Cloud
  • Do you need root access or custom server configuration?
    • Yes → Forge
    • No → Cloud (you get managed infra without the ops burden)

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.

Bottom Line

In 2026, you have three first-party Laravel hosting options, and they genuinely serve different needs.

Forge is for teams who want control and have someone to exercise it. Best price at scale, most flexibility, most operational ownership.

Vapor is for apps with spiky traffic built in a serverless-compatible way. Best auto-scaling story, zero infrastructure to manage, AWS-native.

Cloud is for teams who want production-grade managed hosting without serverless constraints. The cleanest path from Laravel code to running app.

If you’re starting something new today, especially if you’re building with an AI tool like LaraCopilot, Cloud is where you want to be. The infrastructure is handled, the scaling is automatic, and the time between “built” and “live” is measured in minutes.

1-Click Deploy to Cloud →