Devboxes

A devbox is a virtual machine for one engineer, a team or an agent. It is built from a template, keeps a persistent home, has local NVMe scratch, and comes with AI coding tools that never hold long-lived keys. The same spec runs on a server pool of your own servers or on the Frazer fleet. One policy gives a whole team boxes, with a plan that shows the count, the cost and the pool’s room before anything is created, and one revoke ends every way in.

Product overview: Devboxes.

How it works

Each box is its own VM, never a shared Linux user, so Docker works inside it and one person’s build cannot fill another’s disk. On your servers, a box runs on a server pool of its project, or on a pool another project shares with it, as a VM in its project’s namespace and VPC network; a server runs only your organization’s boxes. On the Frazer fleet, boxes are VMs too, and a server never hosts two organizations’ boxes. Every box shows the server, the CPU and the drives it runs on. Boxes run as microVMs on Frazer’s runtime layer; Windows and long-lived GPU boxes run as full VMs.

Memory is reserved and never overcommitted. CPU overcommit is written on each size (2:1 by default), never hidden. A box has an IPv4 address and an IPv6 address in its subnet, and people reach it through Frazer Access or Frazer Link, never through a public address. Outbound port 25 is blocked.

• Devbox: a VM with a home volume, scratch, the box agent and the tools from its template and profile.
• Template: what is installed. A devcontainer.json from your repository, or a Frazer base image (Ubuntu 24.04 with Docker, the box agent and OpenSSH trusting your organization’s SSH certificate authority). Templates have versions, such as checkout-api@v7, and are shared with runners and agent sessions.
• Provisioning profile: how the tools on the box are configured: skills, MCP servers, connections, company knowledge, models, instructions, dotfiles and editor extensions. It applies live, without a rebuild.
• Devbox policy: binds a template, a size and a placement to IAM groups, for example “every member of engineers gets one standard box”.
• Placement: a server pool (--pool) or a location on the Frazer fleet (--location us-virginia1). The two differ in one flag.
• Members: Owner, Collaborator and Viewer, for people or groups. Every grant except the owner’s expires.
• Session: one task thread with an agent, bound to a box and a workspace (repository, branch, folder). The transcript stays on the box; you resume it from any device.
• Home and scratch: the home persists and is snapshotted. Scratch is local NVMe for caches and build output, and is erased on stop.

Every box ships with the Frazer AI pack: the Frazer harness, Claude Code, Codex CLI and Hermes, an MCP pack with the Frazer MCP server pre-wired, and a per-box browser service. By default, the tools reach models through the Frazer LLM gateway with a token minted per box and person that lasts at most one hour; nobody copies an API key onto the box. Claude Code runs on your organization’s own Anthropic key, or your own Bedrock, Vertex or Foundry credential, connected to the gateway; Frazer never bills Claude tokens used in Claude Code. A person may instead sign in with their own subscription on their own box; it is labeled in the console and never pooled.

Sizes

Your organization’s devbox settings decide which sizes people may pick.

Size	vCPU	Memory	Home	Scratch	Fits
small	4	16 GiB	50 GiB	50 GiB	Front-end work, scripts
standard	8	32 GiB	200 GiB	100 GiB	Most services
large	16	64 GiB	200 GiB	200 GiB	Go monorepo builds, several agents in parallel
xlarge	32	128 GiB	500 GiB	400 GiB	Heavy builds and many agents

A box can also take a GPU. On the fleet, a whole GPU is passed into the VM and is reset and scrubbed between organizations. On your servers, a GPU is split by MIG or time-slicing only between boxes of one project; across projects, each box gets whole GPUs. GPU boxes stop after 15 idle minutes.

Shared build caches

A hundred boxes building the same repository should not each fetch, compile and store the same objects. Boxes in a pool read a shared tier of Frazer Cache on the pool’s servers and keep a hot tier on their own scratch:

1. The box’s local NVMe answers first.
2. A miss asks the pool’s cache service by the exact key the build tool computes (for Go, through GOCACHEPROG).
3. Still a miss: the box builds and keeps the result locally.

