Workspace Services Slice — cgroup Partitioning for Multi-Developer Environments
The development workspace runs as a multi-tenant environment. Production services (local-slm, local-doorman, local-content, local-fs, local-proofreader) share the same Linux box as interactive AI-coding sessions (Claude Code, Gemini CLI) and human shells. Without resource isolation, a heavy cargo build in one operator's session can starve the OLMo SLM that another operator is relying on for inference.
An initial hardening pass introduced foundry-services.slice — a systemd cgroup partition with CPUWeight=200 and MemoryHigh=11G that holds every local-*.service. Default systemd user slices (user-1001.slice, user-1002.slice) sit at CPUWeight=100, so under CPU contention the service group receives 2× the scheduler weight relative to a single interactive shell. Memory ceilings prevent any one service from pinning more than approximately 11 GiB on a 16 GiB VM; with OOMScoreAdjust ordering (sshd −1000, local-fs −500, local-doorman −300, local-slm +500), the kernel's last-resort kill prefers cheap-to-restart services over the WORM ledger writer or the operator's SSH connection.
This is not orchestration in the Kubernetes sense — there is no scheduler, no replica controller, no service mesh. systemd is enough. The pattern scales to roughly a dozen services on a single GCE VM, the compact single-node configuration that characterises a minimal sovereign deployment. Beyond that scale, the architecture changes — but the cgroup discipline carries forward.
Where this lives on disk: /etc/systemd/system/foundry-services.slice, plus Slice=foundry-services.slice drop-ins under /etc/systemd/system/local-*.service.d/slice.conf. The version-controlled source mirrors live under infrastructure/.
See also
- multi-engine-session-coordination — how concurrent AI-coding sessions coordinate access to the same workspace to prevent index corruption
- cargo-target-per-user-discipline — per-user build cache separation for the same multi-developer scenario
- totebox-session — the session model that individual developer workstreams follow within this environment
- totebox-orchestration-development — the orchestration pattern at the development-environment layer