Self-host an open-source AI agent that works all night

What changes when the agent runs on your server

Three things have to hold at three in the morning: a machine that stays up, credentials that still work, and a record you can open afterwards. You can rent all three, and for most teams that is the sane default. Owning them is what makes the record readable, because it lands in a repository you control instead of a vendor's activity view.

OpenAI's Dots is the rented shape. A dot keeps its work on OpenAI's computers and reaches you in ChatGPT, Slack or Teams, and nothing on its launch page offers a way to run one yourself. Self-hosting splits the arrangement in two. The control plane, meaning the agents, skills, memory and connector grants, is a Docker Compose stack on a Linux box you pick (self-hosting). The sessions are not.

The sandbox stays outside. One isolated sandbox per session. Each session has its own isolated machine and branch. Those machines are created on a cloud provider and call back to your instance over its public API, so the domain needs A and AAAA records, its API subdomain needs the same, previews need a wildcard, and ports 80 and 443 need to accept traffic before the first start. What moves onto your box is the platform. Model traffic still goes to the provider you connect.

The provider key is the second change. You add it to the project in the web app, and calls leave your instance's gateway for that provider. Any model provider with your own keys. A procurement review tends to like the shape: one key to rotate, one contract, one place where spend shows up.

A trigger starts a session when no person is present, either on a cron schedule or from a signed webhook that another system sends (triggers). session_mode then chooses between a fresh session, a reused one, a pinned one and one keyed to an identifier, and fresh is the default. If a schedule looks like it is ignoring you, read that field before you debug anything else.

The record is why teams bother. Session work reaches main through a change request. Merge is default-deny for agents, so an agent that tries without the grant gets a 403 with agent_scope_insufficient (quickstart). Each session works on a branch named for its ID, and what it wants to keep it commits and proposes. Morning reading is a diff.

What stays in your repository

kortix.yaml is a manifest rather than a settings screen. It declares the machine image, the connectors and triggers, and the secret names and grants, and each agent's behavior lives in a markdown file beside it (manifest). Changing what an agent may do produces a diff: reviewable, revertable, greppable next year.

The grant list is where operators slip. Connectors and secrets are granted per agent, so the agent that drafts the weekly report and the agent that can push to a repository are two files with two lists. Self-hosting does not change that separation. It changes where the separation is enforced.

The starter's agent file carries the rule the sandbox enforces: "Only what you commit + push survives." A session's value is the branch it pushes, so anything that never lands disappears with the session.

What you take on starts at the operating system: a Linux box with a public IP, those DNS records, inbound traffic on 80 and 443, and a Platinum API key, without which sessions never start. The model provider key goes in after the first sign-in, and the order matters, because DNS comes before the certificate and the stack comes before the admin account. Init writes docker-compose.yml, .env, a Caddyfile and updater.sh under ~/.config/kortix/self-host/<instance>/.

What it costs to run

Self-host is free, and that is the whole of the software bill. Four things still cost money: the server, model calls at your provider's list price, the Platinum API key behind session compute, and the hours somebody spends on upgrades.

The hours are steady rather than difficult. Caddy renews certificates, so DNS has to be right from the start. A daily updater pulls images, migrates Postgres and rolls the services while you may be asleep. Backups of the accounts database are yours to schedule and to test. When an upgrade lands, kortix self-host doctor lists what is broken.

One trap pays to know before the URL goes anywhere. A fresh instance accepts a confirmed account for any address, the admin included, until EMAIL_URL or DISABLE_SIGNUP=true is set. Sign up as the admin and connect GitHub at /admin/git while the stack is still warm (self-hosting).

When the managed cloud is the better buy

Hand the Linux box to Kortix Cloud if nobody wants to own DNS, certificates, upgrades and backups, or the two-in-the-morning question of whether the stack or the model provider is down. Two people shipping one weekly report do not need a server. A team that mostly wants an agent answering in Slack and Teams can compare the managed plan with Dots for teams. If nobody on the team would own a Postgres upgrade this quarter, renting is cheaper than learning.

Self-hosting pays in narrower cases: the platform has to sit in your own VPC or on your on-prem network, somebody already runs that network, and a reviewer wants the image and the commit behind a piece of work. Then the move is smaller than most teams expect, because the project is already a git repository with kortix.yaml at its root and every session works on a branch.