How to choose the right hosting for your PHP project

# Why we wrote this

We have been hosting PHP since before fortrabbit existed as a company, and we keep meeting developers who picked the wrong host the first time. The wider hosting market is a lemon market — buyers cannot inspect quality before they buy, so vendors compete on marketing instead of substance. This page is the short answer to "where do I host my PHP project?" — written from inside the market, with links to deeper reading where you need it.

We will not pretend every category is a fine choice if you pick carefully. Some are. Some are not. We will say which.

# The audience has changed

Until recently, "the developer choosing PHP hosting" was a person who knew their way around a Caddyfile and a composer.lock. Today, half of the people pushing PHP code to production are doing it with an AI coding agent in the loop — Claude Code, Cursor, GitHub Copilot. Some of them write the code by hand and ask the agent to deploy. Some of them never open the editor at all.

That changes what "the right hosting" means. If a human is not going to maintain the server, the platform has to. If the agent is going to deploy, it has to be able to deploy via plain Git push — not via a vendor-specific button in a vendor-specific dashboard. We will come back to this in the decision framework.

# What a PHP project actually needs

There is no universal list. What you need depends on the framework, the traffic shape, and the team. 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.

The constants are smaller than most buyer's guides pretend:

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

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

We have a longer write-up of each category in the hosting guide. The summary:

• 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 already or your stack genuinely 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.
• PaaS — Heroku, Render, Railway, Fly.io, Laravel Cloud, fortrabbit. You push code, the platform runs it. The honest 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, not a category. See our note on the term — 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 actually 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 — an actual 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.

# 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, with the caveat that you will eventually 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, not 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 already 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, full stop. Your agent needs an environment that is consistent, scriptable, and forgiving of mistakes. Root access on a VPS is the opposite of what you want here.

# Pricing patterns to recognize

The hosting industry runs on three recurring pricing tricks. 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 your real bill, not the headline number.
• Per-unit metered without a cap. Common with polyglot PaaS and IaaS — per-second compute, per-GB egress, per-build minute. Predictable for steady workloads, terrifying when a script loops.

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 already 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 actually does. If you genuinely do — for a custom extension, a kernel-level dependency — you are shopping a different product category. See the VPS section of the hosting guide.
5. Everything else. PaaS. The question is which one. The alternatives index walks 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, the hosting guide points to who does.

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.