Self-hosted

The same Kortix, on your box.

One Docker Compose stack, built from the same images the managed cloud runs. Your database, your files, your repos and your policies sit on disk you control. It is open source, so what you are running is code you can read.

Same images as the cloud · One command · Any model, your keys

Install
kortix self-host start
Stack
One Docker Compose project
Models
Your provider, your keys
Updates
Nightly, or pin a version
What you keep

The company stays on your side of the wall.

Self-hosting is not a smaller Kortix with the interesting parts removed. It is the whole control plane — accounts, projects, repos, secrets, connectors, policies, audit — running inside your network, on storage you back up yourself.

on your box

  • The Postgres database, as a directory you can back up
  • File storage, as a second directory next to it
  • Every project repo and every secret the platform holds
  • Accounts, roles, policies, triggers, channels and the audit record
  • The LLM gateway your sessions route model calls through
your box

not on your box

  • Agent sandboxes, which run on the provider you configure
  • The image registry the stack pulls from, which needs no credentials

Sandbox compute is a provider choice: Daytona by default, or Platinum or E2B. local-docker runs sandboxes on the same box through Docker and is experimental — not for production. Air-gapped and other fully isolated topologies are scoped with us rather than self-served.

Two commands

Start the stack. Point the CLI at it.

There is no separate provisioning step and no console to click through. One command brings the stack up. One more decides which Kortix your CLI is talking to.

bring the stack up
# install the CLI$ curl -fsSL https://kortix.com/install | bash # create the config if it is missing, then start everything$ kortix self-host start→ stack up · dashboard registered as host "selfhost" # check on it any time$ kortix self-host status$ kortix self-host logs kortix-api
choose which Kortix you are talking to
# a host is one Kortix API endpoint, with its own token$ kortix hosts ls # work against your own stack$ kortix hosts use selfhost→ Active host is now selfhost # and back to the managed cloud$ kortix hosts use cloud→ Active host is now cloud
  • Tokens are stored per host, so switching hosts switches the account and the default project with it.
  • kortix self-host start registers the selfhost host for you and makes it active.
  • Override for one command instead of switching: pass --host selfhost.
First run

Six questions. Everything else is generated.

You are not handed a template env file to fill in. The CLI asks the handful of things only you can know, generates every port, URL, password, signing key and Compose default itself, and writes the whole instance to one directory.

  1. 01

    How this instance is reachable

    A domain you point at the box, or a Cloudflare tunnel for evaluation. Sessions run on a remote sandbox and have to call back, so this is the first real decision.

  2. 02

    An admin email

    Grants platform admin, so you can configure GitHub and the rest in the dashboard. Optional, and you can set it later.

  3. 03

    Whether you hold an Enterprise licence

    Unlocks SAML SSO, SCIM directory sync, custom roles, groups and audit read on this instance.

  4. 04

    Who may create organizations

    Admin-only by default. People still join by invite or SSO either way.

  5. 05

    Your sandbox provider and its key

    Daytona, Platinum, E2B, or experimental local-docker. This is the one credential the stack genuinely cannot start without.

  6. 06

    Connectors, and the update window

    Pipedream credentials for the 3,000+ app catalog — optional, skipped by default — then whether to auto-update nightly.

what it generates for you

  • Every host port, reassigned automatically if one is already 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 turn it on
  • The whole docker-compose.yml and .env, written at mode 0600

Everything the CLI generates is rotatable later with kortix self-host env rotate, and every value is visible with kortix self-host env ls, masked unless you ask for --show.

GitHub and your model key are not asked here on purpose. Both are set in the dashboard after the stack is up — GitHub at Settings → Git, the model key in the model picker.

The stack

One Compose project, no hidden pieces.

The same artifact runs on a laptop, a VPS or a cloud VM. A domain is one environment variable, not a different deployment. Everything lives in one instance directory you can back up by copying it.

one hostdocker compose

