One host, many organisations, each running itself
An operator runs the host. Each organisation invites its members, assigns their roles, grants repositories and AI providers per person, and sets its own rules within the operator's floor.
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.
acme · roles and per-member grants
| Member | Role | acme/payments | acme/web | Anthropic | OpenAI |
|---|---|---|---|---|---|
owner@example.test | owner | granted | granted | granted | none |
dev@example.test | member | granted | none | granted | none |
audit@example.test | auditor | read-only: grants do not apply | |||
Toggle a cell to grant a repository or an AI provider. New members start with none. An auditor is strictly read-only.
Invitationacme
- to
- dev02@example.test
- role
- member
- grants
- none until an admin adds them
- expires
- in 7 days
- not configured: the link is shown to the admin to hand over
Pick an organisation, change a member's role, toggle grants, add an organisation, send an invitation. Organisations never see each other. Names are synthetic.
Two consoles, one shell
The shell is scoped by who is signed in. One team's tooling serves several teams, or several clients, without them seeing each other.
Operator console
Runs the host.
- Health
- Workspaces
- Organisations
- Credentials
- Cluster
- Settings
- Governance
- Egress
- Audit
- Changelog
The Changelog page, at /changelogs, is for platform operators only: every release with what it built and fixed, searchable.
Organisation console
Runs one organisation.
- Members
- Workspaces & repository access
- AI keys
- Checks
- MCP servers
- Plans
- Tasks
- Settings
- Audit (owners, admins and auditors)
- AI usage
- Why it's stuck
Its settings cards include Where workspaces run with its Computers list, Workspace Docker, Workspace languages, Workspace requests, Member requests and App feedback. A plain member is not offered the Audit tab.
Limit: single host. Multi-host placement is built and off; high availability is not built. Members' own computers can host their workspaces only if an operator grants it and the organisation turns it on, and egress there is observed, not enforced.
Sign in with what you already run
Organisations can sign in through their own Entra ID, Google Workspace or OIDC provider. Everyone else uses a password. Sessions are signed and revocable, and invitations last seven days.
- Accounts are never linked by plain email match.
- The auditor role is strictly read-only.
- A shared front-door password is unattributable until "require identity" is turned on. Turn it on once everyone has an account.
- Password
- PBKDF2-SHA256; lockout per source, held in memory
- Sessions
- signed, HttpOnly, 24 h, revocable
- OIDC SSO
- Entra ID, Google Workspace, generic. Never tested against a real IdP on record
- MFA
- through the IdP on SSO logins; no native MFA
- SAML, SCIM
- not currently available
- refuses every send until SMTP is configured
What ships, what it defaults to, where it stops
| Capability | Default | Limit |
|---|---|---|
| Organisations, four roles (owner, admin, member, auditor) | on | No organisation deletion |
| Invitations | 7 days | Without SMTP, the admin hands over the link |
| OIDC SSO per organisation (Entra ID, Google Workspace, generic) | available | Never tested against a real IdP on record; no SAML or SCIM |
| MFA | via the IdP on SSO logins | No native MFA |
| Per-member repository and AI grants | none | n/a |
| Operator quotas and profile floors | unlimited / none | n/a |
| Offboarding (archive home, remove user, archive workspaces, including those on the member's own computer) | CLI | Disabling alone does not end sessions |
Members' own computers as workspace hosts (personal_hosts_allowed, personal_hosts_enabled) | off | Needs an operator grant and the organisation's switch. Egress observed, not enforced; DNS filtering not enforced; source readable on that disk; no Docker. Tested end to end only on Windows |
| Member requests (a repository from the catalog, or the organisation's AI model) | available | A request grants nothing; the admin makes the change with the existing controls |
Agents manage their owners' workspaces: list, start and stop the owners' other workspaces in the organisation, ask for a new one (Workspace requests), record what an app's users reported (App feedback) (workspace_portal_api_enabled) | off | Only while the owners are active members; a request creates no workspace; it cannot change settings, members or credentials or reach another organisation; rate-limited and audited |
| Docker and language versions per organisation (Workspace Docker, Workspace languages) | Docker off; all languages | Full Docker needs a platform administrator |
| AI usage tab | on for admins and auditors | No spend cap; cost only where the cost meter is on; AI tools holding their own login in a workspace are not measured |
| Members' own AI keys | private to each member | Admins see which members hold one, never the key; keys from the old shared store must be re-entered |
| Encrypted backup and partial restore | refuses until a key is set | Not scheduled |
| Health: readyz, whats-running, egress coverage, DNS filter status | on | n/a |
| Operator Changelog page | on | Operators only |
Onboarding an organisation
- The operator creates the organisation and invites its owner.
- The owner configures SSO and invites members.
- Members sign in with SSO.
Offboarding a leaver
dev-offboardarchives the leaver's home.- It removes the account.
- The leaver's workspaces are archived, including those on their own computer.
Limit: disabling an account does not end live sessions. Offboarding does.
Questions
Can we use Okta?
Through generic OIDC. It has not been tested against Okta on record.
Can we delete an organisation?
Not yet.
Do you support SSO?
Yes: OIDC per organisation with Microsoft Entra ID, Google Workspace or a generic provider. It has not yet been tested against a customer's live IdP.
SAML? SCIM?
Not today.
Can members run workspaces on their own computers?
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). The member adds the computer on Your computers and pastes one command; its agent updates itself. A computer that has not connected within its lease (30 days by default) is disabled, removing it stops its key at once, and offboarding archives its workspaces.
What it does not do yet
- SAML.
- SCIM.
- Native MFA or passkeys.
- Organisation deletion.
- Scheduled backups.
- High availability.
- Enforced egress on members' own computers. There, internet access is observed and DNS filtering is not enforced.
- Email that works before you configure SMTP.
Run several teams from one host
Read how organisations, roles and SSO are set up, or tell us what you need.