all posts

The best Laravel hosting platforms in 2026

Ajay Kumar··10 min read

Hosting a Laravel app is not one problem. There is the web process — php-fpm behind nginx, or Octane holding the framework in memory — and then there is everything Laravel encourages you to build around it: queue workers, a scheduler running every minute, Horizon watching Redis, file storage, broadcasting, and a database that everything expects to be nearby.

That is why so many Laravel hosting decisions age badly. The platform serves the web requests fine, and then someone ships a job that takes ninety seconds, or a scheduled command that has nowhere to run, and the architecture quietly becomes a workaround. Pick based on what the whole application needs, not on what serves a page.

I build PandaStack, and I want to be straight up front: PandaStack has no first-class PHP support today, so it appears at the end with a clear caveat rather than as a recommendation. The rest of this list is what I would actually suggest to someone shipping Laravel this year.

The five things that decide your shortlist

  • Queue workers. Are they long-lived processes the platform supervises and restarts, or do you need a separate service? A Laravel app without reliable workers is a Laravel app where emails sometimes don't send.
  • The scheduler. Something must run `schedule:run` every minute. Platform cron, a supervised worker with the built-in scheduler daemon, or an external pinger — decide which before you deploy.
  • Storage. If your host's disk is ephemeral, every user upload must go to S3-compatible storage, and `storage/app/public` symlinking stops being a valid pattern.
  • Sessions and cache. File-driver sessions work on one server and break the moment there are two. Redis or database drivers are the fix, and they need to be in place before you scale, not after.
  • Deploy semantics. Laravel wants `migrate --force`, `config:cache`, `route:cache`, and `optimize` at the right point in the deploy, plus a way to run them once rather than on every instance.

The platforms

Laravel Cloud — the first-party answer

Laravel's own managed platform knows what a Laravel app is: web, queues, the scheduler, and a database, configured as parts of one application rather than as four unrelated services you wire together. If you want the least friction between `laravel new` and production, this is it, and being first-party means the framework's newer features arrive supported rather than as a compatibility question.

The trade-off is the usual one for a first-party platform: you are inside one vendor's model, and anything unusual — a system binary, a background daemon that is not a queue worker, a service the platform does not have a concept for — is harder than on a generic host.

Forge — a server you own, provisioned properly

Forge is not hosting; it is provisioning and management on top of a VPS you rent from DigitalOcean, Hetzner, AWS, or similar. It installs nginx, PHP, MySQL or Postgres, Redis, supervisor, and certificates, and gives you deploy scripts, queue worker management, and scheduler entries. You get a real server with a real disk and a real cron, at VPS prices, which is why an enormous number of profitable Laravel businesses run exactly this.

You are still the person who resizes the droplet, watches disk usage, and applies OS updates. Forge makes that manageable; it does not make it someone else's job.

Vapor — serverless Laravel on AWS Lambda

Vapor runs Laravel on Lambda with the surrounding AWS pieces arranged for you. It scales to essentially unlimited concurrency and costs little when idle, which suits spiky, bursty applications. The constraints are inherent to Lambda: request timeouts, no local disk worth using, cold starts, and a mental model where nothing persists between invocations. Applications with long-running jobs or heavy file processing tend to fight it.

Ploi, RunCloud, ServerAvatar — the Forge alternatives

Same category as Forge, different pricing and slightly different opinions. Worth comparing if Forge's per-server pricing is the sticking point, or if you want a control panel that also handles non-Laravel PHP apps on the same box.

Render, Railway, Fly.io, DigitalOcean App Platform

General-purpose platforms host Laravel well as long as you accept that you are describing the pieces yourself: a web service, one or more worker services, a scheduled job, a managed Postgres or MySQL, and Redis. Most people use a Dockerfile here rather than fighting a PHP buildpack, which is more work up front and more predictable afterwards. Choose these when Laravel is one service in a polyglot stack rather than the whole company.

Shared hosting and cPanel — still fine for some apps

For a brochure site with a contact form and no queue, cheap shared hosting genuinely works and costs a few dollars. It falls apart the moment you need a supervised worker, a real cron, or a PHP version the host does not offer. Know which of those you need before dismissing it or committing to it.

PandaStack — honest caveat

