Hangars

Cloud machines for your team's coding agents, with a shared terminal in the browser.

A Hangar is a cloud machine for coding agents, next to your applications. The agents you choose are installed on it, each in a window of its own, and the machine keeps working whether or not anybody is connected. Close your laptop and the agents carry on.

A Hangar belongs to the team, not to whoever created it. Everyone in the team can open it, everyone connected shares one terminal, and its files and each agent's sign in are shared the same way.

Hangars are in beta and free while it lasts. Find them under Hangars in the sidebar.

A Hangar or an Application

You want	Use
Agents that keep working after your own machine is closed	A Hangar
One machine the team's agents and people work on together	A Hangar
A quick look at a dev server an agent started	A Hangar's ports
Something that answers requests at an address	An application
A repository built and shipped on every push	An application

A Hangar is where agents work. An application is what serves. A Hangar can open a few ports to preview what its agents build, but it has no deployments and no custom domain. When something an agent builds should stay reachable, deploy it as an application.

Create a Hangar

Open the Create Flow

Open Hangars → New Hangar, or Create → Hangar from anywhere in the console.

Name It and Choose the Agents

Name. Letters and numbers only, 5 to 45 characters. The name is permanent, and applications and Hangars share one set of names in a team, so a name one of them holds is taken for the other.
Agents. Claude Code and OpenAI Codex are selected to start with. You can also choose Pi, OMP, Devin CLI, OpenCode and Cursor, or Terminal only for a machine with no agents and a plain shell.

Choose a Repository

Optional. Pick a repository to find on the Hangar's disk when it starts:

GitHub. A repository from your connected GitHub account. Install the Out Plane GitHub App and grant it the repository, as when you deploy from GitHub.
Public repository. Any public GitHub repository, with no install.
No repository. Clone one yourself later, from the terminal.

Then choose the Branch. The repository is cloned once, into ~/<repo>, on the Hangar's first start: acme/web lands in /home/hangar/web. A repository named go or bin lands in ~/go-repo or ~/bin-repo, because those directories already mean something on the machine. From then on the clone is yours, and Out Plane never clones or pulls it again. The repository cannot be changed after the Hangar is created.

If the clone fails, for example because the repository or the branch cannot be read, it is not tried again. The terminal says why when it opens, with the git clone command to run by hand. To push from the Hangar, see Push from a Hangar.

Each agent signs in from its own terminal with your plan, the way it does on your laptop. If you would rather use an API key, add it under Environment variables and the agent picks it up:

Agent	Variable
Claude Code	`ANTHROPIC_API_KEY`
OpenAI Codex	`OPENAI_API_KEY`
Cursor	`CURSOR_API_KEY`
Pi, OMP, OpenCode	Any model provider's key
Devin CLI	Signs in from the terminal only

Everyone in the team can read every variable on a Hangar, so a personal key set here is shared with the whole team.

Add Variables and Groups

Environment variables are available in every terminal and to every agent. You can also link shared variable groups. Both can be changed later on the Hangar's Environment tab. HOSTNAME, OP_*, KUBERNETES_* and HANGAR_* are reserved.

Review the Machine

Runtime image. The Out Plane Hangar image, which comes with git, gh, node, pnpm, python, go, psql, sqlite, build tools, tmux and the Out Plane CLI.
Size. One size during the beta: 2 vCPU and 4 GB of memory, with a 10 GB disk.
Auto-pause. How long the Hangar may sit idle before it pauses: 15 or 30 minutes, 1, 2, 6, 12 or 24 hours, or Never. 30 minutes is the default, and you can change it later in the Hangar's Settings. See Pause and Auto-Pause.

Create

Select Create Hangar. The page opens on the new Hangar while the machine starts, and the terminal appears as soon as it is ready. The agents install on this first start, at their newest version.

Work in the Terminal

The terminal fills the Hangar's page. Its tabs are the Hangar's windows: one for each agent, named after it, plus any shells you open.

+ opens a new window with a shell, starting in your home directory.
× on a tab closes that window. Anything running in it stops, including an agent in the middle of a task. Files on the disk are kept.
Switching tabs keeps every tab you have opened connected, so you come back to what it was printing.

The session is shared and it keeps running. Everyone who opens the Hangar sees the same windows and types into the same programs. Leaving stops nothing: what runs there keeps running with nobody connected, and opening the Hangar again finds it as it was. When an agent exits, its window stays open on a shell, so you can start it again.

A new shell greets you with the Hangar's name, its agents and the keys outplane hangar connect uses. In the console, the tabs, + and × do those jobs. To turn that off, run touch ~/.hushlogin.

Connect from Your Own Terminal

Select Connect on the Hangar's page to copy the command that joins the same session from your own terminal with the Out Plane CLI:

outplane hangar connect <HANGAR_NAME> --team <TEAM_SLUG>

