Fortrabbit Alternatives

The blog post that sent people looking for Fortrabbit alternatives was unusually candid for a hosting company. In October 2026, one of its founders announced that from 1 November some plan prices would go up, and wrote: "We have not raised prices in the 14 years fortrabbit has been around. I'm not happy to start now." The same post admitted "our traffic prices still suck" and pointed the blame at AWS. That is not the tone of a company hiding anything — I have read a lot of hosting press releases and this is the opposite of one. But candour does not pay your invoice, and if the new numbers do not work for your app, you need options.

Fortrabbit is a managed PHP platform: a bootstrapped German GmbH in Berlin that has been running PHP and MySQL on AWS since 2012. You push to Git, a Composer build runs, TLS is issued automatically, backups happen daily, and nobody asks you to patch an operating system. Apps run in Ireland (EU) or Virginia (US), billed per component and per day, in arrears, with the same number in EUR and USD. It is a genuinely good product for a specific person: the developer or small agency who lives in Git and Composer and wants nothing to do with servers. Whether you should stay on Fortrabbit through the price change depends on which components you run and how big they are.

When it makes sense to leave Fortrabbit

The November 2026 price changes hit the top end

The increase is deliberately narrow. Everything small keeps its price: all XS and SM plans, PHP up to the XL size, and all MySQL, storage and backup plans are unchanged. What goes up from November 2026: PHP 2XL (4 GB) from €50 to €80 a month, Jobs from MD upward (for example 1 GB workers from €15 to €20, 4 GB workers from €60 to €80), and Traffic from MD upward (128 GiB from €8 to €10, scaling up to the largest tier from €512 to €640 a month). If your footprint is small, this paragraph is about other people. If you run a 2XL PHP plan, fat queue workers, or serious traffic, your bill moves materially — for a large setup the monthly cost can rise by a third or more. Do the arithmetic on your own component list before deciding.

Traffic pricing is the weak point

Fortrabbit says so themselves. Traffic costs more than raw AWS bandwidth because of the markup a managed platform must add to survive, and the founder's own assessment is blunt. If your app streams gigabytes per user — media, downloads, big API payloads — you are paying a premium per gigabyte that a bandwidth-friendly host or a CDN in front of a cheap origin would not charge. In these cases, the answer is sometimes not to leave but to put a CDN in front; but if traffic is intrinsic to the product, the pricing model is working against you.

The platform has firm edges

No root access — SSH runs in a jailed shell. No WebSocket support. PHP only: there is no first-class Node, Python or Go runtime here, and no control panel or one-click installer by design. For a PHP monolith or a Laravel app these edges rarely matter. They matter the moment you want a long-lived socket connection, a sidecar service in another language, or a system package the platform does not ship. If your architecture has grown past "a PHP app with MySQL and workers", you have outgrown the platform regardless of price.

Component billing is a mental tax

Pricing per component, per environment, per day is fair — you pay for what you book — but it means every environment is a small budget spreadsheet. Agencies billing clients found the old company plans confusing enough that fortrabbit replaced them entirely on the new platform, and the founder admits the concept "has not worked out". If you need one predictable number per client per month, a fixed-tier host is administratively cheaper even at a slightly higher sticker price.

You are being pushed up a size by one component

Because components scale independently, growth is usually gentle: the database grows, you resize MySQL, nothing else changes. But PHP is sized by hand and is not cheap at the top end, and the November changes make the largest PHP plan notably more expensive. If your app needs 2XL PHP most of the month just to survive peak hours, a platform where CPU-based pricing or autoscaling exists will serve you better than a memory-based one.

When you should stay with Fortrabbit

• Small setups are still genuinely cheap. The smallest environment starts at €2.50 a month, a small production app with a database lands around €5–10, and the standard example stack (512 MiB PHP, 1 GiB MySQL, 2 GiB storage, three backups) runs about €19 a month at time of writing. That is competitive with managed PHP hosting anywhere, and the November changes do not touch it.
• The workflow is the product. Git push deploys with Composer builds, GitHub integration, real staging environments that run the same code at different sizes, SSH and SFTP for the day-to-day. Once a team has tasted "merge, push, live", going back to FTP and a control panel feels like a downgrade.
• Managed means managed. PHP versions, MySQL, TLS certificates and backups are operated for you, and the platform has been doing exactly this on AWS since 2012. There is no server to patch and no deploy pipeline to maintain.
• Agencies are first-class citizens. Access roles from code-only to full admin, multiple client ownerships under one login, and app transfer that hands billing to the client while your developers keep maintenance access. If you run client sites, that handover mechanic alone justifies staying.
• The company behaves like a partner. Fourteen years before a price rise, a published cost breakdown, an explanation of exactly which plans are affected and why, and an invitation to talk if the new prices break your setup. Try getting that from a listed company.
• The trial de-risks everything. Every app starts with seven free days, no credit card, with any components in any size. If you are considering leaving, the correct first move is to build a copy elsewhere during a trial — here or on a rival — and compare the real bills.

The alternatives

