Self-host the open source control plane, rent the agent sandboxes

What a self-hosted install puts on your box

A self-hosted Kortix is one Docker Compose project on a machine you own, built from the same images the managed cloud runs. Accounts, projects, repos, secrets, connectors, policies and the audit record live inside that instance, on storage you back up yourself. The frontend, the API and the LLM gateway are the published images. A self-hosted instance consumes them instead of building its own.

The word "everything" is where readers go wrong. What you own is the control plane, the layer where work is configured and governed. The computers the agents work on are a second layer, and it stays somewhere else. One isolated sandbox per session. Each session has its own isolated machine and branch.

Sandbox compute runs on Platinum. Daytona remains a legacy fallback, and its removal is scheduled. Fully isolated topologies are scoped with the Kortix team rather than self-served.

The split has one consequence worth knowing before you start. Sessions run on a remote sandbox and have to call back to your instance, so the instance needs a URL a sandbox can reach. That is the first question the installer asks. It is also the first thing people get wrong. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.

What to have ready before the first command

A host with Docker on it, because the stack is a Compose project. The same release runs on a laptop, a VPS or a cloud VM, and a domain is one environment variable rather than a different deployment.

A URL the instance is reachable at: a domain you point at the box, or a Cloudflare tunnel for evaluation. A tunnel is for a first look. The URL changes when the tunnel restarts, and a changing callback URL breaks sessions.

A Platinum API key. It is the one credential the stack genuinely cannot start without. Nothing else on this list has that weight.

You do not need a model key or GitHub access yet. Both are set in the dashboard after the stack is up: GitHub at Settings → Git, the model key in the model picker. Kortix runs on any model provider with your own keys, and an instance carries no managed lineup to fall back on. An admin email, an Enterprise entitlement, Pipedream credentials and an update window are optional at install time and changeable later.

The six questions, and what the CLI writes for you

Install the CLI, then start the stack:

curl -fsSL https://kortix.com/install | bashkortix self-host start

kortix self-host start creates the configuration if it is missing, then brings everything up. You are not handed a template env file to fill in. The CLI asks the handful of things only you can know and generates the rest:

1. How this instance is reachable. A domain, or a tunnel for evaluation. Sessions call back, so this is the real decision.
2. An admin email. It grants platform admin, so you can configure GitHub and the rest in the dashboard. Optional.
3. Whether the instance holds an Enterprise entitlement. That switches on SAML SSO, SCIM directory sync, custom roles, groups and reading the audit record. Every install carries both sets of built-in roles: an account role of owner, admin or member, and a project role of Manager or Member on each project.
4. Who may create organizations. Admin-only by default, and people still join by invite or SSO either way.
5. Your sandbox provider and its key. Platinum, with the key from the section above.
6. Connectors and the update window. Pipedream credentials for the 3,000+ app catalog, optional and skipped by default, then whether to auto-update nightly.

What lands on disk is worth reading twice. Every host port, with a free one picked if yours is taken. Every internal URL the services use to find each other. The database password, the JWT signing secret and the API keys derived from it. The gateway, service and tunnel signing tokens. A fresh RSA keypair for SAML, so SSO has a key the day you switch it on. The whole docker-compose.yml and .env are written at mode 0600.

Nothing there is final. kortix self-host env rotate rotates what the CLI generated, and kortix self-host env ls shows every value, masked unless you pass --show. Then check on it:

kortix self-host statuskortix self-host logs kortix-api

Pointing your CLI at your own stack

A host is one Kortix API endpoint with its own token, and kortix self-host start registers your instance as selfhost and makes it active. Tokens are stored per host, so switching hosts switches the account and the default project with it.

kortix hosts lskortix hosts use selfhostkortix hosts use cloud

To avoid switching for a single command, pass --host selfhost instead. If you also run Kortix Cloud, kortix hosts use cloud puts the managed one back.

Two directories and a file are the backup

The Postgres data directory, the storage directory, and the .env that holds every key the instance uses. Copy those three and you have copied the instance. There is no separate backup service to configure, and nothing to export from anyone else's account.

The updater runs on its own schedule. It checks once a day at a time you set, runs the migration, then starts the new services before it stops the old ones, so the handover is a few seconds of both rather than an outage. Track the curated stable channel, ride latest, or pin an exact version and never move.

Three things that catch people in the first hour

The callback URL comes first. A laptop install behind a changing tunnel registers sessions whose sandbox cannot find its way home. Set a domain, or a named tunnel whose URL stays put.

GitHub and the model key come second. Neither is asked during install, and both sit in the dashboard afterwards. Skip that step and you have a running instance with no repo and no model, which looks like a broken install and is not one. Policy has its own default to check while you are there. Approval gates you set. Off until you set them.

Compute comes third. Sandbox hours stay on the provider you configured, and that is where they are billed. The shape of the number is public. Eleven credits buys one agent-computer hour at 2 vCPU, 4 GB and 20 GB. A vCPU-hour is $0.0324, memory is $0.0108 a GB-hour, and storage is $0.0526 a GB-month. All of it bills per second and costs nothing while a computer is stopped. The pricing page runs that arithmetic for a few team sizes, so the number to plan is hours of work rather than size of machine.

If you are still deciding whether to self-host at all, the self-hosting decision page walks the choice rather than the install.