Open-source self-hosted AI agents your team can still operate

A list answers a smaller question than the one you asked

Search for self-hosted AI agents and page one is Reddit threads, a couple of videos and listicles. The listicles line coding agents up in a row. Most of those tools do what the list says. None of them tells you whether the install on your own server will still answer in month three. A feature table is the wrong instrument for that question.

A coding agent on a laptop and a system a team runs are different buys. The first is one process on your machine, your keys, a session you close when the work is done. The second carries a control plane, a database, stored files, accounts, connectors and backups. It also has to survive an update on a Tuesday afternoon without losing the credentials it needs to run.

Kortix is the open-source AI Operating System: your agents, their skills, your company memory, and every connector in one git repo you own, with the agents working on real cloud computers. Self-hosting it moves the control plane, the Postgres database and the stored files onto a server you control. Sessions still run on Platinum sandboxes and call back to the instance's public URL. Verify that callback before anything else.

Four readings that decide the first week

An instance rarely falls over on the model. It falls over on something you could have measured earlier. A public operator kit built around the Kortix CLI (selfhosted-ai-agents-stack) turns four of those readings into scripts. Each one exits non-zero on the failure it prevents. An afternoon of output beats a page of promises.

Closed sign-up

A domain-mode instance is reachable on purpose. A new one also confirms accounts without sending mail. Until you close it, anyone who finds the host can register a confirmed account for any address, the admin address included. The first person to claim that address becomes platform admin. check-signup.sh asks the auth settings whether a stranger can join and prints OPEN or CLOSED. Closing it takes one environment variable and a restart. Re-run the check after every update, because an update is when a setting tends to return.

A callback a sandbox can reach

No session runs on your server. kortix-api creates each one on a Platinum sandbox with your key, and that sandbox calls back to the instance's public KORTIX_URL. If api.<domain> does not resolve, the stack looks healthy and no session starts. preflight.sh prints that failure by name before anything is written. It also probes the wildcard record previews need. Without it, a browser preview falls back to a path proxy that breaks root-absolute links.

A backup that carries the key

The instance directory is the unit to copy. .env holds the signing keys, volumes/db/data is Postgres, volumes/storage keeps the files. A database dump captures one of the three and leaves the key behind. API_KEY_SECRET decrypts every stored secret, so an archive without it restores a stack that serves pages and cannot read its own credentials. restore.sh fingerprints the archived key and compares it with the live one. When they differ it refuses the swap. That is the refusal you want to meet on a spare instance.

A doctor someone reads

Seven checks read the container runtime, the compose file, the instance directory, the mail URL, preview origins and open sign-up. Six of seven is the usual first result. The one that fails is the failure that would have surfaced after an update at the worst moment. A doctor nobody runs is just a script. The kit folds it into a weekly pass with the sign-up check, update status and backup age. That pass exits 1 when a person needs to act.

What each tool leaves you to run

The four tools differ in the work that stays with you. OpenClaw is a personal assistant that meets you in chat apps. Its install is a single Gateway process on a host you keep running. What remains is channel pairing, the sandboxing decision for tools that otherwise run on that host, and updates. OpenHands Agent Canvas is a self-hosted control center for coding agents, installed from npm or Docker. A team ends up owning the VM hardening, the backend API key, Docker sandboxes for conversations and the nginx layer that terminates TLS.

Dify is an LLM app platform with a visual workflow canvas, RAG and observability. It comes up from a Compose file in minutes. The stack, the model providers and the apps you publish stay your responsibility, and its license adds a condition for anyone running it for other organizations. Each of the three is a reasonable tool for the job its own documentation describes. The difference is volume: how much of the install is still your job in month three.

Kortix takes the other end of that trade. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. The stack is one Docker Compose project with no Redis and no separate worker. The first run asks six things and no model key, and models are added in the app with keys you hold. What stays with you is the server, DNS, the backups and the daily updater, plus the four readings from the operator kit.

An afternoon test for any candidate

Stand each candidate up in domain mode on a throwaway host and try four things. Sign up from a phone as a stranger and see whether the account is confirmed. Resolve the API host from outside your network and start one session. Restore a backup onto a second instance and check that stored credentials still decrypt. Run the project's own health check. Does it name the failure and the fix?

A tool with no script for one of those is not disqualified. You have learned which jobs you are taking on. The price of the pager becomes part of the decision instead of a surprise in month three. The four checks hold for any of them, and the install sequence for the Kortix stack is on the stack page.