Agency hosting

An agency runs client work at scale: a dozen production sites, each owned by a different business, maintained by a team whose members change over the years. Most hosting accounts are built for one owner and one site — which is how agencies end up sharing logins, collecting client sites under one credit card and untangling access every time somebody moves on. fortrabbit started inside a web agency before becoming its own company in 2012, and the account model reflects that origin. The stacks agencies build with — Craft CMS, Statamic, Laravel and more — get dedicated guides and support here.

# One login, all client projects

Sign-up is personal — an account represents a real person, not a company. From there the structure is many-to-many: a team groups the agency's developers, apps represent the client projects, and each app is owned by a payment method rather than by whoever happened to create it. One login shows every client project, while each project keeps its own owner and its own bill.

That separation sounds bureaucratic until the day two clients part ways with the agency in the same quarter. Because ownership, access and billing are independent objects, each relationship can be unwound on its own — no shared account to split up, no innocent bystander sites affected. The collaboration features exist precisely to map these real-world business relations.

# Access that survives staff changes

People join, people leave, contractors come in for one project. There are two team roles: unlimited for the core team — full access to apps, members and billing — and limited for junior developers or externals, scoped to chosen apps. Freelancers who help out on a single project don't need to join the team at all; they can be invited to that one app directly.

Offboarding is the part most setups get wrong. Here, removing a person from the team ends their dashboard access and their personal code access in one step. Nothing about the apps changes: no deploy keys to swap, no redeployment, no downtime. The same works in reverse — anyone can leave a team on their own, and the apps stay behind with the team. Compare that with the industry default of a shared master login whose password has to be rotated after every departure, and usually isn't.

# Whose name is on the invoice

A payment method is its own object with an invoice address, VAT settings and a separate invoice archive. An agency can hold several of them — one per client, one for internal projects — and route each app's charges accordingly, all managed from the same login.

That makes the resell-or-pass-through question a choice instead of a constraint. An agency that bundles hosting into a retainer keeps the apps on its own payment method and re-bills as it sees fit. An agency that wants hosting out of its books puts the client's payment method in charge: the invoice then carries the client's name and address, goes into the client's archive, and the agency keeps developer access for maintenance. No invoices forwarded with a markup nobody asked for, no client paying for a service they cannot see.

Switching between the two models later is a handover, not a migration. Ownership changes while code, database, domains and certificates stay put, and pro-rated daily billing means a mid-month transfer is not paid twice. There is even a page to send clients to that explains their side of the arrangement.

# When the developer who built it leaves

The uncomfortable agency question: a client site was built four years ago by somebody who has since left. Who can still deploy it? No platform can transfer application knowledge that was never written down — but the infrastructure side can be made self-describing instead of living in one person's head.

The platform pushes in that direction. Configuration belongs in environment variables, not in code, so credentials survive a personnel change and can be rotated without a deployment. Scheduled work belongs in the jobs component, not in a personal crontab. Uploads belong in the storage component, not on somebody's disk. An app built this way is documented by its own dashboard: the next developer can read the setup instead of reverse-engineering it. The departure itself is then an access change, not an incident.

# A staging environment per client project

Each app has at least one environment, and every environment is a fully isolated hosting setup with its own settings, domains and individually billed components. An environment can be mapped to a Git branch, which turns a client project into the familiar shape: a production environment on the main branch, a staging environment on a develop branch for reviews and client demos.

Staging does not have to cost like production. Smaller component sizes keep a review environment cheap, built-in password protection keeps it away from public eyes and search engines, and daily billing means an environment deleted after launch stops costing anything the next day. Concepts and workflows are covered in the multi-staging guide.

# Reliability an agency signs its name to

When a client site goes down, the client calls the agency — the reputational risk of the hosting choice sits with whoever recommended it. The platform runs on AWS infrastructure, environments are isolated from each other so one busy site cannot starve another, and a 99.5% uptime SLA with defined service credits backs it up. The platform is monitored around the clock with on-call duties. Each app runs in a chosen region — EU (Ireland) or US — picked once per app to match where the client's audience is.

Support is part of that calculation. It runs through chat during business hours (CET), staffed by the people who operate the platform, with a median first response of under two hours. There is no phone line and no white-glove tier — see what fortrabbit deliberately does not do. And because provider longevity is itself a client-relationship risk, it is worth knowing that the same independent German company has operated this service since 2012 and publishes its cost breakdown, down to a 4% profit margin.

# Margin without seat licenses

On the old platform, team features were a paid add-on — company plans ran up to $250 per month for a large organization. The new platform includes all collaboration features at no extra cost: teams are free, inviting people is free, payment methods are free. Costs scale with what the client apps actually consume, not with the agency's headcount or project count.

The billing model follows through. Components are booked per environment, billed pro-rated and post-paid with a one-day minimum; the smallest possible combination starts at €2.50 per month. TLS certificates for client domains are included and renew automatically. Autoscaling is optional and can be capped, so a fixed-budget client site stays inside its budget. There is no minimum contract and hosting can be cancelled at any time — full numbers and worked examples live on the pricing page and in the pricing details.

# Migration is self-service, on purpose

There is no free migration service here, and that is a deliberate decision, not a gap in the offer. A migration performed by the provider is a migration nobody at the agency understands afterwards — a poor trade for a team that will maintain the site for years. The migration guide covers the general procedure, the alternatives pages carry provider-specific notes, and support is reachable throughout with specific questions.

The free trial makes the rehearsal cheap: every new app starts with seven days of full access, no credit card required, so a first client project can be stood up and tested before any DNS record changes.