How the pool works
The platform continuously maintains a set of warm VMs:- Backfill — when idle VMs drop below the workspace’s
min_idlethreshold, new ones are booted - Assignment — when you spawn an agent, a warm VM is claimed instantly
- Hard cap — total VMs never exceed
max_vms(set in pool-config)
Pool configuration
Each tenant has apool-config resource (singleton, always named default) that sets the tenant-wide max_vms cap. Each workspace has a min_idle field that controls how many warm VMs to keep ready for that workspace.
Monitor pool health with murmur pool status. After changing environment config or images, use murmur pool flush to drain warm VMs so fresh ones are created from the new configuration.
Cost management
Warm VMs consume compute even when idle. Tune these parameters to balance speed vs cost:| Parameter | Trade-off |
|---|---|
Higher min_idle | Faster agent startup, higher idle cost |
Lower min_idle | Slower startup (may need cold boot), lower idle cost |
Lower max_vms | Hard cost cap, but may queue agent starts during peaks |
min_idle of 1–3 is a good starting point for most teams.
| Type | Page |
|---|---|
| Reference | pool-config |
| Reference | murmur pool status |
| Reference | murmur pool up |
| Reference | murmur pool flush |
| Concept | Workspaces |
| Concept | Environments |