Problem
Currently, Devboxes operates in a single shared deployment context without explicit multi-tenancy isolation. In team or organizational environments, different users or groups need isolated environments, storage, RBAC policies, and resource quotas to prevent tenant conflicts and unauthorized access to other users' devboxes and PVCs.
Proposed outcome
- Support tenant isolation via Kubernetes Namespaces or logical tenant ID tagging.
- Provide RBAC control and user-level resource limits (e.g., CPU, Memory, GPU allocation per tenant).
- Ensure storage (
/home/dev volumes) and SSH keys are strictly isolated between tenants/users.
- Allow FastAPI Controller and CLI to filter and manage resources based on authenticated tenant context.
Alternatives and tradeoffs
- Alternative: Deploying separate Devboxes control planes/helm releases per team.
- Tradeoff: Higher operational overhead and resource duplication compared to native multi-tenancy within a single deployment.
Project boundaries
Problem
Currently, Devboxes operates in a single shared deployment context without explicit multi-tenancy isolation. In team or organizational environments, different users or groups need isolated environments, storage, RBAC policies, and resource quotas to prevent tenant conflicts and unauthorized access to other users' devboxes and PVCs.
Proposed outcome
/home/devvolumes) and SSH keys are strictly isolated between tenants/users.Alternatives and tradeoffs
Project boundaries