Run AI agents privately on open source you own

A chatbot needs a model and a window. An agent needs the model. It also needs four things that sit outside the conversation: a credential for each system it acts in, outbound traffic to reach those systems, a computer to run commands and keep files on, and a record of what it did. Strip those four away and the agent answers questions. Leave them in place and it can file the invoice.

Privacy claims usually cover two layers. Your data sits in a region you picked, and the model answers from an endpoint you pay for. Neither layer says where the agent's computer runs, or which hosts its commands can reach. Egress is the part people drop first. A deployment with no outbound path cannot open a pull request, read a mailbox or update a customer record. It runs no work worth watching. The computer matters next, because a session holds a workspace, a shell and whatever packages it installed. The record comes last and hurts most, usually the first time a reviewer asks who approved a change.

Kortix splits the four in a way you can write into an architecture note. The rules, the memory, the secrets, the database and the audit record live on a server you run. The machine the agent works on lives on compute you configure. Both halves are accounts you hold, and neither one is a claim that the network is sealed.

Three shapes cover most of what teams build for self-hosted AI agents, and they differ in which half moves.

The first puts everything on one machine. The model endpoint, the control plane and the agent's workspace share a box behind a tunnel. A Cloudflare tunnel publishes the API, so the workspace can call back. Nothing to arrange in DNS, no certificate to renew, and the whole system is one host to back up. It also caps what you can run. One box serves the API and every session on it. A long turn slows the next person's page load, and a reboot ends the sessions in flight. For an evaluation it is the right trade. For a team of ten it becomes the thing everyone waits on.

The second keeps a control plane on your server and puts sessions on compute you configure. That is the shape Kortix ships. "A self-hosted instance is the full Kortix platform on a server you control: one Docker Compose stack that the kortix self-host CLI installs, configures and updates." The split runs through the whole design: "Sessions run on Platinum sandboxes, not on the server." What stays with you is the half that carries the knowledge and the evidence: "Self-host and the database, the files, the repos, the secrets and the audit record all sit on disk you control, on one Docker Compose stack built from the same images the managed cloud runs." Sessions on top of it do not share a workspace: "One isolated sandbox per session. Each session has its own isolated machine and branch."

The limit belongs in the same paragraph, where a reader can weigh it. "It is not air-gapped, and we will not pretend otherwise: agent sandboxes run on the compute provider you configure, and your instance has to be reachable so they can call back." That sentence is the whole honest position. You own the configuration, the knowledge and the trail. You rent the machine the agent touches, at a provider you picked, in a region you can name. The deployment shapes set beside each other on the private AI platform page go into more detail on the same trade.

The third shape puts the model and the agent on your own GPUs. Open weights served from hardware in your rack never cross a network you do not control, and the per-token bill stops. What it costs is capital and a person. Someone has to serve the models, upgrade them when a better open release lands, and keep the inference stack patched. The agent layer still has to exist on top of that endpoint. That is either Kortix pointed at your own keys, or a framework your team assembles around it. Few teams need this shape. The ones that do usually cannot buy anything else, because the internet path is the part their review will not allow.

Six things have to be true before the first session, and most of them are one-time work.

A Linux server with a public IP. The bootstrap script installs Docker Engine and the Compose plugin; on a server that already has both, you install only the CLI. DNS comes next, and it has to be in place before the first start, because Caddy needs the records to get a certificate. Add A or AAAA records for kortix.example.com and api.kortix.example.com, plus a wildcard *.p.kortix.example.com for previews. Skip the wildcard and browser previews fall back to a path proxy that breaks root-absolute links, and doctor fails on it. Ports 80 and 443 open inbound.

Then two keys, and they do different jobs. The Platinum API key is the compute: without it, sessions do not start and projects have no Drive. The model key is added later, in the app, per project, because a self-hosted instance has no managed models.

The last item is the one people skip, and it is a one-line fix at the right moment. A new instance confirms every sign-up without sending mail. "Until you set EMAIL_URL or DISABLE_SIGNUP=true, anyone who reaches the instance can create a confirmed account for any address, the admin address included." Sign up as the admin first, then set one of those two values and restart. The self-hosting guide walks the same steps with the commands in order.

A week of real work answers three questions, and the instance already holds the evidence for all of them.

Which actions asked for approval. "Approval gates you set. Off until you set them." So the first number is the count of pauses. A week in which nothing ever waited for a person means no gate is doing anything yet. Open the project's connector policy, set each action to Allow, Ask or Block, and watch what changes on Monday.

What the record holds. Every session writes a log, and session work lands through a change request rather than a direct write to the default branch. Take one finished task and follow it: the session, the diff, the person who approved the change request, the merged commit. If any of those four is missing from the trail, the process has a hole you can still fix. Reading and exporting the audit log depends on the plan, so check that before you promise a report to anyone.

What a session costs. Two meters run at once: sandbox minutes and model tokens. The platform stops an idle sandbox 15 minutes after its last turn by default. A running turn holds its machine for up to 240 minutes. A session left open after the work ends is cheap; one that runs all night is not. Preview traffic keeps a sandbox alive for 30 minutes, which is worth knowing before someone pins a link in a channel. Tokens bill on your own provider key, so the model line on the invoice is the one your team controls directly.

kortix self-host doctor closes the loop. It exits 0 when every check passes and 1 when one fails, and --json prints the result for a monitoring job.

A local install with no public URL looks like the safest option and is the one that does not work. In that mode every port binds 127.0.0.1, nothing is reachable from outside the host, and sessions do not run, because the sandbox cannot reach the API. You end up with a web app you can click and an agent that never does anything. That is a demo of a UI, not a deployment.

The same trap appears in a vendor pitch. Any product that shows a session doing work while nothing on the network can be reached is hiding a path. That session runs somewhere, on some compute, with a route back to the control plane. Ask where, and ask which provider. A deployment that answers both questions and names the region is one a reviewer can approve. A deployment that answers neither has an air gap in the slide and a rented machine underneath it.

The version of this that holds up is the second shape. Rules, memory and record sit on your disk. Sessions run on compute you named, and the instance stays reachable enough for them to call home. Put the split in the architecture note beside the provider name and the region. The page on private AI with approvals and an audit trail covers what to log and who approves it.