How to choose the right hosting for your PHP project

# Why we wrote this

Hosting is a lemon market: buyers cannot judge the product before they buy, so vendors compete on marketing instead of substance.

Today, half of the people pushing PHP code to production are doing it with an AI coding agent, be it vibe coding or agentic engineering. That changes what "the right hosting" means.

This page is the category-level version of the question. The comparisons next to it cover the providers we hear about most in evaluation calls — each with a feature table, pricing examples, and migration notes. Read this one first if the shortlist is not settled yet.

# What a PHP project needs

What you need depends on code and config. A Kirby site is flat-file and needs no database. A Laravel app needs MySQL or PostgreSQL, a cache, a queue worker, and a scheduler. A Statamic site sits in between. A custom PHP app can be almost anything.

• A recent PHP version (8.3 or newer) with the extensions your framework loads.
• A predictable way to deploy — Git push or a CLI you can script.
• Composer at build time, with a real build step.
• A place to put files that survive a deploy.
• TLS on a custom domain without a support ticket.

Everything else — managed database, object storage, queue worker, cron — is project-specific. Match the host to your project, not to a feature checklist.

# Hosting categories, briefly

The categories, briefly:

• Shared hosting — cheap, isolated only at the directory level, oversold. Fine for a brochure site that nobody depends on. Not fine for anything that ships from Git, runs background jobs, or needs to stay up under load.
• VPS — a virtual machine with root. You become the sysadmin. Cheap on paper, expensive in hours. Only the right answer if your team has a sysadmin or your stack needs kernel-level control.
• Server management tools — Laravel Forge, Ploi, RunCloud. A dashboard that provisions and configures a VPS for you. You still own the VPS, the OS upgrades, and the 3 a.m. pages.
• Vanity hosting — branded resellers of someone else's infrastructure. Skip.
• Serverless — functions and scale-to-zero containers that run on demand and bill per use. Bref on AWS Lambda, Cloud Run, the WASM edge. A good fit for spiky or idle workloads; more to adapt for a steady app.
• PaaS — Heroku, Render, Railway, Fly.io, Laravel Cloud, fortrabbit. You push code, the platform runs it. The middle ground for most PHP teams.
• IaaS — AWS, GCP, Azure. Raw cloud primitives. Not hosting in the consumer sense — you assemble it yourself.
• Low-code / no-code — Lovable, Bolt, v0. AI-builder platforms that generate a frontend and host it. Useful for prototypes; not where you put a PHP app you intend to maintain.
• Managed hosting — a service model rather than a category. It gets stretched to cover everything from white-glove enterprise contracts to any PaaS that does updates for you. Be specific when you compare.

# How to evaluate a provider

Most "evaluation criteria" lists are uncheckable from the outside — security posture, real uptime, support quality. Stick to the things you can verify before you sign up.

• PHP version is listed publicly. If a provider hides the PHP version behind a sales call, that is a red flag.
• Free trial without a credit card. You should be able to deploy a real app and watch it run before you pay.
• Pricing model is on the pricing page. Look for: monthly price, what happens at renewal, what happens if you cancel mid-month. Intro prices that triple on renewal are a known trap. Consumption-based or month-to-month is what you want.
• Public status page with history. Not a marketing "99.99%" badge, a page showing past incidents.
• Deployment is Git-push or scriptable CLI. If the only deploy path is a button in their dashboard, your CI cannot deploy and neither can your AI agent.
• A real human answers support. Send a question before you sign up. If the answer is slow, generic, or written by a chatbot you cannot escape, that is what your incident response will feel like.
• Documented migration path. Provider docs that explain how to move to them, and how to move off, are a sign of confidence.

A few things you cannot judge from outside, and should stop pretending you can: raw NVMe throughput, OPcache hit rate on someone else's hardware, exact WAF rulesets. Benchmark numbers from marketing pages are not evidence.

# Try before you buy

Deploy something. Most providers have a free tier or a trial, and an afternoon of shipping tells more than a week of comparison tables. Push the real repository rather than a hello-world — the interesting problems live in the build step, the uploaded files and the cron jobs, and none of them show up in a feature matrix.

# Let the developers pick

If you are the client, or the boss, hand the decision to the people who will run the deploys. Hosting is a working environment before it is a line item, and a host picked on price by someone who never opens a terminal gets paid for twice: once on the invoice, once in the hours.

# Prefer a smaller host

Smaller providers tend to be invested in one particular setup, and there is usually a person behind the support address who knows that stack. The trade is fewer regions, fewer managed extras, and a smaller company to bet on. We are one of the small ones, so weigh that as you like.

# Match the host to the project