Only prebuild workers and CI builders with a signed workload identity publish to the shared tier; boxes read it and write their own. An opt-in team tier lets members of one team share each other’s outputs. The policy’s caches setting picks the pool tier, the ecosystems and the team tier, caches.policy names the cache policy, and the box’s Overview shows the pool tier it uses.

Create a devbox

Every change in Frazer is a plan you apply. Add --dry-run to any command that changes something to print the plan and stop. Creating your own box applies at once when the policy checks pass.

1. Sign in with frazer login, or open the console. You need access to devboxes in the project and room in its quota.

2. Create the box.

   CLI

   frazer devboxes create lena-api \
     --project acme-staging \
     --template checkout-api@v7 \
     --size large \
     --pool vint-hill-default

   To place it on the Frazer fleet instead, replace --pool vint-hill-default with --location us-virginia1.

   Console

   Open My boxes from the avatar menu and choose New box, or press C. Pick a repository or a template; when a prebuild exists for the branch, the template shows Prebuild ready. Pick a size (only the sizes your policy allows are listed) and keep or change the prefilled name. The line below says where the box runs and what it costs, for example “Your servers · vint-hill-default”. Choose Create box.

   For the source branch, home size, lifecycle, models, secrets or members, choose Advanced… instead: its plan rail lists the changes, the checks and the cost before Apply.

3. Watch it start. The box moves from Creating to Starting to Running, and its card shows each step: claim a warm box, attach the home, boot, agent ready.

4. Open it from the card’s Open in VS Code ▾ button, which remembers your last choice, or from a terminal:

   frazer devboxes ssh lena-api

Give a team devboxes

A devbox policy gives every member of an IAM group a box. Groups can be managed by hand or synced from your directory.

1. Write the policy.

   policy.yaml

   # projects/acme-staging/devboxPolicies/engineering-standard
   subjects: [groups/engineers]
   project: projects/acme-staging
   template: workspaceTemplates/checkout-api@v7
   size: standard
   placement: { pool: projects/acme-infra/locations/us-virginia1/serverPools/vint-hill-default }
   perPerson: { count: 1, max: 2 }
   idle: { stopAfter: 30m, maxRunning: 12h, schedule: "Mon-Fri 08:00 local" }
   llm: { mode: gateway, key: llmKeys/anthropic-main, budgetPerPersonMonthly: 300 }
   onLeave: { stop: now, snapshotHome: true, deleteVmAfter: 30d, keepSnapshot: 90d }

   The pool here belongs to acme-infra and is shared with acme-staging. For the Frazer fleet, write placement: { location: us-virginia1 }.

2. Print the plan.

   frazer devboxes policies apply -f policy.yaml --dry-run

   Output

   Plan  projects/acme-staging/devboxPolicies/engineering-standard   (devboxes)
     + 12 devboxes (checkout-api@v7, standard) for 12 members of groups/engineers
     + 2,400 GiB of home volumes on pool vint-hill-default
     Capacity  pool vint-hill-default has room at peak, N+1 holds          OK
               acme-staging's share of the pool: within its limit          OK
     Cost      on your pool: no compute fee (the server fee covers it)
               LLM budget up to 300 per person a month, metered by the gateway

3. Apply it: run the command again without --dry-run and answer y. You can also review and apply it in the console under Devboxes › Team policies.

After apply, each person’s box appears. A new group member gets a box at the next directory sync, and a person who leaves the group gets the policy’s onLeave. The policy’s Members and boxes tab shows provisioning progress (“12 of 12 provisioned”); Budget sets a per-person monthly LLM budget that alerts at 80 % and stops at 100 %. People can still create boxes themselves inside the project quota.

The Fleet tab is the admin view: boxes running and idle, outdated templates, failed prebuilds, pools near their limit, cost by team or policy, and template versions in use.

Connect to a devbox

Every way in uses one identity (your Frazer sign-in), one device check (Frazer Access) and one revoke. Your laptop needs no separate VPN client: the frazer CLI and the Frazer app connect to Frazer Access themselves, and fall back to Frazer Link when the laptop is not connected.

