How it works
A small daemon runs on a machine you control. It polls for work belonging to your organization, clones the repository locally, runs the coding agent there and reports the result back. The platform keeps the tasks, specs, approvals and audit trail. The source only ever exists on your hardware.
The runner is a standalone package with no runtime dependencies beyond the coding agent itself, so putting it on a build server or a developer machine is not a project.
Why teams choose it
- A client contract says their source stays with you. This is how you honour that and still use the product.
- Your repositories are only reachable from inside your network. The runner is already there.
- You want model spend and data-retention terms to be between you and the provider. Bring your own key and they are.
- Troubleshoot sessions need to reach staging or production. The runner is usually the only machine that can.
What still runs on our side
Tasks, specifications, approvals, comments, usage and the audit log. The orchestration and the record of who approved what stay in the platform, which is what makes it useful to a team rather than to one laptop.
Switching is a per-organization setting. You can move to self-hosted later without losing anything you have already done.