Self-Host an Open-Source AI Agent Platform: Kortix, the Self-Hosted OpenWork Alternative

Kortix keeps your agents, their skills, company memory and every connector in one git repo, runs each session in an isolated sandbox on its own branch, and lands work as a change request a person reviews. The code lives on Kortix on GitHub. Kortix is open source (Elastic License 2.0), which means you can self-host it, read the code and modify it.

What you actually own once the stack is up

Self-hosting is worth the work only if the parts you care about end up on your disk. With Kortix they do.

• Agents and skills are markdown files. Every agent and skill lives as a .md file under agents/ and skills/, so you can read, grep, diff and roll back how the company works without opening a UI.
• Company memory is files that accumulate. What the company learns is stored as files in the repo rather than in someone else's database.
• kortix.yaml declares the machine. The manifest holds the image sessions boot, the connectors the company is wired to, the triggers that start work with nobody present, and the rules for what each agent may touch.
• Your data sits in a handful of paths. A self-hosted instance stores its Postgres database under volumes/db/data, its file storage under volumes/storage, and every secret and signing key in one .env file, all inside ~/.config/kortix/self-host/<instance>/.
• Connector credentials never enter the machine. Kortix brokers connector credentials server-side and encrypts secrets at rest with a key per project.
• Every tool call has a rule. Set a connector to Allow, Ask or Block, down to the arguments of a call. An Ask holds the call until a person approves it, then the agent resumes.
• Work reaches main through a change request. Each session runs in its own isolated sandbox on its own branch, and only what a person reviews gets merged.

For a self-hosted Kortix, the whole control plane runs this way: accounts, projects, repos, secrets, connectors, policies and audit, inside your network, on storage you back up yourself. Self-hosting here is not a stripped build, because a self-hosted instance runs the same images as the managed cloud from the same pipeline.

Before you install

• A Linux box or VPS. The one-shot bootstrap runs on Linux only. On macOS or Windows, install the CLI and use the manual path.
• Docker with Docker Compose. The one-shot script installs Docker for you. The manual path expects Docker with Compose v2 already on the machine.
• A domain and two DNS records. Point an A/AAAA record for your domain and for api.<domain> at the box, then open ports 80 and 443 so the bundled Caddy proxy can issue a TLS certificate. Evaluation mode skips this.
• An LLM key. A self-hosted instance uses your own key by default, so connect a provider key in the model picker after the stack starts.
• A sandbox provider key. Agent sessions run on a separate sandbox provider rather than on the Compose stack. The default is Daytona; Platinum and E2B are also supported.
• Memory to spare. Each API container defaults to a 640 MiB limit. Keep that default on an 8 GiB host, and raise it to 1 GiB on a 16 GiB host only when API traffic reaches the limit.

Install and start the stack

Production-style install on a Linux box

One command installs Docker, installs the kortix CLI and starts the stack:

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

The first interactive setup asks only for the integration credentials that unlock managed git, GitHub access and Pipedream connectors. The CLI generates every port, URL, password, signing key and Compose default itself, and writes the whole instance to one directory.

Manual path

curl -fsSL https://kortix.com/install | bash
kortix self-host init --domain kortix.example.com
kortix self-host start

Create the DNS records first. kortix self-host init generates the config, and kortix self-host start brings the stack up and registers it as a host named selfhost. A host is one Kortix API endpoint with its own token, so kortix hosts use selfhost points the CLI at your box and kortix hosts use cloud points it back at the managed cloud. The Kortix CLI reference lists every command and flag.

Evaluation mode with no domain

kortix self-host init --tunnel cloudflare
kortix self-host start

A Cloudflare tunnel gives you a URL without DNS. The tunnel URL changes on every restart, so use this mode to evaluate rather than to run production. Kortix's self-hosting docs cover ports, the update schedule and the stack architecture.

Check on the stack

kortix self-host status
kortix self-host logs kortix-api
kortix self-host doctor

Connect a sandbox provider and a model key

kortix self-host configure

The kortix self-host configure command is an interactive prompt for the sandbox provider key and, optionally, a managed-git token. After the stack starts, sign up in the dashboard and connect your own LLM key in the model picker, or set it from the CLI:

kortix providers set anthropic sk-ant-...
kortix providers login chatgpt
kortix providers ls

A self-hosted Kortix has no managed model lineup. Every model call routes through the gateway on your own box, so providers you already pay for reach your agents without a Kortix credential in the path. Any generated value is rotatable later with kortix self-host env rotate and visible, masked, with kortix self-host env ls.

Updates and backups

Every self-hosted instance updates itself. 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 stable channel, ride the latest release, or pin an exact version with kortix self-host update --tag <version> so the instance never moves on its own.

Kortix has no separate backup system, so a backup is a copy of three things: the Postgres data directory, the storage directory, and the instance's .env file. Copy all three from ~/.config/kortix/self-host/<instance>/ before any destructive command, because a restore needs every one of them.

Self-hosted Kortix compared with OpenWork

OpenWork is a free, open-source desktop app for macOS, Windows and Linux that lets agents work on your own files and stays local-first; its team control plane can be self-hosted too, with Docker Compose for evaluation and Kubernetes for production (OpenWork self-host docs). Kortix takes a different shape. The self-hosted unit is the whole platform, the frontend, the API, the LLM gateway and the Supabase distribution as one Compose stack, while agent sessions run on a separate sandbox provider.

Both are open source and both run on hardware you choose. The difference is the unit each one owns. OpenWork centers on a desktop app and a control plane for shared skills. Kortix centers on a git repo that holds the agents, memory, connectors and triggers themselves, plus a reviewed change request as the only gate to main. The Kortix vs OpenWork comparison covers the feature-by-feature breakdown, and the OpenWork FAQ handles the common questions.

Self-host, cloud, VPC or on-prem

Kortix self-hosts free. The managed cloud Team plan costs $40 per seat per month and includes 2,500 pooled credits per seat per month, while the Free plan starts at $0 with 200 sandbox credits a month (Kortix pricing). Enterprise covers cloud, VPC or on-prem deployment with SAML SSO and audit logs.

Self-host when your team already has the box or VPS and wants the Postgres data, the file storage and the configuration on disk it controls. Choose managed cloud when you would rather skip the install, or VPC and on-prem when policy keeps the stack inside your own network. Rolling this out to a team raises seat and permission questions, which the Kortix for teams page answers.

Start with the install command above, or Get started with Kortix. The OpenWork alternative home page starts from the top of the comparison.