skip to content

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%

answer

  1. who operates it, who gets paged
  2. Forge: pack small sites per server
  3. Cloud: managed resources, autoscaling
  4. Vapor: bursty, AWS account, /tmp, SQS
  5. portability through env-driven drivers

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.

solid answer

~50 s

I would not pick one platform for twenty different apps; I would tier them by traffic shape, criticality and who pays. Small brochure sites and low-traffic back offices go several-per-server on **Forge**-managed VPS servers: cheapest per site, full control, but the agency owns patching, backups and noisy-neighbour risk. Apps with real traffic, growth or uptime promises go to **Laravel Cloud**, where managed compute, databases, caches and object storage plus automatic reloads remove most operations work at a higher per-app cost. **Vapor** is for the few apps with sharp spikes or a client already on AWS, provided they tolerate `/tmp`-only writes, SQS queues and time-limited jobs. Whatever the tier, I keep every app portable: files through the `Storage` facade, drivers chosen by environment variables, no local-disk state, so moving a client later is configuration rather than a rewrite.

go deeper

for a junior

Recall the basic split: Forge manages your servers, Cloud is fully managed, Vapor is serverless on AWS Lambda.

for a middle

Explain what each platform changes for a single app: storage, queue workers, deploy reloads, and who maintains the server.

for a senior

Show you can assess an app's readiness for each host, such as local-disk writes, job durations and traffic spikes, and plan a migration between them.

for a principal

Own the portfolio policy: tier by criticality and traffic, balance cost against on-call burden and blast radius, and keep apps portable as clients change.

## The real question: who operates what For an agency, hosting is not a technology choice made once; it is an **operating commitment** repeated twenty times. Each Laravel app needs PHP, a web server, a database, a cache, workers for queued jobs and a scheduler. The three Laravel platforms differ mainly in **who operates those pieces** and **how cost follows traffic**: - **Laravel Forge** provisions and manages VPS servers in the agency's (or client's) provider account and installs Nginx, MySQL, Redis and friends. The agency owns the servers. - **Laravel Cloud** is fully managed and auto-scaling, with managed compute, databases, caches and object storage; it also reloads long-running services on deploy. - **Laravel Vapor** runs apps serverless on AWS Lambda in an AWS account you connect, with SQS queues and a `/tmp`-only filesystem. ## Decision axes | Axis | Forge-managed servers | Laravel Cloud | Vapor | |---|---|---|---| | Who is paged when a box dies | the agency | the platform, for infrastructure | AWS and the platform, for infrastructure | | Cost for many tiny sites | low: several sites share one server | per app and per resource | low when idle, per invocation | | Traffic spikes | capacity you pre-provision | autoscaling | scales per request | | Control (extensions, OS, root) | full | limited to what the platform exposes | limited to what Lambda allows | | Code constraints | none beyond normal Laravel | few | durable storage off-box, jobs within the function time limit | | Client handover | hand over provider account or server | transfer the app | hand over the AWS account | No column wins everywhere, which is why a portfolio usually mixes them. ## A tiered recommendation 1. **Tier A: small and steady.** Brochure sites, internal tools, low-traffic CMS installs. Put several per Forge-managed server, grouped by client or by risk. Accept noisy-neighbour risk in exchange for the lowest cost per site, and budget time for OS updates, backups and monitoring. 2. **Tier B: business-critical or growing.** E-commerce, SaaS products, anything with an uptime promise in the contract. Put these on Laravel Cloud so autoscaling, managed databases and caches, and deploy-time reloads are not the agency's night shift. Bill the client for the platform cost directly. 3. **Tier C: spiky or AWS-bound.** Campaign sites that get sudden bursts, or clients whose compliance or data already lives in AWS. Consider Vapor, but only after the app passes a readiness check: no local-disk writes, cache and sessions in DynamoDB, Redis or a database, queued jobs short enough for the function limit. ## Portability as the hedge Clients grow, shrink and change budgets, so the most valuable decision is keeping each app **movable**: - Read and write files only through the `Storage` facade, with the disk chosen by `FILESYSTEM_DISK`. - Choose cache, session and queue drivers with environment variables (`CACHE_STORE`, `SESSION_DRIVER`, `QUEUE_CONNECTION`), never hard-coded. - Keep queued jobs short and idempotent, so they survive either a server worker or a function invocation. - Keep platform checks such as `Cloud::hosted()` or `Vapor::active()` rare and isolated, never scattered through business logic. With that discipline, moving an app from a Forge server to Cloud, or from Cloud to Vapor, is mostly configuration. ## Risks and failure modes - **Consolidating everything on one big Forge server** looks efficient until one client's traffic spike or runaway job takes all twenty sites down together. - **Choosing Vapor for the whole portfolio** imposes its constraints on apps that gain nothing from serverless scaling, and every app needs refactoring first. - **Putting every brochure site on its own managed environment** multiplies per-app cost for sites that could share a server. - **Ignoring account ownership**: if servers or AWS accounts sit in the agency's name, handing a client over becomes a migration project. ## When to revisit Revisit an app's tier when its traffic pattern, uptime promise or budget changes, and at each contract renewal. A Tier A site that starts selling online moves to Tier B; a Tier B app whose client wants lower cost and accepts more risk can move back. The tiering is a policy the agency maintains, not a one-off answer.

  • What would make you move a client's app from a shared Forge server to Laravel Cloud?
    A change in stakes or shape: the app starts taking payments, the contract gains an uptime promise, traffic becomes spiky enough that sizing the shared server for its peak wastes money for everyone else, or incidents on that server keep hurting neighbouring sites. At that point paying for managed autoscaling costs less than the agency's on-call time and the blast radius.
  • What must be true of an app before you would put it on Vapor?
    It must keep no state on the local disk (files on S3, cache and sessions in DynamoDB, Redis or a database), its queued jobs must finish well inside the function time limit and tolerate SQS redelivery, and someone must be comfortable owning the AWS account. If any of these needs a large refactor, a server or managed host is usually cheaper.

saying these in an interview costs you the question

  • One big Forge server for all twenty apps is always the cheapest and safest choice.
  • Vapor should be the default because serverless is always cheaper.
  • On Laravel Cloud there is nothing left to decide about queues, storage or database sizing.
  • Any Laravel app can switch hosts later without code changes, whatever it does.
  • Pick one platform for the whole portfolio so everything is consistent.