"Where should we host it?" sounds like a technical question. It's really a question about who gets woken up when something breaks, and how much you want the monthly bill to surprise you.

For Laravel apps there are three broad options today: run your own server, hand the servers to a managed platform, or go serverless and stop thinking about servers at all (mostly). I've worked with Laravel on plain Linux servers and on AWS, and each option is the right answer for someone. Just rarely for everyone.

The housing analogy

• A VPS is owning a house. You decide everything, it's cheap per square metre, and when the boiler breaks at midnight, that's your problem.
• A managed platform is a serviced apartment. You move in with your suitcase (your code). Someone else handles the plumbing, and you pay for that service.
• Serverless is a hotel billed by the minute. Brilliant when you only need a room occasionally or suddenly need fifty rooms. Odd if you live there full time.

Option 1: a VPS (your own Linux server)

A virtual machine from AWS EC2, DigitalOcean, Hetzner, Linode or similar. You install Nginx, PHP-FPM, MySQL or a managed database, Redis, Supervisor for queue workers, and a cron entry for the scheduler.

Why people love it:

• Full control: any PHP extension, any system package, any cron schedule, long-running workers, WebSockets.
• A flat, predictable monthly price. Traffic spikes make it slower, not more expensive.
• Laravel runs exactly as it does locally. No special rules.

What it costs you in effort: OS updates, PHP upgrades, firewall rules, SSH hardening, TLS renewal, backups you've actually tested restoring, monitoring and log rotation. None of it is hard. All of it is easy to forget.

Tools like Laravel Forge sit on top of this option. It's still your VPS on your cloud account, but provisioning, Nginx config, SSL, deploy scripts and workers are set up for you. For many teams, that's the sweet spot: VPS prices with much less of the ops burden.

Option 2: a managed platform

You connect a Git repository and the platform builds, deploys and runs the app. Laravel Cloud is the Laravel team's own take on this category; general platforms such as Render, Fly.io or Heroku-style services work too, with more setup for Laravel specifics.

Why people love it:

• Push to deploy, preview environments, managed databases and caches, queue workers as a setting.
• Scaling is a slider, not a migration project.
• Nobody on the team needs to know what ufw is.

The trade-offs: less control over the underlying system (unusual extensions or binaries can be awkward), pricing that grows with usage and add-ons, and some degree of lock-in to the platform's way of doing things. You're also trusting their uptime and support with yours.

Option 3: serverless

Your app runs as functions, typically on AWS Lambda. Laravel Vapor is the commercial option built for Laravel; Bref is the popular open-source way to run PHP on Lambda.

Why people love it:

• It scales up to very high traffic and back down to almost nothing without anyone touching it.
• No servers to patch at all.
• For spiky or seasonal traffic, paying per request can be far cheaper than idle servers.

The rules change, though. This is where Laravel apps get surprised:

• The filesystem is read-only except /tmp, so uploads go to S3 and local file caches and sessions won't work.
• No long-running processes. Queue workers become functions triggered by SQS, and the scheduler is triggered by an AWS event, not cron.
• Each invocation has a maximum duration, so long reports or imports need to be split into jobs.
• Lots of concurrent functions can mean lots of database connections. A connection proxy or careful limits matter.
• Cold starts add latency to the first request on a new instance.
• Cost is less predictable. A viral moment, or a badly behaved bot, shows up on the bill.

Side by side

How I'd choose

Ask three questions, in this order:

1. Who will own the servers? If the honest answer is "nobody", rule out a raw VPS. Choose Forge on a VPS, a managed platform, or serverless.
2. What does your traffic look like? Steady business traffic, like an internal portal used during office hours, suits a flat-priced server. Huge spikes, like ticket sales or a campaign landing page, suit serverless.
3. Does your app need anything unusual? Long-running processes, WebSockets, heavy local file work, odd binaries or PHP extensions all point towards a VPS or a flexible platform.

Whatever you pick, do these

• Keep the app stateless: sessions and cache in Redis or the database, files in S3-compatible storage. It keeps every option open.
• Script your deploys. composer install --no-dev, migrations, config:cache, route:cache, queue restart, in the same order every time.
• Back up the database somewhere other than the server it runs on, and test a restore.
• Set up uptime checks and error tracking before launch, not after the first outage.

Where do your Laravel apps live right now, and what would make you move them?