# Hosting for agentic engineers Source: https://www.fortrabbit.com/workflows/agentic-engineering Created: 2026-07-20 Reviewed: 2026-07-24 > Hosting for agentic engineering — agent skills, machine-readable docs, per-environment deploy triggers, daily billing for throwaway branch environments. **An agent can write the code. It still has to ship somewhere.** A developer describes an intent, a coding agent edits the codebase, tests run, and the same developer reviews and ships. The application at the end is an ordinary Laravel or Symfony project. What changes is the loop around it. It's faster. fortrabbit is the platform. > Rigor at agent speed. ## Developers, multiplied This is the rigorous end of AI-built software: developers who keep the discipline and hand over the typing. Agents work several branches in parallel, tests gate the merges, and the deployment rate climbs accordingly. Responsibility does not move with the typing — production sits behind a manual deployment trigger while agents push freely to their own environments. Where [vibe coding](/workflows/vibe-coding) accepts what runs, agentic engineering wraps the same agent in review and staged releases. Both deploy the same way; the rigor lives in the settings, not in a different host. ## Skills the agent already speaks Reading is table stakes; fortrabbit ships tools an agent can act with. The open source [agent skills](https://docs.fortrabbit.com/platform/concepts/agent-skills) install locally and turn platform operations into prompts: `/fortrabbit deploy`, `db down`, and `ssh` run deployments, database syncs, and remote commands over plain SSH and rsync. Logs from PHP, Apache, and jobs are tailed over SSH, so an agent quotes the failing line rather than asking somebody to look. An MCP server, a public API, and a CLI are in the making, launching soon — every dashboard action becoming scriptable, no clicking required. A fleet of agents drives the same platform a single one does; nothing about the interface assumes a human is holding it. ## Docs a machine can actually read An agent needs to know how deployment works or why a build failed, and it finds out by reading. Documentation wrapped in a JavaScript app behind a search box is close to unusable for that; documentation served as plain Markdown at a predictable URL is not. Every docs article is available as raw Markdown, plus `llms.txt` and `llms-full.txt` for retrieval — a structured index and the entire docs in one file, regenerated on every deploy. Point a retrieval pipeline at them and the platform explains itself. ## More environments, shorter lives When a change takes 20 minutes instead of two days, branches multiply, and each one wants somewhere to run that isn't a laptop. An environment maps to a Git branch, books its own components, and is billed pro-rated by the day — one that exists for an afternoon costs a day, and deleting it stops the billing that day. The deployment trigger is set per environment. The agent's branch deploys on every push; production is switched to manual deployment, so nothing goes live without a person clicking deploy. Rigor, kept — at the speed the agents set. ## Why fortrabbit? Because a platform an agent can operate is the same one a developer can trust: docs it reads without help, deploys it scripts over SSH, and a manual production trigger a human still owns. The agents move fast, and the last word does not move at all. ## FAQ ### Is this hosting for AI applications? **No** — This is about how the code gets written, not what it does. The application is an ordinary PHP application. What changes is that a coding agent does much of the editing, and the surrounding platform has to be readable and scriptable enough to keep up. ### How is this different from vibe coding? **Same loop, more rigor** — [Vibe coding](/workflows/vibe-coding) describes the intent and accepts what runs; agentic engineering keeps the agent but adds review, tests, and staged deploys. Both are welcome and both deploy the same way — the difference shows in settings like the per-environment deployment trigger, not in the hosting. ### What makes fortrabbit agent-friendly? **Readable and scriptable** — Every docs article is available as raw Markdown, with `llms.txt` and `llms-full.txt` as aggregate files for retrieval. Open source [agent skills](https://docs.fortrabbit.com/platform/concepts/agent-skills) handle deployment, database sync, and remote SSH commands from a prompt today — with an MCP server, public API, and CLI on the way. ### Can an agent deploy on its own? **Mechanically, yes** — A push to the connected Git branch deploys the mapped environment through the fortrabbit GitHub app, and an agent can push. Whether it should is a judgment call that belongs to the developer — which is what the per-environment deployment trigger is for. ### Should agents have production credentials? **Preferably not** — The deployment trigger is set per environment: push-to-deploy for the branch the agent works on, manual deployment for production. With manual set, a push never goes live without a human clicking deploy in the dashboard. App access itself is granted per person, app by app. ### Do agents need a different kind of hosting? **No** — The runtime requirements are unchanged. What changes is the rate of deployment and the number of throwaway environments, both of which suit pro-rated per-day billing better than monthly plans. --- - [Agent skills](/platform/concepts/agent-skills) - [Staging environments](/features/staging-environments) - [Vibe coding](/workflows/vibe-coding) - [Platform reference](/platform)