Client	How it connects
Frazer app (recommended)	Sign in, pick a box (it starts a stopped one), and the app connects with a one-hour token bound to you, the box and the device.
VS Code	The Frazer extension lists your boxes and writes the SSH entry; VS Code’s Remote-SSH connects through frazer devboxes proxy.
Other VS Code-based editors	Their own remote-SSH, plus the same Frazer extension from Open VSX.
JetBrains	Toolbox remote development over SSH; the Frazer plugin for JetBrains Toolbox lists your boxes.
Zed	Zed’s headless server on the box, over SSH.
Hermes	frazer devboxes open lena-api --hermes writes the gateway entry and token for Hermes Desktop; the Hermes TUI runs over SSH.
Terminal	frazer devboxes ssh lena-api, or ssh lena-api from a device on Frazer Access.
Browser	A web IDE and the web terminal behind Frazer sign-in, for the owner and members only.

To wire any SSH-based editor by hand, point it at the proxy command:

~/.ssh/config

Host lena-api
  ProxyCommand frazer devboxes proxy %h

frazer devboxes ssh fetches an SSH certificate from your organization’s certificate authority for each connection, valid for 8 hours. No key is ever stored on your laptop or the box. To run one command, or to sync your working tree and run something there, pass the command after --; arguments arrive exactly as you typed them:

frazer devboxes ssh lena-api -- uptime
frazer devboxes rx lena-api -- go test ./...

Work with an agent happens in sessions. A session keeps running on the box when you close your laptop; open it again from the Frazer app on another device and it continues where it stopped. A stopped box starts when you resume a session on it. Continue in the background hands a session to a managed agent so the box may stop, and Take back brings it into the box again.

Share a devbox

A box can have more members than its owner, so two engineers can pair on one machine or a team can keep a shared box.

Role	Can	Cannot	Default grant
Owner	Everything: every way in, sudo, Docker, start, stop, resize, snapshot, share, transfer, delete		No expiry
Collaborator	Their own account on the box, every way in, their own agent profile and sessions, write in /workspace, share previews up to their own grant, start and stop	Delete, resize, transfer or grant roles; sudo and Docker only when the box’s collaboratorAdmin is on	7 days, renewable
Viewer	Watch shared sessions and terminals read-only, open previews, read Overview and Activity	Any shell, file write, port share or start	8 hours, renewable

1. Open the box and go to Access › Invite.
2. Choose people or groups, a role, and an expiry (1 hour, 8 hours, 1 day, 7 days, or a custom date up to the cap your policy sets). Add a note if you like.
3. Send the invite. It applies at once unless an access rule needs an approval; then it waits for the approvers.

The grant is a resource of its own:

projects/acme-staging/devboxes/lena-api/members/noah

principal: users/noah
role: collaborator
expireTime: 2026-10-21T17:00:00Z # required for everyone but the owner; the maximum is set by policy
grantedBy: users/lena
recordSessions: false

Someone who opens a box link they cannot use chooses Request access (role, reason, duration), and the owner gets an approval request in the Inbox, Slack and email. Members get a notice 1 day and 1 hour before a grant expires and can renew it in one click. At expiry, the grant is revoked the same way offboarding revokes access, for that one box.

Each Owner and Collaborator gets their own account and home on the box (/home/lena, /home/noah) and a shared /workspace. A team box is owned by a group (ownership: {group: groups/platform}) and names one accountable contact in its header; every member of the group is an Owner.

Note

The VM is the isolation line between boxes and between organizations. Inside one box, members trust each other the way people sharing a Linux server do, and the Access tab says so.

Ports and previews

When a process listens on a port, it appears under Ports and previews, marked “detected”. Each port gets an HTTPS URL on the apps domain frazer.run, for example https://3000-lena-api-acme.preview.frazer.run, behind Frazer sign-in. A port is private to you until you share it, and every share has an expiry:

frazer devboxes ports share lena-api 3000 --to group:engineers --for 8h

Visibility levels are Private, People, Group, Org and Public, capped by policy; Public is off unless an org admin raises the cap. A member can share only what they can reach themselves.

Templates, profiles and change reports

A template decides what is installed in the image. A provisioning profile decides how the tools are configured for the people and agents who use the box, and it applies live. One profile spans many templates.

