2026 03 19 Executive Workspace Vm Gspace1
Documentation for Plans
Executive workspace VM — gspace1 RAM budget (Vitto building Vitto)
Audience: Infra + product — why executives get a larger Firecracker VM when driving Vitto from WhatsApp (or the web app) to work inside the gspace1 monorepo.
Role split
| Capability | Executive | Developer |
|---|---|---|
monorepo_* tools (remote codebase) |
Yes | Yes |
| Full-stack workspace VM (extra RAM/vCPU, no snapshot restore) | Yes | No (standard VM_MEM_SIZE_MIB, snapshot path unchanged) |
Eligibility: isExecutiveFullStackWorkspaceVmEligible() in role-derivation.ts (platform executive or legacy JWT resolving to executive).
Why 12 GiB (12288 MiB) default
Rough concurrent footprint for “real” gspace1 dev inside the guest VM:
| Consumer | Conservative estimate |
|---|---|
| Linux desktop + agents | ~0.8–1.2 GiB |
Four Nest backends dev (yarn serve:* — api, ai, docs, vitto) |
~2.5–4 GiB (watch mode, sourcemaps) |
| Nx + Angular dev server (gograb-space or similar) | ~2.5–4 GiB |
| Chromium + DevTools (debugging the app) | ~1.5–2.5 GiB |
Headroom / spikes / nx graph |
~1–2 GiB |
Sum: about 9–14 GiB. 12 GiB is the default sweet spot: enough for the described workflow without encouraging 16+ GiB per executive VM on every host.
vCPU default (4)
Nx and multiple Node processes benefit from 4 vCPUs for parallel compilation and dev-server work. Standard sandboxes stay at VM_VCPU_COUNT (often 2).
Configuration
backend-vitto-api (.env.local):
# Executive cold-boot profile (optional overrides)
EXECUTIVE_WORKSPACE_VM_MEM_MIB=12288
EXECUTIVE_WORKSPACE_VM_VCPU=4
sandbox-orchestrator (caps — applies to all requested sizes):
VM_MEM_SIZE_MIB=2048 # default for non-executive / generic creates
VM_MEM_SIZE_MIB_MAX=16384 # hard clamp upper bound
VM_VCPU_COUNT_MAX=8
Product note: “Vitto building Vitto”
The innovation is operational: executives steer Vitto from mobile; Vitto runs a dedicated, large, disposable-class workspace VM for our repo, separate from customer platform-building tools. Developers keep the same monorepo tools but standard VM economics until you promote them or change policy.
Pre-baked tech stack (recommended)
Yes — giving the VM more RAM does not remove the need for a pre-installed toolchain. If every session runs apt install / nvm install / yarn install from a cold disk, boot-to-productive time stays slow and flaky.
Today, deployment/sandbox-orchestrator/Dockerfile.rootfs bakes Ubuntu 22.04, XFCE, Google Chrome, SSH, VNC, xdotool/scrot — optimized for desktop automation, not for building gspace1.
For nice, fast, easy monorepo work inside the guest, extend the rootfs (same Dockerfile or a variant image built from it) with at least:
| Layer | Purpose |
|---|---|
git, openssh-client |
Clone / fetch; submodule-friendly |
Node.js (version pinned to repo policy, e.g. .nvmrc / CI) |
Nx, Angular, Nest |
Yarn (match monorepo — Corepack or classic as in packageManager) |
Lockfile + workspaces |
build-essential, python3 |
Native Node addons where needed |
Optional: jq, unzip, zip |
Scripts and tooling |
Do not rely on first-run inside the VM for Chrome — already in the image. Do align Node/Yarn with gspace1 so yarn install is the main variable cost (still large, but cached layers / optional pre-warmed node_modules snapshot are separate optimizations).
Flow: edit Dockerfile.rootfs (or add Dockerfile.rootfs-gspace1-dev), rebuild with deployment/sandbox-orchestrator/build-rootfs.sh, deploy the new ext4 as BASE_ROOTFS_PATH (or a dedicated path for the executive template). Executive VMs can point at the same richer image while non-executive sandboxes keep the slimmer image if you split builds.