Self-host the open-source Kortix AI Operating System

01What a self-hosted Kortix instance installs

A self-hosted Kortix instance is one Docker Compose stack. The frontend, the kortix-api image, the LLM gateway and the Supabase Docker distribution all run on the box you choose. When you set a domain, Kortix also renders Caddy for TLS and a small updater that keeps the images current. The same Compose file runs on a laptop, a VPS or a server in your own cloud account. A domain is only the value of KORTIX_DOMAIN; it is not a different setup. Kortix documents how the pieces fit together.

Three things land on disk and stay yours. The company itself is one git repo: kortix.yaml declares the agents and what each may touch, each agent is a markdown file at agents/<name>.md, each skill lives at skills/<name>/SKILL.md, and project memory accumulates under memory/. Grep it, diff a change, roll one back. The instance data sits under ~/.config/kortix/self-host/<instance>/: the Postgres database in volumes/db/data and file storage in volumes/storage. The instance .env holds every secret and signing key the stack uses.

Connector credentials are brokered server-side and never enter the machine. Secrets are encrypted at rest with a key per project. One isolated sandbox per session, and session work reaches main through a change request.

02What the first run asks for

The first run asks for a few values and no model key. You point the install at a domain, or use a Cloudflare tunnel for evaluation, and later run kortix self-host configure to enter a sandbox provider key. Models are BYOK in the app, so you connect your own provider key in the model picker once the stack is up. GitHub connects in the dashboard under Settings → Git. The stack has no Redis and no separate worker.

Plan for memory as well. Each API service defaults to a 640 MiB limit, and that default suits an 8 GiB host. On a 16 GiB host with API traffic pressing the limit, raise it:

kortix self-host env set KORTIX_API_MEMORY_LIMIT=1024m

03Install and start the stack

On a bare Linux box, the one-shot bootstrap installs Docker, installs the kortix CLI and starts the whole stack:

curl -fsSL https://github.com/kortix-ai/suna/raw/dev/scripts/kortix-selfhost-up.sh \  | bash -s -- --domain kortix.example.com --email ops@example.com

Create the DNS records for your domain and for api.<domain> before you run it, and open ports 80 and 443. On macOS, or on any host you would rather configure by hand, install the CLI and run the manual path:

curl -fsSL https://kortix.com/install | bashkortix self-host init --domain kortix.example.comkortix self-host startkortix self-host status

kortix self-host init renders the Compose config and the .env, and kortix self-host start brings the stack up. kortix self-host doctor validates the Docker tooling and the rendered config. To evaluate without a domain, use kortix self-host init --tunnel cloudflare; the tunnel URL changes on every restart, so run production on a real domain.

04What it needs, and what it does not

A self-hosted Kortix instance needs outbound network access; it is not an offline install. It pulls its images from docker.io/kortix/*, and agent sessions never run on the box. They run on a separate sandbox provider that kortix-api reaches over egress, with Daytona as the default and Platinum and E2B also supported. The sandbox provider key is the one credential the stack cannot start without. A domain or a tunnel gives the sandbox a stable URL to call back to, so without one, sessions cannot run.

05How it compares with OpenWork

Kortix self-hosts as the whole platform: the frontend, the API, the LLM gateway and the Supabase distribution in one Docker Compose project, with Caddy issuing TLS and a daily updater built in. The agents, the memory, the connectors and the triggers live in the git repo you own, and agent sessions run off the box on a separate sandbox provider rather than on the machine running the stack.

OpenWork is a desktop app for macOS, Windows and Linux where agents work on your own files, and its control plane can be self-hosted too. OpenWork's self-hosting docs present Docker Compose as an evaluation path and point production at a published Helm chart on managed Kubernetes, with MySQL for control-plane state and a separate worker runtime, leaving TLS, secret management, backups and cloud sandboxes to your own infrastructure. Both run on hardware you choose; the difference is what each one treats as the unit you own.