Templates. Create a template from a repository (Frazer detects .devcontainer/), from an image, or from a running box with Save box as template. Build an organization image with extra packages from a Dockerfile or devcontainer with frazer devboxes images build; it lands in Frazer Registry. Each template version shows the diff of devcontainer.json and the boxes on it, and rolls out one of three ways: notify owners, update on next stop, or force by a date. A box on an older version shows “checkout-api@v8 available · Rebuild keeps your home · Update on next stop”. Prebuilds build the devcontainer and warm the caches on push to a configured branch, on a config change or nightly, so new boxes start from a ready volume.

Profiles. Under Devboxes › Profiles, a profile holds skills, MCP servers, connections (GitHub, Linear, Slack and others, each person signing in for themselves), company knowledge bases, models, instructions, dotfiles, editor extensions, agent settings and references to secrets. Profiles stack:

org baseline (acme-baseline@v12) → team profile (team-payments@v4) → devbox policy → person

Each layer adds items and may change default items from the layers above; nobody below a layer changes its locked items. Every item has an enforcement:

• locked: people cannot remove or change it, and the box agent puts it back if it drifts.
• default: applied, and people may override it; overrides are shown.
• suggested: offered to the person, not applied.

The resolved profile is under the box’s Settings › Profile, with the origin of every item. Profile versions roll out like templates: notify, apply on next start, or apply now for items that reload live (MCP servers, skills, instructions, models).

Change reports. The policy’s selfProvisioning setting decides whether people may add things to their own box: allow, report (the default) or block. With report, the box agent files a change report for each item a person adds, removes or changes (an MCP server, a skill), with its use, its risk and the other boxes that have it. Under Devboxes › Changes, an admin can Promote to profile (a plan that picks the layer, enforcement and rollout; each person gets their own “Connect” prompt, so no one’s sign-in is copied), Keep on this box (an exception that expires after 30 days by default), Block (removes it and adds it to the deny list), or dismiss it. When three or more boxes add the same item, it becomes one “Suggested for the fleet” row.

Shared models. One open model on your own GPU server can serve many boxes. Under Devboxes › Shared models, you publish an AI endpoint to the boxes of a profile as a route of the LLM gateway, with quotas per box and per person on concurrency, tokens per minute and context length.

Stop, snapshot and delete

Boxes stop when nobody uses them, and a stopped box costs storage only. The box always shows why it is running or why it stopped.

State	What you see	What happens next
Running	“Running · stops in 18 min” or “Running · agent busy”	The idle timer pauses while there is activity.
Asleep (personal plans)	“Asleep · wakes on your next keystroke”	Instead of stopping after 5 idle minutes: memory saved, no compute drawn; a keystroke, SSH, editor, preview request or agent call wakes it in about a second (a target); after 7 days asleep it stops with the home kept.
Stopped	“Stopped · by idle 2 h ago”	Archived after 14 days stopped (the policy can change this).
Archived	“Archived · home in object storage”	Deleted after 30 more days, with an email 1 day before and a Keep box button.
Updating	“Updating to v8”	Running again; a rebuild keeps the home.
Failed	“Failed · image pull” with Retry and Explain	You retry once the cause is fixed.

Activity is any of: an IDE connection, an SSH session with input or output, the web terminal, a busy agent session (Claude Code, Codex or Hermes), a request to a preview in the last 5 minutes, or CPU over 30 % (off by default). Viewing settings or ports is not activity. Five minutes before an idle stop you get a desktop notification, a terminal message and an IDE notice, each with Keep running 2 h. Change the idle stop, the maximum running time and a start schedule in the box’s Settings › Lifecycle, within your policy’s caps.

frazer devboxes stop lena-api
frazer devboxes start lena-api

Caution

Scratch is erased on stop. Keep work in your home or in /workspace; caches on scratch refill from the shared tiers.

