A workspace, not the machine

Q: What languages are installed?

Node and Python, plus the build essentials. Go, Rust, Java,.NET, Deno and other Node.js versions are available on demand: an admin picks them per workspace and the host installs them with the vendor's checksum checked. Your organisation can narrow the list.

One container per person or agent, with everything they need to work and nothing they don't need to reach.

A browser terminal, VS Code in the browser, app preview, a headless browser, a persistent home directory, its own Postgres and the major agent CLIs, on your host. Each organisation's workspaces sit on their own Docker network. If your organisation allows Docker in a workspace, the containers it starts run beside it on that workspace's own network. Workspaces run on your host (or, if your organisation turns it on, a member's own computer: egress there is observed, not enforced).

Run it on your hardware Meet the agents

acme / dev012 CPU · 2 GBsynthetic

$ npm test -- signup

8 passed

$ gitleaks detect --no-banner

no leaks found

$ git push origin feature/dev01/signup

through the git broker · no token in this workspace

src/signup.tsvalidate.tstest/

export function validateSignup(body) {
  if (!body.email) throw new Error('email required');
  return body;
}

Lifecycledrag to scrub

CREATE · workspace-agent

non-root user · 2 GB, 2 CPUs, 512 pids · on the acme network

Know where the agent runs

An agent can only be governed if you know where it runs. A workspace is the one place you set the rules, see the traffic, and keep the record.

Laptops differ, hold personal credentials and have unrestricted networks. Cloud dev environments put the source code on someone else's infrastructure. A Kodela workspace sits on your host, your disk and your network, unless your organisation turns on members' own computers, where egress is observed, not enforced.

Developers get a ready environment on the first visit.
Engineering leads get every agent run in a known place.
Team leads onboard a contractor in the time it takes to accept an invitation.

How a workspace is put together

One component creates workspaces. One front door lets you in. The credentials stay on the host.

Workspace anatomyacme · synthetic names

Browser
yours

Front door
authenticates every request

the acme network

ws-acme-dev01

terminalVS Codepreview 1024–65535headless browser/home/dev

Broker sockets are mounted in. The git token and the model keys stay on the host.

Firewall
then the egress proxy

workspace-agent creates the workspace. It creates the container as a non-root user, with memory, CPU and process limits, on the organisation's network. When a workspace has managed Docker, a per-workspace broker (bin/docker-broker) also talks to the host's Docker, deny-by-default, for that workspace's own containers.
It refuses to create one unless the firewall has verified that network and its DNS gateway exists.
The front door authenticates every request to /ws/<organisation>/<workspace>/ and routes it to the terminal (ttyd with tmux), the IDE (code-server) or a preview port from 1024 to 65535.
Idle workspaces are suspended after 30 minutes and wake on the next visit. The home volume survives recreation.

What a fresh install gets

Every capability with its default and its limit, on the same line.

Capability	Default	Limit
Browser terminal, several shells as tabs	on	n/a
VS Code in the browser, curated pinned extensions, seeded settings	per workspace	about 1 GB RAM per IDE user
App preview; dev-server mode keeps hot reload	port 3000	share links expire within 24 h
Headless browser inside the workspace network	on demand	obeys egress, so it sees what the workspace sees
Persistent home, idle suspend, resource caps	30 min idle; 2 GB / 2 CPU	containers share the host kernel
Postgres per workspace, with a read-only Database tab	on for each new workspace	none, or connect your own server, are still choices; skipped on a member's own computer; the tab never runs a query you type
Docker and `docker compose` in a workspace, with a Docker tab (`workspace_docker_allowed`)	off; managed or full	managed runs through a deny-by-default broker; full needs a platform administrator; refused on members' computers
Language versions on demand: Node.js, Go, Rust, Java, .NET, Deno (`workspace_languages_allowed`)	all	installed by the host with the vendor's checksum; package registries still need the egress allowlist
Workspaces on a member's own computer	off	needs an operator grant and the organisation's switch; egress observed, not enforced; no Docker
File transfer control (download / upload / both)	off	cannot stop code shown in an attached editor or terminal from leaving
Desktop IDE attach (VS Code Remote-SSH, JetBrains Gateway, ssh)	off	bypasses file transfer by design; the admin is warned at switch-on
devcontainer startup tasks and dotfiles	off	`image` and `features` are refused
Offline scanners and linters in the image	on	the vulnerability DB is as fresh as the image
`workspace-info`: what this workspace may do	on	says "not measured" rather than guessing

File transferper org · synthetic

settingoff

Download from the IDE or Files panerefused · audited
Upload into the workspacerefused · audited
scp, sftp, rsync over attachrefused · audited

The default. Nothing moves as a file, and the attempt is audited.

Files move only when you say

File transfer is off by default. The setting is off, download, upload or both, and it only tightens from the organisation to the user to the workspace.

It covers the Files pane, the browser IDE's Download and Upload, scp, sftp, rsync, ssh and ftp from the workspace terminal, and scp, sftp and rsync over desktop IDE attach. Below both, GitHub is reached only through the git broker, and GitHub release downloads and PyPI upload are refused.
Copy tools are refused by port, and on any port when the connection goes through the egress proxy, which recognises ssh, rsync and ftp by their opening bytes.
Attempts are audited, whatever the setting. A refusal over desktop IDE attach is logged inside the workspace only, not on the platform's audit trail.
Limit: it cannot stop code shown in an attached editor or terminal from leaving. both also opens direct GitHub access. The browser IDE applies a change at its next start. Preview links are detectable, not preventable.

What is in the image

The same CLIs your developers use locally, and scanners that run with no network.

base Ubuntu 24.04 · Node 22 · Python 3 · build-essential · psql client · openssh-server

agent CLIs Claude Code · Codex · Antigravity

VS Code extensions Python · ESLint · Prettier · GitLens · Claude Code

offline checks gitleaks · osv-scanner · semgrep (local rules) · ruff · basedpyright · tsc · shellcheck

On demand, not preinstalled GoJavaRust.NETDenoNode.js versions

An admin picks versions when creating or editing a workspace. The host downloads each one, checks the vendor's published checksum and copies it in, so the workspace reaches no new host. Package registries still need the egress allowlist. The gh CLI is not in the image.

Two workspaces at work

A new contractor

An admin invites them.
The contractor accepts and opens their workspace.
They clone through the broker with no token, work in the browser IDE, and push to a feature branch.
File transfer is off, so nothing is downloaded to their laptop.

An agent fixing a failing test

The agent runs the checks the organisation has declared.
It edits the file, re-runs, and proposes the push.
The approval card shows the diff and the push target.

How approvals work

Contained, and honest about it

Docker containers, not virtual machines. No custom seccomp profile, no read-only root. If your threat model needs a VM boundary, Kodela is not that today.

Read the security model

A non-root user with no-new-privileges.
One network per organisation, so a workspace cannot reach another organisation's workspaces.
No git or model credential inside under the default profile. The exception is full Docker under privileged, set only by an operator: there the firewall and no-credentials guarantees no longer hold for that workspace.
Offboarding archives a departed person's workspaces, including those on their own computer. Operators set per-organisation quotas; the auditor role can see workspaces without changing them.

Questions

Is a workspace a VM?

No. It is a Docker container with limits, a non-root user and its own organisation network.

Can I use my desktop IDE?

Yes, if your organisation turns on desktop IDE attach. It is off by default.

Does my work survive a restart?

Your home directory does. The container itself is replaceable.

What languages are installed?

Node and Python, plus the build essentials. Go, Rust, Java, .NET, Deno and other Node.js versions are available on demand: an admin picks them per workspace and the host installs them with the vendor's checksum checked. Your organisation can narrow the list.

Can I run Docker in a workspace?

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; containers get no internet by default (docker_egress). Pulled images are one shared cache on the host, so a workspace can tell an image was already pulled. Full Docker needs a platform administrator and a supported runtime (Sysbox); under privileged the firewall and no-credentials guarantees no longer hold for that workspace. Not available on members' computers.

Does a workspace come with a database?

Each new workspace gets its own Postgres by default (none, or connect your own server, are still choices), with a read-only Database tab. Its password stays on the host. When a compose project declares its own Postgres, starting it from the Run box points the app at the workspace database; a docker compose up typed in the terminal is not redirected.

Can a workspace run on my own laptop?

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).

How many workspaces can one host run?

It depends on memory: plan about 2 GB per active workspace. We have not published a tested maximum.

What it does not do yet

Read this before you install.

VM-level isolation.
Go, Java or Rust preinstalled in the image. They are available on demand instead, installed by the host.
Docker on a member's own computer.
Hiding which images were pulled. Pulled images are one shared cache on the host.
devcontainer image and features.
A database service beyond each workspace’s own Postgres (on by default; choose none, or connect your own server).
Stopping code shown in an attached editor or terminal from leaving with the person looking at it.
Enforced egress on a member's own computer. 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).

Your host, your disk, your network

Self-hosted only. Give each developer and each agent a workspace on hardware you already own. Members' own computers stay off unless your organisation turns them on.

Run it on your hardware Meet the agents Talk to us about a pilot