Self-host an open-source Claude Cowork alternative on your own hardware

What self-hosting Kortix means

Kortix is the open-source AI Operating System, and self-hosting it means running the whole platform on hardware you control. The runtime, the configuration and the data sit on your Linux box rather than in a vendor’s cloud. Here "self-hosted" has a precise shape: one Docker Compose stack that carries the frontend, the API, the LLM gateway and a bundled Supabase distribution.

Everything that describes how your company works lives in one git repo you own. Your agents, their skills, your company memory and every connector’s configuration are files in that repo, versioned and diffable. Any model provider with your own keys. The code is open source: read it, fork it, audit it on Kortix on GitHub.

Self-hosting does not remove the review gate. Agent work still reaches your default branch through a change request a human merges, whether the box is a laptop, a VPS, a VPC or an on-prem server. If you are weighing this against a hosted platform, the self-hosted AI agent platform guide sets the two side by side.

The install, command by command

Two routes install Kortix. The first is a one-shot bootstrap script for a bare Linux box that installs Docker, installs the kortix CLI and starts the stack in a single command. Read the docs for both routes.

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

That script runs on Linux only. On another operating system, install the CLI directly and use the manual path, which shows exactly what the bootstrap automates.

1. Install the CLI: curl -fsSL https://kortix.com/install | bash.
2. Point DNS and open ports. Create A or AAAA records for your domain and for api.<domain>, both aimed at the box, then open ports 80 and 443 so the bundled Caddy proxy can issue its TLS certificate.
3. Render the stack: kortix self-host init --domain kortix.example.com. The command writes the Compose file, .env, a Caddyfile and an updater script, with ports, URLs and keys already generated.
4. Start it: kortix self-host start.
5. Watch it settle: kortix self-host status, kortix self-host logs and kortix self-host doctor report progress while the stack comes up.
6. Add the two credentials: kortix self-host configure prompts for a sandbox provider key and, optionally, a managed-git token. Then connect your own LLM key in the dashboard’s model picker, because a self-hosted instance uses your key by default.

Where the instance lives, and what to back up

One directory holds the entire instance: ~/.config/kortix/self-host/<instance>/. The rendered stack definition and settings sit at its root, and the data sits in two directories beneath it.

• volumes/db/data holds the Postgres database.
• volumes/storage holds file storage.
• .env holds every secret and signing key the instance uses.

Kortix has no separate backup system. Copy those three somewhere off the box before you run any destructive command. The self-hosted AI workspace guide covers how the repo, memory and connectors fit together once the stack is up.

The change-request gate on every session

Each session has its own isolated machine and branch. OpenCode is the harness. The agent plans, runs tools, commits and pushes, then opens a change request. Session work reaches main through a change request. Merge is default-deny for agents.

From the CLI the same review works three ways: kortix cr ls lists change requests, kortix cr diff reads the patch, and kortix cr merge lands it. On a self-hosted box that gate is the point. The agent holds broad tool access inside its sandbox, and the change request is where you keep control. Coordinating many sessions across a team is the subject of the AI agent orchestration guide.

What still touches the internet

Two facts decide how isolated the box really is. First, kortix self-host start pulls its images from a registry, so the host needs outbound access to pull them, and the bundled updater checks for new images once a day. Second, agent sessions do not run on your hardware at all. They run on a separate sandbox provider, with Daytona as the default and Platinum and E2B also supported, and the API reaches that provider over egress.

So a self-hosted Kortix is not a fully offline install. The split has a practical payoff: parallel sessions consume the provider’s compute instead of your box’s CPU and memory, which keeps the host small. In exchange you keep one outbound dependency to plan for. To hold a release still, pin an exact version with kortix self-host update --tag <version> instead of tracking the updater, or turn auto-update off.

Sizing the host

An 8 GiB host runs the stack with its documented defaults. The API ships with a 640 MiB memory limit, which the docs size for an 8 GiB box. On a 16 GiB host whose API traffic reaches that limit, raise it to 1 GiB with kortix self-host env set KORTIX_API_MEMORY_LIMIT=1024m, then confirm the result with docker stats --no-stream.

The same rendered stack runs unchanged on a laptop, a VPS, a VPC or on-prem hardware. Moving from a trial to production changes one setting, the domain, plus the DNS records and open ports that a stable domain needs. The evaluation path skips DNS entirely: kortix self-host init --tunnel cloudflare brings the stack up behind a tunnel URL that changes on every restart.

Before you onboard the team

Work through this list before the first teammate signs in:

• A persistent domain with A or AAAA records for the domain and api.<domain>, and ports 80 and 443 open.
• A sandbox provider key, Daytona by default, or Platinum or E2B if you prefer.
• Model keys connected in the dashboard’s model picker.
• Off-box copies of volumes/db/data, volumes/storage and .env.
• An update policy: the stable channel by default, or a pinned version with auto-update off.
• Named reviewers who read and merge each change request.

With the domain, the keys and the backup copies in place, the first session runs the same way it does on the managed cloud. Get started takes the first project from an empty repo to a merged change request.