The best PHP hosting platforms in 2026

PHP hosting is the oldest solved problem in web infrastructure, which is exactly why the advice is so bad. Search results are a mix of shared-hosting affiliate pages from 2014, container tutorials that assume you want to hand-write an nginx config, and platform marketing that says 'we support PHP' without saying which of three very different runtime models they mean.

I'm Ajay, I build PandaStack. I'll say up front that PandaStack is near the bottom of this list for PHP specifically, and I'll explain exactly why rather than pretending otherwise — the honest version is more useful to you than a ranking I had to bend. Everyone else is described qualitatively from public documentation.

The three camps, and why the distinction matters

Nearly every difference downstream comes from which of these a platform actually runs:

• Classic php-fpm behind a web server. nginx or Apache accepts the request, hands it to a pool of PHP worker processes, each request gets a fresh interpreter state. This is what 'PHP hosting' has meant for twenty years and what almost all shared hosting is.
• An application server that stays resident. FrankenPHP, RoadRunner, Swoole and Laravel Octane keep the framework booted between requests. Dramatically faster, and it introduces a class of state-leak bug PHP developers historically never had to think about.
• PHP compiled into a container, run like any other process. The platform does not know or care that it is PHP; you own the image and the process supervision. This is what most modern PaaS actually offers when it says it supports PHP.

If you are moving a Laravel app off shared hosting, the first two are the interesting choice. If you are a platform team standardising on one deploy path, the third is where you will end up regardless.

1. Laravel Cloud

For a Laravel application in 2026 this is the obvious first thing to price. It is built by the people who build the framework, so the queue workers, scheduler, Octane support and database story are not integrations — they are the product. If your app is Laravel and you have no strong reason to be elsewhere, start here and make other options justify themselves.

The obvious constraint is that it is for Laravel. A Symfony app, a WordPress install or a fifteen-year-old bespoke PHP codebase is not the customer.

2. Platform.sh / Upsun

The most serious option for PHP that is not Laravel-specific, and the one most likely to already know about your framework. Managed php-fpm, per-branch environments that clone the database, and a configuration model that describes the whole application rather than one service.

It is a considered, enterprise-shaped product with pricing to match, and the YAML configuration is a real thing to learn. Worth it for a large PHP estate; heavy for a side project.

3. Fly.io

Bring a container, get microVMs near your users. Fly's own PHP and Laravel documentation is unusually good for a general-purpose platform, and multi-region PHP with a read replica per region is a shape it handles well.

You own the Dockerfile, which for PHP means owning the php-fpm and nginx relationship, or picking FrankenPHP to collapse it into one process. More operator work than a PHP-native host.

4. Render

A solid general PaaS that runs PHP via a Dockerfile, with managed Postgres, cron jobs and workers in the same product. If your team already deploys other services to Render, adding the PHP one there is worth more than a marginally better PHP-specific host.

No PHP-native runtime, so you are in camp three: your image, your process supervision. Instance-shaped billing means idle environments cost real money.

5. DigitalOcean App Platform

Buildpack-based PHP support that detects a composer.json and does something sensible without a Dockerfile, at predictable prices, next to managed databases you were probably going to buy anyway.

Less configurable than the specialists. When the buildpack's assumptions do not match your app, the escape hatch is a Dockerfile and you are back in camp three.

6. A VPS with Ploi, Forge or RunCloud

This is the honest mainstream answer for a lot of PHP teams and it does not deserve the sneer it usually gets. A control plane provisions nginx, php-fpm, certificates and deploy hooks on a server you rent, and then gets out of the way. Cheap, fast, and the runtime is exactly the one PHP was designed for.

You own the server. Patching, backups and being the person who notices at 2am are yours. Fine at one or two servers; a job at ten.

7. Google Cloud Run

PHP in a container, request-driven autoscaling including down to zero, and a free tier that covers a lot of small apps. FrankenPHP suits it particularly well because a single resident process maps cleanly onto Cloud Run's model.

Classic php-fpm plus nginx in one container works but is slightly against the grain, and you inherit GCP's IAM surface area. Filesystem is ephemeral, which matters more for PHP apps than most, since a lot of them assume a writable storage directory.

8. PandaStack

Mine, and I am ranking it last for PHP deliberately. Here is the precise reason, which is more useful than a score.

PandaStack deploys from a git repo with no Dockerfile by detecting the framework and using mise to install runtimes. The base image pre-warms Node, Python, Go and Bun. PHP is not pre-warmed, and mise builds PHP from source, which is slow enough to be a real factor against a twelve-minute deploy budget. A repo that PHP-specific detection does not recognise falls through to a Railpack-generated plan, and while Railpack does understand PHP, its plan assumes an nginx and php-fpm layout that PandaStack does not reproduce — the platform extracts the runtime pins and commands, not Railpack's image layout.

The practical consequence: PHP on PandaStack works best when you take the resident-process route and set the start command yourself, rather than expecting camp-one behaviour.

{
  "install_command": "composer install --no-dev --optimize-autoloader",
  "build_command": "php artisan config:cache && php artisan route:cache",
  "start_command": "frankenphp php-server --listen 0.0.0.0:$PORT --root public"
}

What PandaStack is genuinely good at is the surrounding shape rather than PHP itself: each app is a Firecracker microVM with its own kernel, apps scale to zero and bill nothing while asleep, and the rate card is one line — $0.054 per active vCPU-hour plus $0.0162 per working-set GiB-hour. If you have forty preview environments, that arithmetic is the reason to look. If you want somebody else to have already solved php-fpm for you, one of the seven above is the better buy and I would rather you found that out here.

How to pick in about ten minutes

1. If it is Laravel and there is no constraint pulling you elsewhere, price Laravel Cloud first. Being built by the framework authors is worth more than a feature-by-feature comparison.
2. If it is PHP but not Laravel, and it is a serious estate, look at Platform.sh before general-purpose PaaS.
3. If your team already has a deployment platform, seriously consider just using it with a Dockerfile. A consistent deploy path across services usually beats a marginally better PHP-specific host.
4. Count non-production environments. Past a handful, idle cost outweighs almost every other difference, and only some of this list scales to zero.
5. Decide php-fpm versus a resident application server explicitly. It changes your performance profile, your bug classes and which platforms fit — and it is the decision people most often make by accident.