Self-host an AI operating system that is open source

What self-hosting decides

A self-hosted AI operating system puts the whole agent stack on hardware you administer: the runtime, the store that keeps company memory, the service that brokers connector credentials, and the record of what every agent did. Kortix ships that stack as open source. Agents, skills, memory files and the wiring to outside apps are all files in a git repository, and every session of work runs on a separate cloud computer.

Where those services run is the decision behind self-hosting. On Kortix Cloud the vendor operates them. Self-hosted, your team does, and the parts that hold your data hold it inside a deployment you control. The project itself does not change. Its configuration lives in kortix.yaml at the root of a git repository, hosted by Kortix or connected from your own account.

Three commands on a fresh server

Installing by hand is three commands (Read the docs). curl -fsSL https://kortix.com/install | bash installs the CLI, kortix self-host init asks the setup questions. kortix self-host start applies the answers and brings the stack up with a TLS certificate. The CLI runs on macOS and Linux, on x86_64 and arm64; on Windows, run it inside WSL.

Before the first start, the server needs a name. Point its A or AAAA records, one for the domain and one for the api subdomain, at the server, add a wildcard record for session previews, and leave 80 and 443 open inbound. The TLS server in the stack needs those records before it can request a certificate.

The setup questions cover the domain, the admin email and the sandbox provider; a model key is not one of them. You add a model key in the web app after the first sign-in, and the sandbox provider key has to exist before any session can start. Then sign in as the admin, connect GitHub in the dashboard, and run kortix self-host doctor, which turns every failed check into a named problem to fix.

What runs where

Sessions run on a cloud sandbox provider, not on the server, and those sandboxes reach back to the instance over the public internet, so the instance needs a public address (Read the docs).

On the server, one Compose project holds every service: the web app, the REST API, the LLM gateway, the database, and the TLS terminator. A built-in updater pulls new images once a day, migrates the database, and rolls the services. Off the server go the sandboxes themselves, created with your provider key on Daytona, the default today, or on Platinum or E2B. The model providers sit outside too, and the gateway calls them with your keys.

In practice you hold the control plane and the data, and a provider you chose and keyed executes each session. The callback requirement sits in the opening paragraphs of the self-hosting docs.

What you hold when the stack is yours

Memory comes first. In the starter layout (Kortix on GitHub), memory/ is a folder of the project repo, plain files next to the agents and skills. It is versioned by git, backed up by a push, and grep reaches your whole company. There is no export step because no vendor holds it.

Connector credentials are brokered server-side and never enter the machine. On your instance, the broker is part of the stack your server runs (Read the docs). Secrets are encrypted at rest with a key per project. The manifest declares secret names and nothing else; the values live in the secrets manager, never in the repo.

Per-resource permissions for people and agents. Roles, groups, and an audit trail. Every action is recorded in the audit log, which keeps 90 days of events live and up to 365 days in the archive (the Kortix docs). Reading, exporting and streaming it depend on the plan.

Projects, sessions and change requests

With the instance up, projects work the way the Kortix docs describe. kortix init scaffolds a project from the starter, kortix ship validates the manifest, asks for missing secrets and pushes the repo. The first run creates the project. A session gives one agent a sandbox and a branch of its own, with the project repository cloned in.

When the work is done, the agent commits to its own branch and a change request carries the result to review. A person reviews it and merges, or sends it back with a note that wakes the session. The manifest sets the governance in advance: the project registers what exists and each agent enables what it needs by name. An omitted grant resolves to none, so a scoped agent starts locked down.

Is it hard?

The requirements fit in one paragraph: a Linux machine with a public address, the domain's DNS records set before the first start, the firewall open on 80 and 443, and a sandbox provider key. The bootstrap script installs Docker and the CLI when they are missing and starts the stack with TLS. Re-running it is safe. The stack has no Redis and no separate worker.

What takes attention is the operations you now own. Certificates wait for DNS, backups are your job, and the daily updater deserves a glance when it rolls a new image. The self-hosting docs walk each step, and kortix self-host doctor turns a half-configured instance into a list of named checks. A first-run walkthrough is in Getting started with Kortix on the Kortix blog.

One boundary remains. The sandbox provider that executes your sessions is a third party, and the instance has to stay reachable on the public internet. If you would rather not run a server at all, Kortix Cloud runs the same product. The project is one repository either way; what changes is who operates the services around it.