Rather than a generic decision tree, here is how we see most PHP projects line up. None of this is a hard rule.

• Brochure site, low traffic, one stakeholder. Shared hosting works until you outgrow it. A PaaS free trial is usually a better starting point.
• Laravel or Symfony app for a small team. PaaS. You want git-push deploys, managed MySQL, a worker, and TLS. Compare PaaS options on the alternatives page.
• Custom PHP, Statamic, or Craft CMS. PaaS, ideally one that handles persistent storage natively — uploaded assets, generated images, search indexes need to survive deploys.
• API backend, no frontend. PaaS or IaaS. The decision is about ops appetite rather than PHP specifics.
• Agency-managed client site. PaaS with a team feature, so the agency keeps access while billing is in the client's name.
• Early-stage startup. PaaS. You do not have a sysadmin and you should not hire one for this.
• Traffic-growing production app. PaaS that can scale a tier or two without a re-architecture; or, if you are at scale, IaaS with someone hired to run it.
• AI-builder prototype. Stay on the AI-builder host while you are prototyping. Move to a PaaS the moment you start writing real PHP — see fortrabbit vs Lovable.
• Vibe-coding with an AI agent. PaaS. Your agent needs an environment that is consistent, scriptable, and forgiving of mistakes. Root access on a VPS is the opposite of that.

# Pricing patterns to recognize

The hosting industry runs on a handful of recurring pricing patterns. Knowing the names helps:

• Intro-rate renewal. You sign up at €2 / month for the first year. Renewal is €12. Most shared-hosting and VPS-panel providers do this. Always check the renewal price before you buy.
• Add-on padding. The base plan looks cheap; the database, the SSL, the backups, the email account, the migration assistant are each €5–€15 / month extras. Total the real bill rather than the headline number.
• Per-unit metered without a cap. Common with polyglot PaaS and IaaS — per-second compute, per-GB egress, per-build minute. Paid upfront, the bill cannot exceed the price. Paid in arrears, the meter runs first and the ceiling is whatever happened: a loop that ran all weekend, a bot that found an expensive endpoint. A fixed plan wastes money slowly; a metered one can lose it quickly.
• Term and notice period. A minimum term, a notice period and a year paid in advance are one fact — time during which money keeps leaving after the decision to leave. It is discovered late, because it is never on the pricing page next to the number.

fortrabbit charges a monthly base for the app size you book, and you can cancel any month with immediate effect. There is no renewal hike because there is no fixed-term contract — see the pricing page for the current matrix.

# Decision framework

A short version, in order:

1. Will an AI agent or CI system deploy this? If yes, you need Git-push or scriptable deploys. PaaS.
2. Do you have a sysadmin on staff who runs Linux for a living? If yes, a VPS is on the table. If no, it is not.
3. Is this a flat-file site with no database? A PaaS free trial is still the easiest path; shared hosting is the budget alternative.
4. Do you need root access? Almost no one shipping PHP does. If you do — for a custom extension, a kernel-level dependency — you are shopping a different product category.
5. Everything else. PaaS. The question is which one. The comparisons in this section walk through fortrabbit vs the named competitors PHP teams evaluate most.

# A checklist before you commit

Before you put a credit card in, confirm:

• The PHP version you need is listed on a public page.
• Composer and SSH access are available without an upsell.
• There is a free trial you can deploy your real app on.
• The pricing page shows monthly cost and what happens at renewal and on cancel.
• A public status page exists, with incident history older than the current week.
• The provider documents how to move your app onto the platform — and off.
• Backups are described concretely, not as a marketing bullet.
• Support replies to a real pre-sales question in less than a business day.

# Where fortrabbit fits

We are a PHP-only PaaS, independently owned, hosted in the EU. You push code via Git, we run it. PHP version switching, Composer build, MySQL component, persistent storage, automatic TLS, staging environments, human support. Pricing is monthly and there is no renewal hike — what you book this month is what you pay next month.

We are not the right answer for everyone. We do not give you root, we do not run Node services next to your PHP, and we do not host static sites you can put on a CDN for free. If you want any of those, another host is the better answer.

If you are deploying PHP with an AI agent in the loop, or if you are a small team that does not want to become an ops team, start a trial — no credit card required.

# Where to go next

• Compare fortrabbit against the providers you are evaluating — Heroku, Cloudways, Laravel Cloud, Render, DigitalOcean, Fly.io, Railway, Lovable, Hetzner, Vultr, Laravel Forge.
• Every PHP host in the FindHost register↗ — the register we publish: filter by price, region, deployment method or shell access, described by recorded attributes rather than ranked.
• Decide if fortrabbit is for you — including who we are a bad fit for.