Skip to main content
Everything you choose when a Devbox is created: how big it is, what image it runs, which repository it checks out, and how long it lives. For the full flag set, see devbox create.

Creating a Devbox

Give the Devbox a name, an image, and a size. Anything you leave out falls back to a workspace default.
Run devbox create with no arguments to be prompted for each value:
Or pass them inline to skip the prompts:

Create a macOS Devbox

Ask for macOS instead of the default Linux.
--platform also accepts macos/arm64, linux, and linux/amd64.
macOS Devboxes run on Apple Silicon from a Namespace-managed base image, so you choose a macOS and Xcode version rather than supplying your own. They support the M and L sizes only, and cannot use custom images or nested virtualization.

Create from a blueprint

Create a Devbox from a saved Blueprint definition.
--blueprint uses the latest version of the named Blueprint, and cannot be combined with --from or --platform.
A Blueprint captures the operating system, base image, machine size, access mode, and optional settings such as repositories, environment variables, and network policy. See Devbox Blueprints to create and configure one.

Create from a spec file

Declare the configuration in a file, then create from it non-interactively:
devbox.yaml
See the spec file reference for every field, the supported formats, and how to read a spec from stdin.

Configuration Options

Set these when you create a Devbox, in any of the forms above.

Image

Choose the image the Devbox starts from.
List the images your workspace can use. Both Linux and macOS images are shown:
Filter with --platform linux or --platform macos. To create from a macOS image, pass the platform and the image name together:
--image follows the latest build of a named image. To pin one exact build, see Pin an exact image.
macOS images are Namespace-managed and named after their release, such as tahoe or sequoia, and each bundles a macOS and Xcode version. Only Linux Devboxes can use images you build yourself. To bake your own tools and runtimes into an image, see Custom Images.

Machine Size

Choose how much CPU and memory the Devbox gets.
The available sizes differ between Linux and macOS.
Linux vCPU counts represent burstable capacity.
Your workspace policy may restrict which sizes are available.

Repository

Clone a repository into the Devbox when it is created. This requires a connected GitHub organization.
Omitting --checkout applies the workspace default repository. Pass --no_checkout to skip the checkout entirely.
To pin a branch, tag, or commit, use the repository block in a spec file.

Access Mode

Choose whether the Devbox is private to you or shared with the workspace. When omitted, the workspace default applies.
--access_mode accepts private or shared.

Idle Timeout

Control how long a Devbox stays running after it goes idle. The dashboard offers presets of 15 minutes, 30 minutes, 1 hour, 4 hours, and 8 hours, plus a custom value. The CLI accepts any duration.
See Idleness and auto-stop for how idleness is detected, and Running long tasks to learn how to keep a Devbox alive for long-running tasks.

Volume Size

Persistent storage defaults to the workspace setting. Override it when a repository or build cache needs more room:

Ephemeral

Create a Devbox whose instance and storage are deleted when it stops.
Ephemeral Devboxes start fresh every time. They suit short-lived tasks or experimentation where you don’t need to keep data across restarts.

Site

Pin the Devbox to a specific site. By default it is created in the site closest to you.
To list the available sites with their measured latencies, run devbox site-latency:
It reports p50 and p90 for each site and highlights the closest one.

Workspace Defaults

Workspace admins can set default values applied to all newly created Devboxes. Navigate to the Defaults page in the dashboard to configure:
  • Image: default base image, which also determines the operating system (Linux or macOS)
  • Instance size: default CPU and memory allocation
  • Volume size: default persistent volume size for new Devboxes
  • Git repository: default repository to clone
  • Access mode: private (just you) or workspace-wide (shared with all members)
  • Auto-stop timeout on idle: how long Devboxes stay running when idle
Network
  • Egress policy: default outbound network access restrictions
Integrations When a workspace policy is active, policy-enforced values take precedence and are shown as locked in the UI.

Pin an exact image

--image follows the latest build of a named image, so a Devbox created today and one created next month can differ. To pin a single build that never changes, pass a full registry reference to --image_ref instead. List the images with their references:
Output
Pass the image_ref value to devbox create:
--image and --image_ref are mutually exclusive. --image_ref applies to Linux images only: macOS Devboxes must use --image with a macOS image name.

GitHub CLI Authentication

Forward your local gh CLI authentication to a Devbox so gh commands and HTTPS git operations are authenticated. Do it at creation time, or against a Devbox that already exists:
The local gh token is read before the Devbox is created, so a missing or expired login fails fast. When both are given, the --setup_github flag overrides the spec value.

Next Steps

Devbox Lifecycle

Listing, starting, stopping, idleness, and deleting.

Sessions

Persistent terminal sessions that survive disconnections.

Blueprints

Reusable Devbox configurations to create from.
Last modified on September 16, 2026