Storage and snapshots. Where the site has replicated storage, the home is a replicated volume and the box can restart on any server of the site. Otherwise the home sits on local NVMe and is copied to object storage on every stop and nightly; the box’s Overview states which. The Snapshots tab lists every snapshot (nightly, on stop, manual, template) with its size and how long it is kept. Choose Snapshot now or run frazer devboxes snapshots create; Restore into a new box (or frazer devboxes snapshots restore) and Clone start a new box from one. A deploy never deletes a snapshot.

Resize. Changing the size is a plan, in Settings › Size or from the CLI:

frazer devboxes resize lena-api --size xlarge --dry-run

Delete. Only an Owner can delete a box, from Settings › Danger zone or with frazer devboxes delete lena-api. The dialog says how long the home snapshot is kept. A deleted box is restorable for 7 days from Activity.

Access and audit

• Who creates boxes. Project members with access to devboxes create boxes inside the project quota and the sizes their policy allows. Org admins set defaults under Org › Settings › Devboxes: allowed sizes, boxes per person, idle and retention caps, the port visibility cap and the default LLM mode.
• Org roles do not open a shell. An org Admin or Infra admin can stop or snapshot any box, and the action is audited. To get a shell or read transcripts, they add themselves as a member like anyone else, which is audited and visible to the owner. Break-glass lets an org Admin grant themselves Collaborator for 1 hour with a reason; the owner is notified at once and the event is flagged in the audit log.
• Verified identity. A connection is allowed only when you have a Frazer session with a second factor, a device enrolled in Frazer Access (with posture checks when your organization turns them on), and a certificate or token bound to you, the box and the device. Collaborator access to someone else’s box, and every guest, also needs a passkey step-up within the last 12 hours.
• Approvals by rule. Access rules in the policy or org settings decide which grants need an approval, for example Collaborator on boxes labeled data: production needs the owner and an Infra admin. Viewer needs none. People outside your organization are off by default; when an org Admin turns guests on, each guest grant needs approval, lasts at most 7 days and is recorded.
• Recording. With recordSessions: true, the box agent records that member’s terminal sessions to your organization’s audit bucket, kept as long as the audit log, and the person sees “This session is recorded”.
• What is logged. Every connection writes a devbox.connect audit entry with the person, device, path, source, grant and session. The box’s Activity tab shows starts and stops (by idle, by a person, by schedule), certificates issued, ports shared, tokens minted and snapshots.
• Transcripts stay private. Owners and the people they share a session with read transcripts. Org admins see the session index (title, state, cost) and not the transcripts, unless an org policy with a visible notice says otherwise.
• An agent out of scope is contained. An agent that acts outside its scope in a box is contained (its session stopped, its credentials revoked, its workspace snapshotted); the box and the people on it keep working.
• Offboarding is one operation. Removing a person from the organization revokes their SSH, Frazer Access, LLM and Git access and stops their boxes; each home is snapshotted as the policy’s onLeave says, and box data is never deleted implicitly. Their accounts on shared boxes are removed, and their live sessions ended, within a minute.

Limits and quotas

These are the defaults. Your organization’s devbox settings and policies may set them lower or higher.

Setting	Default
Idle stop	30 minutes (15 minutes for GPU boxes), warning 5 minutes before
Maximum running time	12 hours
Stopped box archived after	14 days
Archived box deleted after	30 days, email 1 day before
Deleted box restorable for	7 days
Collaborator grant	7 days, renewable
Viewer grant	8 hours, renewable
Guest grant	Off; at most 7 days when turned on
Port share expiry	1 hour to 7 days
Preview request counts as activity for	5 minutes
SSH certificate	8 hours
App gateway token	1 hour
LLM token on a box	At most 1 hour
Passkey step-up	Within the last 12 hours
Break-glass grant	1 hour
“Keep on this box” exception	30 days
Session index kept	180 days
CPU overcommit	2:1, stated per size; memory never overcommitted

Devboxes count against the project’s quota and, on your servers, against the project’s share of the server pool.

Pricing

On your own servers, devboxes are included in the server fee; on the Frazer fleet, a box is billed per second while it runs and for storage only while it is stopped, and LLM tokens are billed either way.

Devboxes	On your servers	On the Frazer fleet
Price	Included	Same rates · a 4 vCPU / 16 GiB box ≈ $0.232 / hour

Every line, with the estimator: pricing.

