mold lambda: Lambda Cloud web UI

mold lambda deploys mold to Lambda Cloud as a private, Docker-first web UI. The local CLI creates or reuses Lambda resources, starts the mold container on the instance, opens an SSH tunnel to 127.0.0.1:7680, and prints the matching MOLD_HOST export.

Setup

Create a Lambda Cloud API key in the Lambda console, then configure mold:

mold config set lambda.api_key <your-key>
# or, for shell-only use:
export LAMBDA_API_KEY=<your-key>

mold lambda doctor

Lambda access stays private by default. The remote container binds mold to 127.0.0.1:7680 on the instance, and your laptop reaches it through SSH:

mold lambda deploy --instance-type gpu_1x_a10 --region us-west-1
eval "$(mold lambda tunnel)"
open http://127.0.0.1:7680

The container uses host networking with MOLD_BIND=127.0.0.1, so SSH forwarding arrives at the engine as an actual loopback connection. Traffic between machines is encrypted by SSH with its existing host-key verification; no public plaintext API or cloud HTTP proxy is enabled. RunPod containers retain their default bind address and accept encrypted protocol 3 WebSockets through their provider proxy.

For an existing instance, explicitly running mold lambda deploy upgrades the previous Mold-generated Docker service to this loopback layout and restarts it with the current image reference. The CLI verifies the exact managed unit, preserves its volume mount, and checks both the original and replacement bytes before installation over SSH. Custom service units require an operator upgrade; the CLI does not overwrite them. Schedule this first upgrade while the engine is idle. Later reuse leaves the updated service running.

Discovery

mold lambda availability
mold lambda availability --json

Availability shows the Lambda instance type, region, GPU description, GPU count, generation_slots, price per hour, memory/storage, and the selected Docker image tag. Slots equal GPU count: mold keeps one GPU-resident engine per worker/GPU and does not claim extra parallel slots on a single large GPU.

Availability displays the human-readable target tag below. Stable automatic deployments fetch the digest manifest generated by that exact release workflow manifest and submit ghcr.io/utensils/mold@sha256:…; they fail closed if that manifest is unavailable or does not match the CLI source. Rolling/source/Nix binaries use mutable latest* tags.

GPU family	Automatic image tag
Ampere / A30 / A100	:<version>-sm80
Ampere / A2/A10/A16/A40, RTX A4000–A6000, RTX 3050–3090	:<version>-sm86
Ada / L40 / RTX 4090	:<version>
Hopper / H100 / H200	:<version>-sm90
Datacenter Blackwell / B200 / B300	:<version>-sm100
Consumer Blackwell / named RTX PRO or GeForce RTX 50-series	:<version>-sm120

The shared name table includes RTX 3050, all named GeForce RTX 50-series, and named RTX PRO 1000/2000/4000/4500/5000/6000 Blackwell variants. Unknown names stay on the conservative default rather than being guessed.

Generic Ampere selects sm_80. A bare Blackwell name is ambiguous between incompatible sm_100 and sm_120 targets, so it conservatively uses the default sm_89-compatible tag rather than guessing.

B200 support is simulated, not hardware-qualified. Mold does not launch Lambda qualification resources automatically; the real 8×B200 campaign is a separate deferred milestone.

GH200, GB200, and GB300 require future linux/arm64 artifacts and are unsupported. The published Mold CUDA images are Linux amd64 only, and both availability output and deploy fail closed before selecting an image for a Grace instance.

Persistent Storage

mold lambda deploy creates or reuses one Lambda filesystem per region. The default name is mold-<region>, mounted at /data/mold and bound into the container as /workspace, so models, LoRAs, cache, the metadata DB, and gallery outputs survive instance replacement.

mold lambda filesystems
mold lambda filesystems --json

Filesystems continue billing while they exist. Use mold lambda reset --to-zero when you want all mold-managed Lambda storage removed.

Secrets

Secrets are not forwarded by default. To copy local HF_TOKEN and CIVITAI_TOKEN into the remote service env, opt in explicitly:

mold lambda deploy --instance-type gpu_1x_a10 --region us-west-1 --forward-secrets

The CLI writes a root-readable env file over SSH and restarts the remote mold-lambda.service.

Lifecycle

mold lambda status
mold lambda logs --follow
mold lambda ssh
mold lambda terminate

terminate stops the instance and local tunnel but leaves the regional filesystem. To remove mold-managed instances, tunnels, and filesystems:

mold lambda reset --to-zero

The reset command requires typing delete mold lambda resources unless you pass that exact phrase through --confirm.

Configuration

[lambda]
# api_key = "..."                         # Prefer LAMBDA_API_KEY for shells
endpoint = "https://cloud.lambda.ai/api/v1"
image_repository = "ghcr.io/utensils/mold"
ssh_key_name = "mold-laptop"
ssh_private_key_path = "~/.ssh/id_ed25519"
filesystem_prefix = "mold"
filesystem_mount_path = "/data/mold"
confirm_hourly_usd = 5.0
local_port = 7680

All keys are settable with mold config set lambda.<key> <value>.