skip to content

Cloud, Forge & Vapor

2 roadmaps5 questions

Laravel Cloud runs an app fully managed, Forge provisions and deploys to servers you own, and Vapor runs it serverless on Lambda. Interviewers ask which fits a team's control, scale and budget.

on this pageshow

explore

questions

5

In the Laravel ecosystem, how do Laravel Cloud, Laravel Forge and Laravel Vapor differ in who runs the servers your app lives on?

level: juniorimportance: must knowfreq 50%

answer

  1. managed vs self-owned vs serverless
  2. Cloud: compute, databases, caches, storage
  3. Forge: VPS on DigitalOcean, Linode, AWS
  4. Forge installs Nginx, MySQL, Redis
  5. Vapor: AWS Lambda plus SQS

basics

~20 s

Laravel Cloud runs the app for you on fully managed, auto-scaling compute with managed databases, caches and object storage; Forge provisions and manages servers you own on a provider; Vapor deploys the app serverless onto AWS Lambda.

solid answer

~40 s

They sit on a spectrum of how much infrastructure you own. **Laravel Cloud** is fully managed: the platform supplies auto-scaling compute plus managed databases, caches and object storage, and it gracefully reloads long-running services on deploy by itself. **Laravel Forge** is server management: it creates VPS servers on providers such as DigitalOcean, Linode or AWS, installs Nginx, MySQL, Redis and the rest, and runs your site's deploy script, but the servers are yours to size and pay for. **Laravel Vapor** is serverless: the app runs as AWS Lambda functions in your AWS account, queued jobs ride on SQS, and only `/tmp` is writable. The interview point is matching control, scale and budget to the team.

go deeper

for a junior

Recall the one-line identity of each: Cloud is fully managed, Forge manages servers you own on a provider, Vapor is serverless on AWS Lambda.

for a middle

Explain what each changes for the app: who reloads workers after a deploy, where files live, how queued jobs run, and what Forge installs for you.

for a senior

Show you can map a workload to a product: bursty traffic, long-running jobs, many tiny sites, or a need for root access and custom extensions.

for a principal

Frame the choice as ownership and risk: who is paged at night, how cost scales with traffic, and how portable the app stays if you switch later.