Six places to land if the numbers or the constraints no longer work. Pricing verified where I could at time of writing; usage-based platforms are inherently case-specific.

Render — a broader PaaS with fixed tiers

Render runs web services, workers, cron and databases with both free static hosting and fixed monthly tiers from around $7 a month at time of writing. Its runtime support is broader than Fortrabbit's — Node, Python, Go, Ruby and Docker-based services alongside PHP — which makes it the natural comparison for teams whose stack has drifted beyond PHP. Deployments are Git-based, TLS and a CDN are included, and the pricing is per-service rather than per-component, which some people find easier to budget.

Railway — usage-based, quick to start

Railway is the fastest way I know to stand up an app plus a database plus a worker and pay for actual usage (plans start around $5 a month plus consumption at time of writing). It favours mixed-language projects and prototypes that turn into products. The trade-off is the familiar one with consumption pricing: a runaway job or a traffic spike shows up on the bill, so set limits and alerts on day one.

Ploi — if what you actually want is a server

Ploi is a different shape of solution: a management panel that provisions and maintains servers on your own VPS account. You keep root, you choose the provider, and Ploi handles deployments, certificates, backups and monitoring for PHP and Laravel apps. This is the move for developers who chafe at Fortrabbit's jailed shell — you trade "no servers" for "servers someone else configures", and you can often run a larger app for less, provided your time is cheap enough to absorb the occasional server problem.

Netlify — for the static front end you keep in front

Netlify is not a PHP host, and I list it deliberately: a fair number of "PHP apps" are really a static front end hitting a small API, and Netlify's Git-based deploys, edge functions and generous free static tier make it the right home for that front end. Some leavers pair a static front end with a much smaller backend bill than a full platform stack.

Ghost(Pro) — when the app is really a publication

Ghost(Pro) is worth a hard look if your Fortrabbit app is a blog, magazine or membership site built on PHP. Ghost(Pro) is managed hosting for the Ghost publishing platform, priced roughly in the $15–$18 a month range at time of writing for entry tiers, and it takes publishing, newsletters, memberships and payments off your plate entirely. Running a publication on a general PHP platform means maintaining publishing software yourself; letting the publisher host it is often both cheaper and calmer.

Divio — the managed platform for Python and Django

Divio offers a similar managed-PaaS philosophy to Fortrabbit — Git deploys, environments, managed backing services, cloud infrastructure operated for you — but oriented around Python and Django rather than PHP. If the reason for leaving is "the stack changed" rather than "the price changed", this is the closest equivalent on the other side of the language fence.

Worth mentioning without links: Tiiny.host for one-page microsites and PDFs, where a full platform is absurd overkill. And before you migrate anything at all, take the seven-day trial on whichever of these fits and deploy your real codebase to it — a pricing page tells you the sticker, a working deploy tells you the truth.

What I would do in your position

If your app runs on XS or SM components, do nothing — the price change was designed to leave you alone, and moving costs more than the increase ever will. If you are on the large end, build the trial copy and compare two real monthly bills side by side, including traffic at your actual numbers. And whatever you decide, keep the fortrabbit blog in your feed: a company that narrates its own price rises this honestly is one whose future decisions you can at least see coming.

How to switch from Fortrabbit without downtime

Fortrabbit's own advice for incoming migrations is the right advice for outgoing ones too: run a copy somewhere else, look at it, and only then touch DNS. Concretely:

1. Export the data while the app is live. MySQL dump (the platform supports access over SSH tunnel), the full storage tree via SFTP, and — critically — the environment variables and cron/worker definitions, which live in the dashboard rather than the codebase in most setups.
2. Rebuild the app on the new host from Git, not from files. Let the new platform run its own build (Composer or otherwise). This surfaces version differences — PHP version, extension availability, memory limits — while the old app is still serving traffic.
3. Mind the workers. Queue consumers and scheduled jobs are easy to forget and dangerous to duplicate. Stand them up on the new host disabled, switch traffic, then enable them there and confirm they are stopped on Fortrabbit.
4. Sync the database twice. Take a final dump at cutover time, import it while writes are paused briefly (maintenance page for two minutes beats corrupted data), and verify row counts.
5. Lower DNS TTLs 48 hours ahead, switch records in the evening, and keep the Fortrabbit environment running for a week — billing is daily and in arrears, so a few days of a paused app costs cents, which is one of the nicer things about their model.
6. Watch the egress bill on the way out. Large storage exports can cost more than you expect on any cloud-backed platform; if you have media-heavy storage, budget for it or migrate it in the quiet hours.

How we evaluate hosting providers

We start from the renewal price, not the headline rate, because that is the price you actually pay from year two onwards — the signup discount is a marketing cost the host expects to earn back. For usage-based platforms like Fortrabbit we do the equivalent: we model what a real small production setup costs per month, note upcoming price changes, and check what happens to the bill at twice the traffic. From there we look at resource limits as written, what is bundled versus paid extra, data centre location versus audience, and how support behaves when something breaks rather than when you are being sold to. We mark anything we could not verify as "at time of writing". Providers do not pay for placement on this page, and no ranking here is for sale.