PandaStack's git-driven app hosting detects Node, Python, Go, and static builds. It does not detect PHP, and the base template does not ship a PHP runtime, so a Laravel app is not a supported one-command deploy today. What is possible is building a custom template — the base image is Ubuntu 24.04 and templates are built from a Dockerfile — with php-fpm, composer, and your extensions, then running the app in a microVM with explicit start commands. That is a reasonable path if you specifically want per-app kernel isolation or you are already running other services on PandaStack, and it is more work than any option above if you just want Laravel deployed.

Where PandaStack does fit a Laravel stack cleanly today is the database: managed PostgreSQL in its own microVM, with point-in-time recovery and auto-suspend for the staging copies, connected over TLS from wherever the app runs.

The things that break after deploy, everywhere

# The deploy sequence that avoids most first-deploy incidents
php artisan down --render="errors::503"
composer install --no-dev --optimize-autoloader
php artisan migrate --force
php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan queue:restart   # workers hold old code in memory until told otherwise
php artisan up

Three specifics worth internalising. First, `queue:restart` is not optional — workers are long-lived PHP processes that keep the previous release's code in memory, so a deploy without it runs old jobs against a new schema. Second, `config:cache` freezes your configuration, and any `env()` call outside a config file returns null once it is cached; this is the single most common "works locally, breaks in production" Laravel bug. Third, migrations should run once per deploy, not once per instance — on a platform that starts several containers, a migration in the start command is a race condition waiting to corrupt something.

If you use Octane, the framework stays booted between requests. That is a large speed win and a new class of bug: static properties, singletons holding request state, and anything that assumed a fresh process per request now leak between users. Audit your service providers before switching.

Choosing, briefly

Shipping a Laravel product and want the least infrastructure work: Laravel Cloud. Want a real server at VPS prices with the setup done for you: Forge, or Ploi if you prefer its pricing. Bursty traffic, no long jobs, already on AWS: Vapor. Laravel as one service among many in a polyglot stack: Render, Railway, or Fly with a Dockerfile you control. And if you're mostly hosting a small site with no background work, shared hosting is not the embarrassing answer people pretend it is.

Frequently asked questions

Do I need Redis for a Laravel app?

Not for a single-server app with light background work — the database queue driver and database sessions are perfectly serviceable, and one fewer moving part is worth something. You need Redis when queue throughput grows enough that database polling becomes a load problem, when you want Horizon's dashboard and supervision, or when you run more than one web server and need shared cache and session state. A useful rule: start on the database drivers, and add Redis when you can name the specific metric that made it necessary.

How do I run the Laravel scheduler on a platform with no cron?

Three options, in order of preference. If the platform has scheduled jobs, run `php artisan schedule:run` every minute as one. If it does not but supports long-running worker processes, run `php artisan schedule:work`, which is a supervised daemon that handles the every-minute loop itself. As a last resort, an external cron service can hit an authenticated endpoint that triggers the scheduler, which works but puts your scheduling reliability in the hands of an HTTP call. Whichever you choose, add a heartbeat check, because a silently dead scheduler is invisible until someone notices reports stopped arriving.

Is Laravel Vapor still worth it?

It depends on whether your workload actually has the shape Lambda rewards. Vapor is very good for spiky, request-driven applications that idle most of the time, and it makes serverless Laravel possible without becoming an AWS specialist. It is a poor fit for long-running jobs, large file processing, WebSocket-style persistent connections, or anything expecting a durable local disk, because those are Lambda constraints rather than Vapor decisions. Look at your slowest queue job and your largest upload before deciding — those two numbers usually settle it.

Can I host Laravel without Docker?

Yes, and it is still the most common setup. Forge and the other server-provisioning panels install PHP, nginx, and supervisor directly on a VPS, with no containers involved, and Laravel Cloud abstracts the packaging away entirely. Docker becomes worthwhile when you need the exact same environment in CI and production, when your app depends on specific system libraries such as image or PDF tooling, or when you deploy to a general-purpose platform whose PHP buildpack does not match your extension list. It is a choice about reproducibility, not a requirement.

What is the cheapest reliable way to host a small Laravel app?

A small VPS from a provider with fair pricing, provisioned by Forge or one of its alternatives, running the web process, a queue worker under supervisor, and the scheduler in the system crontab. That is roughly the cost of a couple of coffees per month, it has a real disk and a real cron, and it scales vertically far further than most people expect. Add off-server backups you have actually restored from, and put uploads in object storage rather than on the instance disk, and that setup will carry a small product for years without architectural changes.

Keep reading

Run code in a microVM in one API call.

49ms p50 cold start. Fork, snapshot, and scale to zero.

Start free
Written by Ajay Kumar, Founder, PandaStack.