Orbit — Agent Mission Control
Run coding agents on your own machines. Keep the plan, history, and controls in one self-hosted place.
You operate the control plane, runners, credentials, TLS, backups, and access controls. Orbit is not a managed SaaS or a no-setup autonomous service.
Three launch scenarios
These names and this order are the canonical launch copy. Each scene is something to verify, not a promise that an agent finishes without review.
Turn a multi-day migration, refactor, or test rescue into a durable task graph. Dependencies, comments, and session history survive context limits, restarts, and a closed browser.
Show
task list → dependency → resumable session → result and comment history
Split a backlog across runners and enable a separate git worktree per session. Review the diffs and choose what to merge; a worktree is file-collision isolation, not a security boundary.
Show
two tasks → isolated worktrees → diff review → human merge decision
Run a runner beside the repository, internal CLI, VPN, or cluster access it needs. Runners poll outward, and a risky command can stop at an approval card before it proceeds.
Show
private-network runner → command approval → transcript and outcome
90-second demo
Use a tagged or explicitly named commit. Redact repository names, hostnames, tokens, cookies, internal URLs, and provider details before recording.
The checked-in storyboard is the source of truth while a public recording is being prepared. It keeps the runner, repository, approval card, and human merge decision in frame.
Reserved media slot: an approved short GIF can be added under site/assets/product/demo.gif with a factual caption.
Quick Start
The complete operator path stays in the repository README and self-hosting guide. This page keeps only the decision points so it remains a small public entrance.
Clone the repository, pin a reviewed tag, create two independent secrets, and run Docker Compose on a host you control.
Use Infrastructure → Add → Register a machine for the machine that has the checkout, tools, VPN, and agent credentials. Approve the browser enrollment.
Point a workspace at the checkout, start with the tiny demo fixture if useful, and review the transcript, approvals, and result.
# Pin a reviewed release before deployment
git clone https://github.com/jianghailong-xy/orbit.git
cd orbit
git checkout <release-tag>
cp .env.example .env
# Set unique JWT_SECRET and PROVIDER_SECRET_KEY in .env
docker compose up -d --build
docker compose psThe included gateway is HTTP-only and intended as a starting point. Put HTTPS and access controls in front before network exposure; operators own backups, monitoring, host hardening, and least-privilege credentials.
Architecture & security boundary
Orbit coordinates and supervises agents. It does not turn an operator-managed runner into a sandbox or a hosted reliability service.
Important: a worktree is not a security boundary, and an agent is not guaranteed to finish correctly without review, approval, or a human merge decision.
FAQ
Short answers for the first visit. The repository docs carry configuration and troubleshooting detail.
No. You run the control plane and PostgreSQL, decide where it is reachable, and put TLS and access controls in front of the included HTTP gateway before exposing it to a network.
Supported agent CLIs use the runner's local configuration and credentials. The control plane stores coordination metadata and transcripts; provider behavior and billing remain the provider's responsibility.
No. It reduces checkout collisions. Processes run as the runner OS account and can access whatever that account can access.
The task graph and session history live in the control plane. A runner that loses heartbeats is treated as offline; exact resume behavior varies by engine and provider, so verify the behavior you need.
The control plane and runner know about Claude Code, Codex, Kimi Code, and OpenCode, plus configured compatible providers. Install and authenticate the runtime on the runner and start with orbit doctor.
Orbit is pre-1.0. Pin a tagged release, review upgrade notes and the hardening guide, and treat main as a development branch rather than a supported release.
Community & contribution
Support is community-maintained and best effort. Sanitize logs and never post tokens, cookies, API keys, private hostnames, repository contents, or runner configuration.
Version & roadmap
Roadmap direction is public; delivery dates and production guarantees are not implied.
main is a development branch and older releases are not supported.Check the repository's Releases ↗ for the exact tag, checksums, known limits, and verification notes.
Follow the full roadmap ↗ and maturity gates ↗.
Funnel we will measure next: visit → Quick Start click → runner online → first task. The site ships no tracking pixel; use GitHub/Pages traffic, tagged links, and sanitized operator evidence.