Give every agent session its own VM. Give every agent session its own VM.

##Why pier

Coding agents changed what a dev environment is. A session is no longer you at one machine. It is an agent that runs for hours and wants its own branch, its own ports, its own docker daemon. And you want several at once. Every existing place to run them fights you:

• [x] Your laptop. Sessions fight over ports and files. Closing the lid kills the run.
• [x] Hosted agent platforms. Your code, your secrets, and your agent's credentials live on someone else's infra, billed by the seat.
• [x] A cloud dev box. Bills 24/7 while the agent thinks and while you sleep. You still hand-build repo, auth, secrets, and tools for every session.

pier makes each session a micro-VM that manages its own lifecycle. One command launches a VM in your cloud account and drops you into tmux inside it, with:

• [+] your repo on a fresh branch, uncommitted edits included
• [+] Claude Code and Codex installed and authenticated
• [+] your MCP servers configured
• [+] your dev environment built by the repo's own setup script

##What you get

• [+] Parks itself. An in-VM supervisor stops the instance once the agent goes quiet. The disk persists.
• [+] Resumes where you left it. Files, branches, and credentials intact, tmux windows back, agents reopened on their conversations.
• [+] Sessions as hostnames. pier proxy serves the dev server at checkout-flow.pier:3000, mirrored on localhost too.
• [+] One-command resize. Outgrown the box? One park and resume cycle swaps the machine type, disk intact.
• [+] GitHub-first transfer. The VM fetches your repo straight from GitHub. Only secrets ride the tunnel.
• [+] Prebuilt repo images. pier bake runs your setup once and images the result. New sessions skip the cold install.
• [+] Warm pools. A parked, set-up session waits for each baked repo. pier <branch> claims it in about 25 seconds.
• [+] Your browser, while attached. URLs the session opens land on your laptop and its ports mirror to localhost, so in-session logins just work.
• [+] No control plane. No server, no database, no daemon. Session state lives in instance tags.
• [+] One transport. Attach, exec, file push, and port forwards are all OpenSSH, direct or through the cloud's tunnel.

##The numbers

Measured on AWS. With the default Fast profile a new session claims a parked, set-up session from the repo's pool and is on your branch, services running, in about 25 seconds. Without a pooled session, a create from the repo's prebuilt image is attachable in about 40 seconds while setup finishes in the background. A parked session is back in about 25 seconds. GCP wakes slower: a resume takes about a minute.

##How it works

A session is one VM plus its persistent disk, tagged and namespaced by your caller identity. All state lives in those tags and on the disk. There is nothing else to operate, back up, or pay for.

flowchart LR
  subgraph laptop["laptop"]
    cli["pier CLI / app"]
  end
  subgraph aws["AWS account (yours)"]
    api["EC2 API
create / stop / start / tags"]
    subgraph vm["session VM"]
      tmux["tmux · claude / codex"]
      sup["pier-supervisor
parks the VM when detached and quiet"]
    end
  end
  cli -- "aws cli" --> api
  cli -- "ssh, SSM tunnel as fallback" --> tmux
          

GCP is the same picture with gcloud, the GCE API, and Google's IAP tunnel in place of SSM.

• [+] The supervisor samples every 5 seconds for attached and busy. Detached and quiet past the idle timeout parks the VM.
• [+] The VM holds no cloud credentials. Parking is the VM running shutdown -h now. Anything needing account credentials happens from the laptop.
• [+] A runaway cap parks a looping agent anyway, so it cannot burn compute for days.
• [+] Before parking, the supervisor snapshots the tmux layout. The next boot rebuilds it, reopens claude and codex on their conversations, and restarts the Docker containers that were running.

##vs. other tools