Skip to content

Agent factory · Run

Hand tickets to coding agents in isolated cloud sandboxes

Your team wants to hand tickets to coding agents, but not to a laptop with everyone's credentials and no record of what ran. hangar runs Claude Code, Codex, pi and Antigravity in isolated sandboxes, checks their work with your repo's own tests and hands back a draft pull request.

Quickstart The web console

A delivered job: issue #42, CSV export drops non-ASCII characters, succeeded; its check passed, draft PR #43 is open and the agent's summary says what it changed A delivered job: issue #42, CSV export drops non-ASCII characters, succeeded; its check passed, draft PR #43 is open and the agent's summary says what it changed
Issue #42, delivered: the check passed, draft PR #43 is open, and the agent says what it changed. Watch a ticket land (19 s): Night, Day.

Who it is for

Ticket to draft PRProduct engineersLabel a Jira or GitHub issue hangar. A sandbox starts from the repo's environment, the agent fixes it, hangar runs the repo's check and opens a draft PR that closes the issue. You review a PR, not a chat log. Delegate from your agentDevelopers in Claude Code or CodexSay "hand this to the cloud". Your uncommitted changes go along, three attempts run in parallel, you pick the best and pull its patch back while your laptop stays free. One fleet for the teamPlatform engineersRun one hangar on GKE. Everyone connects their own client with their own token; credentials stay behind a gateway, budgets cap spend, and the inbox brings each person their reviews, approvals and agents' questions.

New here? Read these five

  1. Concepts: environment, harness, sandbox, session and job.
  2. Quickstart: hangar up on a laptop, then a first task.
  3. The web console: Needs you, Jobs, Sessions and the Fleet.
  4. Jobs: hand work to an agent from a script, a ticket or Slack.
  5. The security model: what a sandbox can and cannot reach.

How it works

Many doors bring work in; hangar runs it in a sandbox and verifies it; the pull request is the one gate out. Around it, the team harness repo defines what the agents run, flightdeck judges the runs and Tower decides risky actions once an admin turns governance on. The suite's architecture page shows how they connect.

Where hangar sitsMany doors · one run plane · one gateWork inDoorsJira, GitHub, Slack,MCP, webhooksand schedulesRunhangar runs itA sandbox per jobThe repo's own checkCredentials outsideThe gateDraft PROne commit, pushedby hangar; anapproval lands itYour teamPeopleReview, answer andapprove: console,Slack, CLI, MCPTeam harness repoDefineThe harness lock, from a goodrun; ai-dlc adds a pluginflightdeckJudgeReads every run fromthe outboxTowerGovernDecides risky actions;hangar's wiring is nextharness lockoutboxdecide?Solid: shipped. Dashed: Tower's decision API is built; hangar's wiring to it is open.
Where hangar sitsMany doors · one run plane · one gateWork inDoorsJira, GitHub, Slack, MCP,webhooks and schedulesRunhangar runs itA sandbox per job, the repo's owncheck, credentials outsideThe gateDraft PROne commit, pushed by hangar;an approval lands itYour teamPeopleReview, answer and approve: theconsole, Slack, the CLI, MCPAround itTeam harness repoDefineThe harness lock, from a good run;ai-dlc adds a workflow pluginflightdeckJudgeReads every run from the outboxTowerGovernDecides risky actions; hangar'swiring to it is next (dashed)

What it looks like

The console on :8787 opens on Needs you: held tool calls, jobs waiting to start and the agents' questions, decided in place. The web console walks through it, the Jobs and Sessions pages and the Fleet.

The Needs you page: the held push on top of the deck with its command, changes and expiry, Deny, Allow for this turn and Approve push; the next decisions and what stopped beside it The Needs you page: the held push on top of the deck with its command, changes and expiry, Deny, Allow for this turn and Approve push; the next decisions and what stopped beside it
The Needs you page: a held git push on top, with Deny and Approve push; the next decisions and what stopped beside it.

Features

Feature What it gives your team Status
Many front doors MCP clients, the CLI, REST, GitHub issues, Jira, Slack, webhooks and schedules all become jobs or sessions, with one repo policy for each repo. Shipped
Isolated sandboxes Each has its own files, tools, checkout and agent configuration, from environments you prepare once; fork a prepared one into parallel attempts. Docker, gVisor or Kata, GKE or E2B. Shipped
Any agent Claude Code, Codex, pi and Antigravity as harnesses, pinned by version; a Codex client can ask for Claude Code and the other way round. A team shares one harness (instructions, skills, Claude Code plugins) frozen from a good run into a harness repo. Shipped
Verified delivery The repo's own check runs before anything is pushed; hangar pushes through the git gateway and opens a draft PR with a review packet; with landing, an approval lands it. Shipped
People in the loop Steer a running agent, answer its questions where it asked (the ticket, the Slack thread, MCP), watch its terminal; the inbox and the web console show what needs you. Shipped
Resumable sessions The conversation and repo state survive the sandbox; come back days later or fork a session. Shipped
Hostile-sandbox security Credentials stay behind a gateway; intake jobs get an egress allowlist and no push rights; tainted work opens as a draft and needs a second person. See the security model. Shipped
Usage and insight Tokens, cost and budgets per job and person (activity), traces as OTLP (observability), and run capture for flightdeck. Shipped
Shadow runs A repo policy samples real tickets and runs a candidate harness on each at the same base commit; it delivers nothing, and flightdeck grades it against what people merged (shadows). Shadow
Governed approvals Job release, landing and risky tool calls ask Tower, the Govern plane, which decides and signs a receipt; hangar enforces and fails closed. On GKE it runs in shadow: hangar's rules decide and Tower answers a dry run. An admin sets a kind to enforce to let Tower decide (Tower beside hangar). Shadow
Overnight lane One Spot node kept up while the sandbox pools are powered down (01:00–10:00) for the intake jobs of repos that opt in and for evals, so evening tickets become PRs by morning; off until an admin turns it on (the overnight lane). Shipped
Plugins and events out Doors, trackers, notifiers and deliverers are plugins: a package of your own adds a chat bot's door or a company tracker without changing hangar, and every job change goes out as a signed hangar.event/v1 (plugins). Shipped
Deploy on your company's cluster Kustomize base and components, a Terraform module that never creates a cluster, released images, secrets from your secret manager and admin configuration as reviewed files (hangar apply) (company deploy). Shipped
Bots that act for people A chat bot's relay token submits work as the linked person who asked, with their rights and audit trail, never more (relay). Shipped

Shipped: on main, on by default or behind a setting. Shadow: built, and runs beside real work without changing what people get. Partial: built and tested; its wiring is in progress. Planned: next on the roadmap.

Security posture. hangar treats every sandbox as hostile. A job from an intake door (a GitHub issue, Jira, Slack, an inbound webhook) can fetch its repo but never push: hangar pushes the commit it verified, through the git gateway. Its network is an egress allowlist, the agent has no sudo, and automated work never uses a subscription login. Once an agent has read untrusted content, its PR opens as a draft and a second person, not the requester, must approve it to land. See the security model and the safe-release upgrade.

Where to go next

Five minutesQuickstartDocker and uv on a laptop: hangar up, a credential, a first task, your own environment, then GKE and a team. The wordsConceptsEnvironment, harness, sandbox, session and job, and what hangar gives you that a laptop does not. The screensThe web consoleNeeds you, Jobs, Sessions, the Fleet, terminals, and what each action does.