One host. Many teams. Each with its own rules.
Give every team or client its own organisation: its own network, settings, members and audit. You set the floor; an organisation can tighten it, never loosen it. Workspaces run on your host, and on members’ own computers only where you grant it and the organisation turns it on.
-
acmenetwork acme · 4 members
guarded
-
paymentsnetwork payments · 3 members
strict
2 organisations · 2 networks · floor guarded · strictest wins
What the platform team gets
For the operator who serves many product teams or clients from one place.
- Organisations
- Each with its own network, settings, members and audit, on the same host. Workspace create refuses unless the firewall verifies that organisation's network and a DNS gateway exists.
- Operator floors
- You set the platform level. Organisations inherit it and can only move stricter.
- Quotas
- Workspace quotas per organisation, set by the operator.
- Strictest wins
- Settings resolve from platform to organisation to member to workspace, and the strictest applies.
- Operator console
- Platform health, workspaces, users, organisations, egress policy and monitor, and the audit log. A posture audit lists any organisation looser than the floor, and a coverage check names any organisation network without rules.
Who sets what
The operator sets the floor. Organisation admins tighten within it.
| Setting | Operator (platform) | Organisation admin | Default |
|---|---|---|---|
| Security level | Sets the floor | Tighten only | guarded |
| Egress mode | Observe or deny for the host | Can move to deny; cannot loosen | observe |
| Allowlist | The host's list | Adds to the host's list; cannot remove from it | GitHub, npm, PyPI, Anthropic API, Open VSX |
| File transfer | Platform setting | Tighten per organisation, member or workspace | off |
| Agent profile | Platform default and floor | Per organisation, narrowed per member | assisted |
| Agent turn caps | Sets the ceiling | Lower only | the platform ceiling |
| Members’ computers as hosts | Grants it per organisation | Turns it on once granted; turning it off stops new workspaces there at once | off |
| Workspace Docker | Only a platform administrator may allow full | Off or managed | off |
| Desktop IDE attach | Off | An admin can turn it on; the switch names the risk | off |
Sizing the one host
Plan about 2 GB of memory per active workspace. We have not published a tested maximum number of workspaces per host, so size from your own pilot. Workspaces on members’ own computers, where you allow them, run on those computers instead.
If the host is down, workspaces are down. If the egress proxy is down, the firewall blocks outbound traffic rather than allowing it. Encrypted backups restore per organisation or per workspace; nothing schedules them yet.
Host requirements- Memory
- 2 GB per workspace
- CPU
- 2 per workspace
- Processes
- 512 per workspace
- Idle suspend
- After 30 minutes
- Browser IDE
- About 1 GB more per user
- Host
- Ubuntu 24.04 · 8 GB+ RAM · 20–30 GB+ disk
Questions we get
Are organisations isolated from each other?
Each organisation has its own Docker network, DNS gateway, settings, members and audit view. Workspaces are containers, not VMs: a non-root user, no-new-privileges and limits, without cap-drop, seccomp or user-namespace remap yet.
Can an organisation loosen what I set?
No. It can tighten, never loosen. The one additive exception is the egress allowlist, where an organisation's entries are added to the host's.
Can we run several hosts?
Not in production today. Additional workers are built and off by default, and seen only in development. There is no high availability.
Does it need Kubernetes?
No, and it is not supported. One Ubuntu host with Docker, Python 3.12 and systemd.
Can I remove an organisation when a client leaves?
Not yet. You can offboard every member, which archives their workspaces, but organisation deletion is not currently available.
What it does not do yet
Plan around these before you put several teams on one host.
- One host. The control plane is one file on one machine.
- Members’ computers are observed, not fenced. If you grant it and an organisation turns it on, a member’s own computer can host their workspaces. There, internet access is observed, not enforced; DNS filtering is not enforced; the source on its disk is readable by whoever uses it; and Docker is not available. Tested end to end only on Windows (Linux laptops up to enrolment; Mac only in a simulation).
- Additional workers are built and off by default. Multi-host placement has been seen only in development.
- No high availability. No failover and no replica.
- No organisation deletion yet. Offboarding removes people, not the organisation.
- No published capacity figure. Size from your own pilot.
- No Prometheus metrics or alerting. Health endpoints and an ops log exist; the log is off by default.
Start with two teams
Bring up one host, create an organisation per team, and set your floor.