When a project reaches a capped budget, its boxes on the Frazer fleet stop, and every home and snapshot is kept.

Troubleshooting

Symptom	Cause	Fix
“Pool full” when you create a box	The server pool, or your project’s share of it, has no room for the size.	Pick a smaller size, place the box on the Frazer fleet with --location us-virginia1 (the dialog offers it), or ask an infra admin to add a server to the pool.
The box shows Failed · image pull	The template’s image could not be pulled.	Choose Explain for the cause and the logs drawer, fix the template or image, then Retry.
The card says “Taking longer than usual”	One start step (claim a warm box, attach the home, boot, agent ready) is slow.	Choose Explain to see which step and why.
The box stopped while you were away	Idle stop, the maximum running time, or the schedule.	The box says which. Choose Keep running 2 h, or change Settings › Lifecycle within the policy’s caps.
Build caches or temporary files are gone after a restart	Scratch is erased on stop.	Keep work in your home or /workspace; caches refill from the pool tier.
You cannot connect	The device is not enrolled in Frazer Access, your session lacks a second factor or a recent step-up, or your grant expired.	Enroll the device, sign in again with your passkey, or choose Renew (or Request access).
A preview URL refuses the person you sent it to	The port is private, or the share expired or is above the policy cap.	Share the port with that person or their group, with a new expiry.
Claude Code or Codex requests are refused	Your monthly LLM budget is used up, or your organization switched LLM access off.	Ask an admin to raise the budget in the policy’s Budget tab.
An MCP server you added disappeared	An admin blocked it, or the profile locks MCP servers (“MCP: locked to profile”).	Read the notice with the reason; ask an admin to promote it to the profile.
Fleet boxes stopped and new ones are refused	The project reached a capped budget.	A billing admin lifts the cap with a reason; homes and snapshots are kept.
The box shows a newer template version	The template has a new version.	Choose Update on next stop; the rebuild keeps your home.

Reference

CLI

Command	What it does
frazer devboxes create	Create a devbox from a template, on a server pool (--pool) or the Frazer fleet (--location).
frazer devboxes list	List the devboxes in a project.
frazer devboxes get	Show one devbox and its state.
frazer devboxes start	Start a stopped devbox.
frazer devboxes stop	Stop a devbox; the home is kept and scratch is erased.
frazer devboxes resize	Change a devbox's size, as a plan.
frazer devboxes delete	Delete a devbox (Owners only); it stays restorable for 7 days.
frazer devboxes ssh	Open a shell, or run one command, with a short-lived SSH certificate over Frazer Access or Frazer Link.
frazer devboxes proxy	The ProxyCommand that IDE remote-SSH connections use.
frazer devboxes rx	Sync the working tree to a devbox and run a command, arguments passed verbatim.
frazer devboxes open	Open a devbox in VS Code, JetBrains, the browser or Hermes.
frazer devboxes snapshots create	Snapshot a devbox's home.
frazer devboxes snapshots list	List a devbox's snapshots.
frazer devboxes snapshots restore	Restore a snapshot into a new devbox.
frazer devboxes ports share	Share a port's preview URL with people or a group, with an expiry.
frazer devboxes policies apply	Create or change a devbox policy from a file; prints the plan first.
frazer devboxes templates build	Build a workspace template.
frazer devboxes templates publish	Publish a new version of a workspace template.
frazer devboxes images build	Build an organization image from a Dockerfile or devcontainer into Frazer Registry.

All of them: CLI reference.

Events

Event type	When it is sent
frazer.devbox.created.v1	A devbox was created.
frazer.devbox.stopped.v1	A devbox stopped (idle, schedule, a person, or a spend cap).
frazer.devbox.change.reported.v1	The box agent filed a change report for something a person added, removed or changed on a box.

All of them: Events reference.

Related

• Give your team devboxes: templates, policies and one-click open.
• Devboxes: the product page.
• Frazer app: the recommended way into a box.
• GitHub runners: CI on the same workspace templates and caches.
• Frazer Agents: hand a session to an agent that keeps working.
• LLM gateway: keys, budgets and models for the tools on your boxes.