Workspaces for people and agents, on your hardware
Kodela is one product. Everything on this page ships in it: four parts, each a feature you configure, not a separate product to buy. Each one does a specific job and says where it stops.
Workspaces run on your Kodela host. If a platform operator grants it and your organisation turns it on, a member's own computer can host their workspaces too; there, internet access is observed, not enforced.
-
A container for every developer and every agent working for them, on your organisation's own network.
Limit: a Docker container, not a VM. Containers share the host kernel. Docker inside a workspace is off until your organisation allows it.
-
Git through a broker, model calls through a proxy, everything else through one egress proxy and a firewall that fails closed.
Limit: egress starts in observe. It logs and allows until you switch it to deny. On a member's own computer it is observed, not enforced.
-
A hash-chained audit trail, exportable in the formats your SIEM reads, and a label on every push saying who wrote it.
Limit: signed on your host, not publicly verifiable. Nothing ships off the box for you.
-
Agent profiles, approval cards, a validation gate on push, and settings that only get stricter.
Limit: the gate and several features ship off. You turn them on.
You sign in to your own console: a password, or your organisation's SSO.
One path, every time
The same four steps for a person and for an agent.
- You sign in to your own console
Your host, your accounts: a password, or your organisation's SSO.
- You open a workspace
It is a container on your organisation's own network, with your editor, your terminal and the agents already signed in through the host.
- The agent works inside it
It reads, edits and runs. Anything your organisation marked as "ask first" stops at an approval card.
- Anything leaving goes through the host
git through the broker, model calls through the model proxy, everything else through the egress proxy, and each one is written to the audit trail. On a member's own computer (if your organisation turns it on), git and model calls still go through the host, but other internet access is observed, not enforced.
How the parts connect
The whole of Kodela on one host. Play a flow, or select a part to see its default and its limit. Workspaces on members' own computers, when your organisation turns them on, are not drawn here.
One host, three boundaries. You reach the console server and the front door; each organisation's workspaces sit on their own network; git, model calls and all other traffic leave only through the host's git broker, model brokers and egress proxy, and every decision is written to a hash-chained audit log.
Egress starts in observe. The validation gate and the key broker ship off. The console's store is one SQLite file on one host. A member's own computer can host their workspaces if an operator grants it and the organisation turns it on; there, egress is observed, not enforced.
Without Kodela, with Kodela
Most teams start with an agent on a laptop, using the developer's own tokens, on a network that lets anything out.
It works until someone asks what the agent sent out, which commits it wrote, and who approved it.
| Without | With |
|---|---|
| Agents on laptops, with personal tokens | Agents in workspaces; tokens on the host |
| Outbound traffic unrecorded | One exit per organisation, every decision logged |
| AI-written commits indistinguishable | Every push labelled agent, console or unattributed |
| One global on/off for agents | Per-member profiles, approvals and a push gate |
What is in the box
Every feature, grouped by what it does. A grey lamp means the feature is built and ships off until an admin turns it on.
Workspaces
- Browser terminal
- Browser VS Code
- App preview, hot reload
- Headless browser
- Persistent home
- Idle suspend
- Postgres per workspace, Database tab
- Language versions on demand
- Docker in a workspaceoff
- Members' own computersoff
- Desktop IDE attachoff
- File transferoff
Agents
- Chat with five modes
- Claude Code, Codex, Antigravity CLIs
- Approval cards
- 68 platform skills
- Skills per organisation
- Images, PDFs and files in chat
- Memoryoff
- MCPoff
- Subagentsoff
Controls
- Git broker
- Model proxy
- Egress proxy and firewall
- DNS filter per organisation
- Strictest-wins settings
- Validation gateoff
Evidence
- Authorship record
- Hash-chained audit
- Audit dashboard per organisation
- Sign-in audit
- AI usage dashboard
- CEF, LEEF, syslog, JSON, CSV export
- Compliance evidence report
- Offline scanners in every workspace
Administration
- Organisations, four roles
- Invitations
- OIDC SSO, not yet tested with a live IdP
- Operator console
- Encrypted backup
What it runs on
One Linux host you already own. No cloud provider, managed database or Kubernetes.
Workspaces run on that host. If a platform operator grants it and your organisation turns it on, a member's own computer can host their workspaces too.
Self-hosted deployment- OS
- Ubuntu 24.04
- Runtime
- Docker, systemd
- Control plane
- Python 3.12, standard library only
- Memory
- 8 GB or more
- Disk
- 20–30 GB or more
- Per workspace
- capped at 2 GB, 2 CPUs, 512 pids
- Browser IDE
- about 1 GB more per user
- Availability
- one host, no high availability
- Members' computers
- off; tested end to end only on Windows
What it does not do yet
Each part has a limit. These are the ones to read before you install.
- No VM boundary. Workspaces are Docker containers that share the host kernel.
- Members' own computers are not your host. Workspaces run on your Kodela host. If a platform operator grants it and your organisation turns it on, a member's own computer can host their workspaces too. 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).
- Docker in a workspace is off until your organisation allows it (
workspace_docker_allowed: off, managed or full). Managed Docker runs every call through a per-workspace broker that refuses privileged containers, host namespaces, outside binds and unlisted registries. Under full Docker withprivileged, the firewall and no-credentials guarantees no longer hold for that workspace. - The workspace database is skipped on a member's own computer. Each new workspace on your host gets its own Postgres by default (none, or connect your own server, are still choices), with a read-only Database tab.
- Language versions are installed on demand, not preinstalled. Package registries for them still need the egress allowlist.
- Images and PDFs in chat are not checked for secrets. Files are capped at 5 MB.
- No AI spend cap. An AI usage tab for organisation admins and auditors: requests, tokens and cost by member, workspace, surface, model and account. There is no spend cap; cost shows only where the cost meter is on; AI tools that hold their own login inside a workspace are not measured.
- The audit dashboard has a window. Up to 90 days, never past your retention; it shows only records provably the organisation's own. Password and shared-credential sign-ins are recorded from orxy V1.7.2.2 on (single sign-on sign-ins are recorded as 'signed in with SSO'); earlier sign-ins are not in the trail.
- Egress starts in observe. It logs and allows until your organisation switches to deny.
- The record trusts your host's root user. Nothing ships the audit trail off the host for you.
- The validation gate ships off, and has not yet been recorded on a live GitHub push.
- One host, no high availability, no scheduled backup.
- No hosted version. Kodela is self-hosted only.
Run it on your hardware
Start with one host. Read the gaps first, then decide.