# Self-host an open source agent runtime on hardware you control

> Self-hosting an agent runtime means running the platform, its database, its object storage and its model keys on a server you control, while each session’s machine comes from the sandbox provider. Kortix is the open-source AI Operating System. Your agents, skills, company memory, and connectors live in one git repo you own.

URL: https://agentruntimesguide.com/self-hosted-agent-runtime

## The self-hosted install, in three lines

`self-hosted`

```sh
Run the same Kortix on your own box. One Docker Compose stack, the same images the managed cloud runs, your database and your files on disk you control.
kortix self-host start
kortix hosts use selfhost
```

Source: https://kortix.com/markdown/self-hosted.md

One Compose stack and the same images as the managed cloud, started with two commands.

## Four things a self-hosted runtime has to own

A runtime you host is four things at once, and a managed product normally bills you for all four in one line. Compute is the machine each session runs on. On a self-hosted install the default sandbox provider is remote, so the instance starts the sandbox and the provider calls back into your host. The database holds sessions, members and the state of every change request, which makes it the part of the stack you will care about most before long. Object storage holds the files a session writes and reads back. Model keys are the fourth area: the stack calls a model provider, and the account on that invoice is yours. Everything else in the install is plumbing around those four, and [how the pieces fit together](/agent-runtime-architecture) decides how much of the afternoon the first run takes.

## What stays on your side of the line

The reason to move a runtime onto your own hardware is the record. A [definition of an agent runtime](/what-is-an-agent-runtime) usually stops at the loop that decides what the agent tries next, and the loop is the cheap part. The record is what accumulates while the loop runs. The database collects every session, the branch it cut and the diff that came out of it, along with the change requests that carried work toward `main`. In a managed runtime those rows belong to the vendor, and leaving the plan leaves the history behind. Kortix is open source. Read it, fork it, audit it. The configuration is a git repo you own, so an agent, a skill or a connector policy is a file you can diff, review and revert like any other code.

Credentials policy stays with the install as well. Keys sit in a database you administer, and the rules about which session may use one are yours to write and enforce. Session work reaches `main` through a change request. Merge is default-deny for agents. That gate matters more when you host, because no vendor-side review sits between a bad session and your repository.

## What you take on

The stack is one Docker Compose stack, and the images are the same ones the managed cloud runs. That buys parity and costs you a calendar. Every upstream release is a change you schedule, test and roll back, and there is no maintenance window you can hand to someone else. The session machines stay off that box: sessions run on sandbox compute the provider operates and bills, and the default provider is remote, so the host has to be reachable from it; a network policy that hides the host from the provider breaks sessions in a way that reads like a runtime bug. The first upgrade is where the docs earn their keep: [Read the docs](https://kortix.com/docs).

The model bill arrives from whichever provider you point the stack at. Any model provider with your own keys. Or the ChatGPT plan you already pay for. Or sign in with your OpenCode Console account for OpenCode Zen and Go. Price the same workload on the managed option before you commit, because [the runtime cost](/agent-runtime-cost) barely moves: self-hosting removes the Kortix credits, while the session compute and the model calls stay on their own invoices.

## How to decide

Two engineers with no customer asking where their data sits should stay on the managed cloud. The install is an afternoon, and the release cadence is a standing appointment that nobody on a small team owns yet. At around ten people, once a security review or a procurement questionnaire asks where the session database lives, the arithmetic flips: the answer becomes a hostname you control, and the review becomes a document you write once. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. The deciding question is whether the record of the work is an asset your company intends to keep, and how many people will ask you about it this year.

## Before the first command

The two questions that decide whether the install fits your network and your week.

### Can a self-hosted agent runtime run fully offline?

No. `kortix self-host start` pulls the images from docker.io, and the default sandbox provider is remote, so the install needs internet access and has to accept callbacks from the provider. Plan for a private network with egress rather than an isolated segment.

### What does the first self-host run ask for?

The first run asks six things and no model key. GitHub connects from the dashboard, and models are added in the app with a provider key or a subscription sign-in, so the stack starts before you have chosen a provider.

## Run the same Kortix on your own hardware

Bring the record of every run onto hardware your team administers.

[Try Kortix](https://kortix.com) · [Read the docs](https://kortix.com/docs)

Open source · Self-host is free · One isolated sandbox per session