## Three answers to one question Every Laravel app in production needs a PHP runtime, a web server, a database, a cache, something to process queued jobs and something to run the scheduler every minute. Laravel's first-party hosting products answer one question in three different ways: **who owns and operates those pieces?** | Product | What you get | Who owns the machines | Typical fit | |---|---|---|---| | **Laravel Cloud** | Fully managed, auto-scaling compute plus managed databases, caches and object storage | The platform | Teams that want no servers to patch or size | | **Laravel Forge** | Provisioning and management of VPS servers on a provider | You, through your provider account | Teams that want root access and predictable servers | | **Laravel Vapor** | Serverless deployment on AWS Lambda | AWS, inside your AWS account | Spiky traffic, teams already invested in AWS | ## Laravel Cloud: the platform runs everything The Laravel 13 deployment documentation describes **Laravel Cloud** as a fully managed, auto-scaling deployment platform tuned for Laravel, offering **managed compute, databases, caches and object storage**. You do not provision or patch servers; you describe the app and the resources it needs and the platform runs them. Two details show how tightly it is wired into the framework: - The docs say that on Cloud you do not need `php artisan reload` after a deploy, because Cloud gracefully reloads long-running services itself. On any other host you trigger that reload yourself and keep a process monitor that restarts what exits. - Laravel 13 ships an `Illuminate\Support\Facades\Cloud` facade (added in 13.27.0). `Cloud::hosted()` tells your code whether it is running on Cloud, and at boot the framework reads variables the platform injects to configure object-storage disks, a database read replica and managed queues without you editing config files. ## Laravel Forge: your servers, managed for you **Laravel Forge** is a VPS server-management platform. It does not host anything itself. Instead it: 1. Creates servers on infrastructure providers such as DigitalOcean, Linode, AWS and others, in your account with that provider. 2. Installs and manages the stack a Laravel app needs: Nginx, MySQL, Redis, Memcached, Beanstalk and more. 3. Runs a per-site deploy script when you deploy, so you control the exact release steps. Because the machines are ordinary servers, you keep full control: several small sites can share one server, you can install any PHP extension, and you can log in when something breaks. The flip side is that capacity planning, scaling out and keeping each server healthy remain your job. ## Laravel Vapor: serverless on AWS Lambda **Laravel Vapor** deploys the app onto **AWS Lambda**, with `laravel/vapor-core` (2.47 at the time of writing) providing the runtime inside each function. The consequences are the ones interviewers probe: - Each request or job is handled by a function invocation, so capacity follows traffic rather than a server count. - The filesystem is read-only apart from `/tmp`; vapor-core points Laravel's storage path at `/tmp/storage`, so uploads, file caches and file sessions must move to S3, DynamoDB, Redis or a database. - Queued jobs travel through **SQS** and are executed by invocations of a hidden `vapor:work` command, not by a `queue:work` daemon. Vapor suits bursty workloads and teams comfortable operating an AWS account, and it asks you to design around those constraints. ## What stays the same The application code is still ordinary Laravel 13: routes in `routes/web.php`, the `bootstrap/app.php` builder, Eloquent, queued jobs and the scheduler. What changes is configuration (which filesystem disk, cache store, session driver and queue connection are active) and which operational chores you own. An app that already reaches files through the `Storage` facade and picks its drivers from environment variables can move between the three with few code changes. ## Common confusions - **Forge is not a host.** It manages servers you rent elsewhere; stop paying the provider and the site is gone even though Forge still lists it. - **Vapor is not Docker on a VPS.** It runs on Lambda; there are no long-lived worker processes and no durable local disk. - **Cloud is not Forge with autoscaling bolted on.** The platform owns and operates the compute; you manage the app and its resources, not machines. - **Laravel Sail is none of these.** Sail is a Docker-based local development environment, not a production host.

  • Can one Forge-managed server host several Laravel apps at once, and what is the catch?
    Yes. Forge manages sites on a server, so several apps can share one VPS, each with its own Nginx site and deploy script. That is cheap for small apps, but it couples them: one app's CPU, memory or disk pressure slows its neighbours, and a server outage or a bad OS upgrade takes every site on it down together.
  • What does Laravel Cloud manage beyond running your PHP code?
    The Laravel 13 docs list managed databases, caches and object storage alongside compute. The framework cooperates: on Cloud it reads platform-injected settings to register object-storage disks, a database read-replica host and managed queues (exposed through the `Cloud` facade), and the platform reloads long-running services on deploy, so no `php artisan reload` step is needed.

saying these in an interview costs you the question

  • Forge hosts your app on Laravel's own servers.
  • Vapor is Forge with Docker containers on a VPS.
  • On Laravel Cloud you still patch and size the underlying servers yourself.
  • Laravel Sail is the production hosting option for Laravel apps.
  • On Vapor you can keep saving uploads to the local disk as usual.
open as a page

An app deployed on Laravel Vapor loses user uploads and file-cache entries between requests; why does that happen, and what should it use instead?

level: middleimportance: should knowfreq 30%

basics

~20 s

On Vapor the app runs on AWS Lambda, where only /tmp is writable; vapor-core moves the storage path to /tmp/storage, which belongs to one short-lived container. Keep files on S3 and cache and sessions in DynamoDB, Redis or a database.

open as a page

Laravel Vapor runs no long-lived queue:work process; how are queued jobs and scheduled tasks executed there, and what does that change operationally?

level: seniorimportance: should knowfreq 25%

basics

~20 s

On Vapor, each SQS message triggers a Lambda invocation that runs the hidden vapor:work command to process that one job, and a per-minute invocation runs vapor:schedule, which calls schedule:run. There are no worker daemons to supervise or restart.

open as a page

A small agency must host twenty client Laravel apps of very different sizes; how would you choose between Laravel Cloud, Forge-managed servers and Vapor?

level: principalimportance: should knowfreq 20%

basics

~20 s

Tier the portfolio: pack small, steady sites onto a few Forge-managed servers for cost and control, put spiky or high-stakes apps on Laravel Cloud to offload operations and scaling, and use Vapor only where serverless scaling on AWS outweighs its constraints.

open as a page

In Laravel 13, what can the Cloud facade tell your code, and what does the framework configure automatically when an app runs on Laravel Cloud?

level: middleimportance: nice to knowfreq 12%

basics

~20 s

Laravel 13's Cloud facade offers hosted(), usesManagedQueues(), queue() and isManagedQueue(); separately, on Cloud the framework reads platform-injected variables to set up object-storage disks, a read replica, Postgres pooling, a managed cloud queue connection, logging and exception reporting.

open as a page