kortix

  • frontendThe web app
  • kortix-apiThe API and the in-process LLM gateway
  • llm-gatewayControl-plane routing
  • kortix-migrateOne-shot database migration on every roll
  • kortix-updaterNightly pull, migrate, then swap

data plane

  • supabase-dbPostgres, on a directory you control
  • supabase-authSign-in, invites and SAML
  • supabase-restThe data API
  • supabase-storageFiles, on a second directory
  • supabase-kongThe data-plane gateway

edge — only what you chose

  • caddyAutomatic TLS. Rendered only when you set a domain
  • cloudflaredThe tunnel. Rendered only in tunnel mode

Your data is two directories and a file

The Postgres data directory, the storage directory, and the .env that holds every key the instance uses. Back up those three and you have backed up the instance. There is no separate backup service to configure, and nothing to export from us.

It keeps itself current

The updater checks once a day at a time you set, runs the migration, then starts the new services before it stops the old ones. Track the curated stable channel, ride latest, or pin an exact version and never move.

Parity

Not a community edition.

This is not a stripped build with the good parts held back for the paid tier. Self-hosted instances run the same images the managed cloud runs, produced by the same pipeline, on the same release train.

The same images
The frontend, the API and the gateway are the published Kortix images. A self-hosted instance never builds its own — it consumes exactly what the release pipeline already produced.
The same product surface
Projects, sessions on their own cloud computers, agents, skills, connectors, channels, triggers, secrets, change requests and the audit record. Nothing on that list is cloud-only.
One honest exception
SAML SSO, SCIM directory sync, custom roles, groups and reading the audit log are Enterprise entitlements. On a self-hosted instance they switch on with an Enterprise licence. The built-in owner, admin, member, manager and editor roles are there on every install, and the audit record is written on every install whether or not you can read it back yet.
No metering in the way
A self-hosted instance runs its own gateway for its own model routing. It never sees or routes to Kortix credentials, and there is no platform fee on a self-hosted account.
Models

Any provider. Your keys. Your bill.

A self-hosted instance has no managed model lineup and does not want one. You connect the providers you already pay for, and every model call routes through the gateway running on your own box.

connect a provider
# stored as an encrypted project secret, injected at session boot$ kortix providers set anthropic sk-ant-...$ kortix providers set openai sk-...$ kortix providers set openrouter sk-or-... # or the subscription you already pay for$ kortix providers login chatgpt $ kortix providers ls→ anthropic · openai · openrouter

The gateway is yours

Sessions call the gateway inside your own stack, over your own domain or tunnel. Kortix has no credential in that path and no visibility into it.

Anything you can reach

Anthropic, OpenAI, Google, Groq, xAI, DeepSeek, Mistral, Bedrock and OpenRouter, or the ChatGPT and Copilot subscription you already hold.

Where it runs

A laptop, a VPS, or your own network.

It is the same Compose project everywhere. What changes is where you point the domain and how much you give it.

A laptop
Evaluation, through a Cloudflare tunnel with no domain. The tunnel URL changes on every restart, so use it to try the product, not to run on it.
A VPS or cloud VM
The production path. Point a domain and its API subdomain at the box, open 80 and 443, and the bundled proxy takes out a TLS certificate itself.
Your own VPC or on-prem
The same stack inside your network. Isolated and air-gapped topologies need the sandbox tier moved inside with it, which we scope with you.
Machine
2 vCPU / 4 GB floor, 4 vCPU / 16 GB for real use
Runtime
Docker Engine with the Compose plugin
Inbound
Ports 80 and 443, with a domain
DNS
A record for the domain and for api.<domain>
Two ways to run it

Run it yourself, or let us run it.

Self-hosting is free and always will be. Kortix Cloud is the same product with the box, the upgrades and the sandbox tier taken off your hands.

Need it inside your own network, with SSO and a licence? Talk to us. Talk to us.

Self-host Kortix | Kortix