The hangar commands need outplane v0.2.11 or newer (hangar port, hangar metrics and hangar restart need v0.2.12 or newer, and hangar pause, hangar resume, hangar update and --hangar on the env commands need v0.2.13 or newer, and --repo on hangar create needs v0.2.15 or newer); run outplane update if yours is older. It shows the same windows as the console's tabs, with the list along the bottom. A window opened or closed in one place appears or goes in the other within a second or two.

Keys	What they do
`Ctrl-b w`	List the windows and switch between them
`Ctrl-b c`	Open a new window (or click + new in the list along the bottom)
`Ctrl-b d`	Leave. Everything keeps running

If your own terminal already uses Ctrl-b, press it twice: Ctrl-b Ctrl-b d.

What a Hangar Keeps

Where	Size	Kept
`/home/hangar`, your home directory	10 GB	Across restarts and pauses, until the Hangar is deleted
Everywhere else, such as `/tmp`	Up to 4 GB	Until the machine restarts or pauses

Clone repositories, install tools and keep agent settings under /home/hangar, and they survive a restart. The agents keep their own configuration and sign in there too, so they stay signed in. If temporary files outside the home directory grow past 4 GB, the machine restarts to clear them; the home directory is untouched.

A restart ends what was running in the terminal. The Hangar starts again with a window for each agent, and everything under /home/hangar is where it was.

After the first start each agent updates the way its vendor intends: some on their own, others when you ask (for example codex update). The Out Plane CLI updates with outplane update.

Push from a Hangar

Out Plane only clones the repository you chose, and keeps no GitHub access on the Hangar afterwards. To push, or to fetch a private repository later, sign in to GitHub in the Hangar's terminal, in one of two ways:

The GitHub CLI. Run gh auth login and follow its prompts. It prints a code to enter on GitHub in your own browser, and offers to set up git to use the sign in.
A fine-grained token. Create a fine-grained personal access token on GitHub, limited to that one repository, with Contents set to read and write. Paste it when gh auth login asks how to sign in.

The sign in is kept on the Hangar's disk, and everyone in the team can open the Hangar. Everyone who does, and every agent on it, pushes as that GitHub identity. A token limited to one repository keeps that to the one repository.

Reach Your Apps and Databases

A Hangar reaches your team's applications over the private network, the same way your applications reach each other, so an agent can call a private service while it works. It reaches databases and the internet like any other machine.

Use the Out Plane CLI in a Hangar

The Out Plane CLI is installed in every Hangar, so your agents can deploy, read logs and manage the team's resources from its terminal. Give it a credential in one of two ways:

Sign in. Run outplane login in one of the Hangar's terminals. It prints a link to the console, where you create a token, and you paste the token back into the terminal. The credential is kept under /home/hangar, so it survives restarts and pauses. outplane logout there removes it.
A variable. Add an API token as OUTPLANE_TOKEN on the Environment tab. It applies the next time the Hangar starts.

Anyone who can open the Hangar can use that credential, and that is everyone in the team. It has the access of any team token: full API access for the team, with no per token scopes.

Ports and Previews

When an agent starts a dev server, open its port to look at what it built or to let your team's applications call it. Open Show details → Network, select Add port, choose the port and its protocol, tick Public HTTPS access (or Public TCP access for a TCP port) if it should have an address on the internet, and select Save.

Every open port is reachable from your team's applications:

Port	Address	Reached by
Any open port	`{name}:{port}`	Your team's applications, over the private network
Public HTTP or H2C	`https://{name}-{port}-{team}.outplane.app`	Everyone on the internet
Public TCP	A host and port number, assigned when you save	Everyone on the internet

{name} is the Hangar's name and {team} your team's slug.

Up to 3 ports. Each is 1 to 65535 and used once. 7070 is the Hangar's own and cannot be opened.
No restart. A save applies within seconds and there is no deployment. The Hangar keeps running, and so do its terminal and its agents.
Listen on 0.0.0.0. A dev server that listens on localhost is reached by nothing outside the Hangar: its public address answers 502, and applications and TCP clients have the connection refused. Many dev servers listen on localhost unless told otherwise.

A public port is open to everyone on the internet. Hangars take no IP access profile and no custom domain, so keep a port private unless what it serves is fine for anyone to see.

Environment

Open Show details → Environment to change the Hangar's variables and the variable groups linked to it.

Environment variables. Add, change or remove variables, then select Save, or Save & restart to apply them now. Save & restart asks first, because a restart ends everything running in the terminal. A paused Hangar offers Save only.
Variable groups. Link group links a shared group, and × next to one unlinks it.

Saving changes nothing that is running. A Hangar is started from what is saved, so a change applies the next time it starts: at the next Restart, or at Resume when it is paused. A change made to a linked group on the group's own page applies the same way, the next time the Hangar starts.

Status

