Skip to main content

CPU, memory, and root disk

VMs are CPU-only. Resource availability depends on the microVM serverless pool. You normally do not need --pool; use it to select a CPU microVM pool you have access to. Choose CPU, memory, root disk size, and image when creating the VM. beam vm update changes idle behavior and metadata, not the machine’s allocation or root disk capacity. See storage for what df -h / reports.

Names and IDs

Names are unique within a workspace. A name must begin with a lowercase letter and contain at most 24 lowercase letters, digits, or hyphens. Omit the name for a generated name such as calm-fox-5959d8. The VM also has an immutable ID such as vm-0123456789abcdef. Use its name or ID with beam vm get, start, stop, and other commands. A VM’s current container ID may change when it restarts; use the VM identity when reconnecting.

Base images

VM images require Debian or Ubuntu. Beam adds systemd, SSH, the browser terminal, and its VM boot services to registry images or the final stage of your Dockerfile. The default base image is ubuntu:22.04.
The browser desktop currently requires Ubuntu 22.04 (jammy). Use the default image for desktop VMs. Alpine and other distributions without the supported apt/systemd setup are not supported VM bases.

Build a custom image

For example, create a Dockerfile that installs your tools:
Dockerfile
Create a VM directly from the Dockerfile:
Or build a reusable VM image first:
Use beam vm image build --desktop when the image will provide a desktop. An --image-id must already include the VM services; Beam cannot append packages to an existing immutable image ID. Do not pass an arbitrary sandbox image ID and expect VM services to be added. The Python SDK accepts an Image:
Use systemd units to start services on VM boots. A VM boots systemd rather than using a Dockerfile’s CMD as its application service.

Environment variables and secrets

Pass ordinary configuration with repeatable --env flags. Pass existing workspace secrets by name:
Use --build-secret NAME for secrets needed during image building. Build secrets and runtime secrets are separate settings. Names beginning with BEAM_VM_ or BETA9_ are reserved.

Additional storage

Every VM already has a durable root. Attach a separate named disk or shared workspace volume when your data needs an independent lifetime:
Additional VM disks use the qcow driver and ext4. Disk names cannot begin with vm-, which is reserved for VM roots. Mount paths must be unique absolute paths, must not overlap, and cannot replace /, /dev, /proc, /sys, /run, or /.beam. These mounts are separate from the root snapshot. Read snapshot and fork boundaries before using them in a reusable environment.

Metadata and creation retries

Use metadata to label environments and filter the VM list:
An update replaces the complete metadata map. Metadata is visible in management responses; keep credentials in secrets. For creation retries, pass the same UUID as --request-id, or request_id in Python, with the same creation options. Reusing that request ID with a changed request is rejected. Reusing the same prepared Python VM object retains its request ID and prepared image, so a lost response can be retried without creating another VM. When creating from a template or snapshot, omitted configuration inherits the saved specification. Explicit settings override it. Choose one image source: registry image, image ID, Dockerfile, or template.