Why we don't do 1-click installers

# The Time-to-WOW pitch

Many cloud services compete on how quickly a new visitor can see something running. A short signup, a 1-click installer, a fresh WordPress / Laravel / Craft / Statamic dashboard staring back at you in ninety twenty seconds. It's a good demo. I think it's also misleading.

# A 1-click installer actually gives you nothing

What you get is a blank install of someone else's reference template, running on a vendor-managed stack you didn't configure. Useful for a pitch — to users or to investors. Less useful for shipping anything.

The reason: with the software we host — Laravel, Symfony, Craft CMS, Kirby, Statamic, WordPress — the fresh install is the empty room. Your project lives in the templates, plugins, theme, schema, content model and the code you write around all of it. None of that exists in a blank copy. You'd throw it away and start over anyway. So what's the point?

The 1-click installer is a sales-funnel device. It demos the platform fast, gets the signup in fast, and lets the host claim "fastest deployment in the market." Having been in PaaS hosting for so long, I've seen many first-generation PHP PaaS come and go. Especially in venture-backed startups, the pressure to get an app running in seconds rather than "only" minutes seems to matter a lot. Same goes for Laravel Cloud, which launched last year.

I don't buy in. I don't want to compete on such a bogus metric. Most projects are hosted for years. Of course you want to set up resources quickly and stay in control — you don't want to fax a hosting provider and wait for your server to be provisioned.

# Real life is local-first

The honest workflow for a real PHP project is the one developers actually use:

1. Install the framework locally
2. Build out the project — code, templates, content
3. Deploy

That's how our install guides describe it. That's how Laravel, Symfony, Craft, Kirby and Statamic recommend it themselves. Pushing the "click here to skip steps 1–3" button doesn't put you closer to a shipped project. It puts you further away — because now you have a deployed shell with nothing in it, and you still need to do steps 1–3.

# What we do instead

We optimize for the developer who'll be hosting with us for years — not for the demo. That means we'd rather give you a slower first session that gets you to a real, working, locally-developed project than a faster one that produces nothing usable.

• Composer-first. Real dependencies, a real composer.json, real version control over what's installed.
• Git push to deploy. Connect a GitHub, GitLab or Bitbucket repo. Pushes trigger a deploy. Composer runs as part of the build. See our git deployment docs.
• Documented local-first workflow. Our install guides for Laravel, Symfony, Craft CMS, Kirby and Statamic all start at "set up locally."
• fortrabbit agentic skills. Our agentic skills for AI coding assistants instruct the assistant to install your project locally first, then deploy. Same path as the docs — automated.

We think the trade-off is worth it. It takes longer to see your first running site, but you get a deployment path you can actually scale into a production workflow. If you came here looking for "deploy a generic Laravel template in one click" — we don't have that, and we're not building it, at least not until we find a way to make it good. If you came here looking for the platform to host the Laravel app you're already building — that's us.

See also: No X for more of what we don't do, and why.