Skip to content

Agent factory ยท Run

hangar

Runs coding agents in isolated cloud sandboxes, from a ticket to a landed PR.

hangar's Needs you: the decision deck with a held git push to main on top, its changes, branch and expiry, Deny, Allow for this turn and Approve push hangar's Needs you: the decision deck with a held git push to main on top, its changes, branch and expiry, Deny, Allow for this turn and Approve push
Needs you: one decision at a time, soonest to expire on top. Everything else keeps running.
Owns Sandboxes, jobs and sessions, the doors, the git gateway and landing, the inbox, the manifest and trace.
Does not own Statistics (flightdeck), harness content (the team harness repo) or approval policy (Tower).
Entry points MCP server, REST API, the hangar CLI, webhooks from GitHub, Jira and Slack.
Used by Engineers who submit and steer work, reviewers, the lead who sets policy, agents through MCP, CI.
Status The safe release, the doors, the inbox, the harness lock and the outbox are shipped; asking Tower is in progress. See P2 on the roadmap.
The first frame of hangar's clip: the Fleet, with issue #42's job starting in checkout-python and the caption Issue #42 gets the hangar label, and a job starts The first frame of hangar's clip: the Fleet, with issue #42's job starting in checkout-python and the caption Issue #42 gets the hangar label, and a job starts
Play the clip (19 s): issue #42 becomes a job, the agent works, its push to main waits in the deck, a person approves it and the PR lands.

Docs site Repository