Self-host Kortix, the open-source AI agent platform, on your own server

What self-hosting Kortix actually gives you

Kortix is open source: read it, fork it, audit it. Self-hosting puts the whole system on infrastructure you control. Your agents, skills, company memory, triggers and connector config are files in one git repo you own, versioned and diffable like any code. Your model keys stay yours: self-hosted instances use your own key by default, connected in the model picker. And the machines are yours to place: the stack runs on your server, and agent sessions boot on the sandbox provider you configure.

The trade is straightforward: updates, backups and capacity planning become your job. Each has a concrete, documented answer.

The setup path, start to finish

The fast path is one command on a bare Linux box. The bootstrap script in the One command panel installs Docker, installs the kortix CLI and starts the stack. It runs on Linux only; on another OS, install the CLI directly and take the manual path.

The manual path gets you to the same place. Install the CLI with the install script. Point DNS at the box: an A/AAAA record for your domain and another for api.<domain>, both to the box's IP, and open ports 80 and 443, which the bundled Caddy proxy uses to issue a TLS certificate. Then run kortix self-host init --domain kortix.example.com and kortix self-host start, the two commands in the Step by step panel. While the stack comes up, kortix self-host status, kortix self-host logs and kortix self-host doctor tell you where things stand.

No domain yet? Evaluation mode swaps the domain for a Cloudflare tunnel: kortix self-host init --tunnel cloudflare, then start. The tunnel URL changes on every restart, so treat this mode as evaluation, not production.

After the stack starts, run kortix self-host configure. It is an interactive prompt for the sandbox provider key and, optionally, a managed-git token. Sign up in the dashboard, then connect your own LLM key in the model picker.

One capacity fact is worth knowing before traffic arrives. Each API service in the stack has a 640 MiB memory limit by default; keep that default on an 8 GiB host. On a 16 GiB host, raise it to 1 GiB when API traffic reaches the default, with kortix self-host env set KORTIX_API_MEMORY_LIMIT=1024m, and confirm the applied limit with docker stats --no-stream.

What runs where

The stack you install is one Docker Compose unit with four parts: the frontend, the API, the LLM gateway, and the Supabase distribution. That is the control plane, on your box.

Agent sessions run on a separate sandbox provider, not on this stack. Daytona is the default; Platinum and E2B are also supported. Each session gets its own isolated machine and branch, does its work there, and opens a change request when the work is ready. Session work reaches main through a change request a person approves, and merge is default-deny for agents.

Plan for two network paths when you place the box. The stack pulls its images from docker.io, and sandbox sessions call back to your instance over the network, so the instance needs to be reachable from the provider you chose.

Choosing between platforms is a separate question: the comparison chart on this site lines them up, and the FAQ answers what buyers ask before committing.

Updates and backups you own

Every instance updates itself automatically. Pin an exact version when you want control: kortix self-host update --tag 0.9.84. Turn the updater off with --auto-update off.

There is no separate backup system. Each instance stores its data as two directories under ~/.config/kortix/self-host/<instance>/: volumes/db/data (the Postgres database) and volumes/storage (file storage). The instance's .env file holds every secret and signing key it uses. Back up all three before you run a destructive command.

The guide behind these commands also explains the stack's architecture and lists every kortix self-host flag. Read the docs to go deeper, and the Kortix blog carries the wider case for owning an open-source agent platform.