The Hangar's state shows next to its name and in its list:

Status	What it means
Deploying	The machine is starting. The terminal appears when it is ready.
Ready	Running. Open the terminal or connect.
Failed	The machine could not start. Delete the Hangar in Settings and create it again.
Crashed	It stopped unexpectedly and restarts on its own. If it stays down, delete it and create it again.
Paused	Its machine is stopped and its disk kept. Select Resume to start it again. See Pause and Auto-Pause.

Details and Settings

Show details on the Hangar's page opens a side panel:

Overview. Status, size, disk, auto-pause, when it was created, its repository, its agents, and what it is using. See Usage.
Network. The ports its dev servers are reached on. See Ports and Previews.
Environment. Its variables and linked variable groups. See Environment.
Settings. Change its auto-pause, or delete the Hangar. See Pause and Auto-Pause.

Usage

The Overview's Usage section shows what the Hangar is using. CPU and memory are charts of the last hour, drawn against what its size allows: 2 vCPU and 4 GB of memory. The disk is a bar showing how full /home/hangar is. Temporary storage outside the home directory is not shown.

When memory reaches 90%, a warning appears. A Hangar that reaches its memory limit freezes rather than restarting, and its status can still read Ready, so stop what is using the memory before it gets there.

Restart a Hangar

Select Restart in the header of the Hangar's page and confirm. The Hangar starts again on a new machine with the same disk:

What stops. Everything running in its terminal, agents included. Anyone connected is disconnected.
What stays. Everything under /home/hangar, and its ports and variables.
What applies. It starts with its saved variables, groups and ports, so a change saved on the Environment tab since it last started applies now.
How long. It is back in under a minute. Its status reads Deploying, then Ready, with a window for each agent again.

A restart is the way out of a Hangar that froze at its memory limit (see Usage). It is also how an existing Hangar picks up a newer Hangar image, because the new machine pulls the image again. A Hangar with no machine running, such as one that never started, has nothing to restart.

Pause and Auto-Pause

Select Pause at the top of the Hangar's page and confirm. Its machine stops:

What stops. Everything running in its terminal, agents included. Anyone connected is disconnected.
What stays. Everything under /home/hangar, and its ports, its variables and its auto-pause setting.
While it is paused. Its status reads Paused and it takes no connection: the terminal, Connect and Restart are gone until it is resumed, and it uses no CPU or memory.

Select Resume to start it again. It is back on a new machine in under a minute, with a window for each agent. What was running before the pause does not come back on its own. It starts with its saved variables, groups and ports, so a change saved while it was paused applies now.

Auto-Pause

A Hangar also pauses itself once it has been idle for its auto-pause time. Idle means its terminal has had no output in any window and no key from anyone connected, in the console or the CLI. An agent at work usually keeps printing, so it keeps the Hangar running with nobody watching. One that is waiting for an answer prints nothing, and counts as idle.

Choices. 15 or 30 minutes, 1, 2, 6, 12 or 24 hours, or Never. A new Hangar starts with 30 minutes unless you choose otherwise when you create it.
When. Out Plane checks every 5 minutes, so a Hangar set to 30 minutes pauses 30 to 35 minutes after the last activity.
Change it. Open Show details → Settings, choose a time under Auto-pause and select Save. The next check uses it, and nothing restarts.

An auto-paused Hangar is the same as one you paused yourself: its files are kept, and it takes no connection until someone selects Resume.

Delete a Hangar

Open Settings → Delete Hangar and type the Hangar's name to confirm. The disk is deleted with it, together with everything its agents wrote that was not pushed anywhere. There is no undelete. Anyone connected is disconnected.

The name is free again afterwards, for a Hangar or an application, and the team has room for another Hangar.

Limits

Limit	Value
Hangars per team	5, on every plan
Size	2 vCPU and 4 GB of memory
Persistent disk	10 GB, at `/home/hangar`
Temporary storage	4 GB, outside the home directory
Ports	Up to 3, never `7070`
Auto-pause	15 minutes to 24 hours, or Never. 30 minutes by default
Name	5 to 45 characters, letters and numbers, shared with applications
Price	Free during the beta

The name, the agents and the repository are chosen when the Hangar is created. The ports, the variables, the variable groups and the auto-pause can change at any time, and a change to variables or groups applies the next time the Hangar starts.

From the CLI and Agents

Everything here can also be done from a terminal: outplane hangar create, list, get, connect, pause, resume, update, restart, port, metrics and delete, with outplane env set --hangar and outplane env group assign --hangar for its variables. See hangar in the CLI reference. A coding agent working with the CLI can create a Hangar and check that it is ready, then hands you the connect command, because joining the terminal needs a person at a real terminal. An agent inside a Hangar can open a port for its own dev server with outplane hangar port set and give you the address. Deleting stops for your confirmation, as every deletion does.