Cookies ahead

Our support chat tool "Intercom" would like to collect some more data on you. See the related link for more details.

Docs

Examples

These examples show the costs for different real life setups including apps with multiple environments and different software stacks.

Docs

fortrabbit / use cases

🗄️

Staff only.

Internal tool hosting

Nobody outside the company will ever see it. Everybody inside depends on it.

The application only a company's own staff uses: an admin panel, an intranet, a stock or logistics tool. PHP holds an enormous share of these, because they were written quickly by whoever was available, and PHP was what was available.

Low traffic, high consequence

20 concurrent users at peak, nothing on weekends. By every metric a hosting dashboard reports, the application looks idle. When it stops, invoices aren't raised and shipments aren't booked, and the manual fallback was forgotten years ago.

Load-based reasoning gives the wrong answer here. The PHP component and the database run through the working day whether or not anyone logs in, and that, plus backups, is the bill. A framework version or three behind is fine; an end-of-life PHP runtime is not.

Access control is the application's job

There's no VPN and no private networking here, and that's worth saying plainly: an internal tool is reachable over the public internet like anything else. The platform offers two coarse gates — the password protection setting puts HTTP basic auth in front of the whole environment, and .htaccess rules can pin access to known office IPs.

An IP gate breaks the moment staff work from home or from a phone in a warehouse aisle, and basic auth is one shared credential. The boundary that survives reality lives in the code: sessions that expire, roles checked on every action, a second factor for accounts that can move money.

An honest account.

Different by design

A platform purpose-built for PHP. More than the sum of its parts.

Pay in arrears

Daily prorated, post-paid billing. No upfront payment, no yearly commitment.

Modular pricing

Pay per component and scale each one from xs to 2xl on its own.

No dark patterns

No vendor lock-in, no upselling, no misleading messages.

Humans in support

Eye-level developer chat over the support bubble. No sales calls.

Developer-first

Git-push deploy, SSH access, bring your own code. No 1-click bloat.

Managed platform

A hardened, service-oriented PHP stack. Deploy code, skip the server admin.

Frequently asked

Can access be restricted to the office network?
Coarsely, yes

Coarsely, yes - There is no VPN or private networking — an internal tool is reachable over the public internet like any other app. Two coarse gates exist: the password protection setting puts HTTP basic auth in front of the whole environment, and .htaccess rules can limit access to known office IPs. Fine-grained control stays the application's job.

#
Does an older code base still deploy?
Usually yes

Usually yes - Age in the application is fine; age in the runtime is not. A CodeIgniter or CakePHP code base from years back runs happily as long as it works on PHP 8.2 or newer — that is where the platform's version range starts. Applications pinned to an end-of-life PHP release are not a good fit.

#
Is a low-traffic app cheaper to run?
Somewhat

Somewhat - Traffic is rarely the cost driver here. What is paid for is existence — a PHP component and a database that must be available during working hours regardless of how few requests arrive. Components are booked individually and billed pro-rated by the day.

#
Can the tool talk to other internal systems?
Yes

Yes - Outbound calls to an ERP, a warehouse API or a mail server work; non-standard ports are closed by default and get opened per environment in the dashboard. Each environment has a fixed outgoing IP the other system's firewall can allowlist. The jobs component runs the scheduled imports and exports. Persistent connections and WebSockets are not supported.

#
How important are backups for an internal tool?
Very

Very - More than for a public site, because the data is often unique to the company and exists nowhere else. The backups component keeps restorable snapshots, which matters most for applications whose original developer has long since moved on.

#

What customers say

I just wanted to say that the documentation that you guys have and the service you provided me while I was initially setting everything up was probably the best I've encountered in my 20-ish years of front-end web development. Your dashboard is super simple and it has all of the right things for someone like me, and none of the fluff that isn't necessary.

Scott Cooper

Scott Cooper

Front-end developer

2023 — Customer support

As a design and development studio, managing and maintaining servers used to take a big chunk of our time, especially when things went wrong or major updates were needed. Passing that responsibility to fortrabbit, who are absolute experts and have a specialist team, was a game changer. The service is faultlessly stable, support is always fantastic & prompt and it scales with the click of a button. The whole experience is so scarily smooth! The time they have saved us could not be more valuable.

Josh Attwood

Josh Attwood

Creative director at Josh Attwood Studio

2026 — Direct feedback

I've been a fortrabbit customer for seven years, and I continue to appreciate its simplicity and reliability. Deploying Laravel applications is incredibly fast and intuitive: projects are online in just a few steps, without wasting time managing infrastructure. Support is always quick, knowledgeable, and practical. fortrabbit lets me focus on development, knowing everything else is in excellent hands.

AS

Andrea Spotorno

2026 — Direct feedback

More