The four tests an open-source self-hosted AI agent stack must pass

What self-hosted has to mean

The word arrives with an install command and a hosting invoice. Two of the products Kortix is set against in the comparison sell the hosting they run for you: Gumloop's builder runs in Gumloop's cloud, Copilot Studio's agents run in Microsoft's service, and the box you self-host is one you never open. That is the same dependency with a bigger bill, and the bill now includes a server you patch.

A business shopping for self-hosted AI agents is not shopping for metal. It wants three facts that survive the install. What may the agent touch? Where does the credential go? Who can change the rules? When those three live behind a vendor's admin console, the deployment topology bought nothing.

Kortix's launch post put the same test in one line: a company that runs on AI should be a codebase you own, not a dashboard you rent and cannot inspect.

The four tests

Run these against any vendor, ours included. Each one produces an artifact you can look at, or a shrug.

Configuration in files you can diff. Ask where an agent's instructions and its reach are written. If the answer is a form in a web console, you cannot review a change, cannot see who widened a grant last month, and cannot rebuild the setup on a second machine. Files in your own repository let a reviewer read the difference before it takes effect.

A credential boundary you can point at. Ask where the API key lives and who can read it. An installation that copies every key into the agent's working environment has moved the exposure, not removed it. A useful answer names the component that holds the value and what happens to a command that tries to print it.

A runtime you can swap. Ask what stays when you leave. A stack that boots from a documented compose file, with images you pull yourself, can be run on another host next quarter. One that exists only inside the vendor's account cannot leave with you.

A data path you can put on your own network. Ask where sessions run, where the control plane runs and where the prompt goes. "On your own servers" should come with a diagram, not a badge. The answer decides whether your security review passes and whether your data-processing terms mean anything.

Running the tests on Kortix

The first test is checkable before you install anything. A project's manifest is kortix.yaml, and in schema version 2 it is governance only: it points at an agent file and lists what that agent may use.

agents:  kortix:    file: agents/kortix.md    connectors: all    secrets: all

Nothing in that block describes behaviour. The prompt, the model and the working style sit in agents/kortix.md, whose description reads "Its access is what kortix.yaml grants it." Change the agent by editing a markdown file; change its reach by editing a grant. Both are diffs in your repository, reviewed like code.

The manifest is also deny-by-default. Leave the connectors, secrets, kortix_permissions or skills grant off a specialist and it resolves to none, so a new agent starts with nothing rather than everything. The starter's own agent is granted broadly on purpose, and the file says so in a comment.

Credential handling is the second test. Connector credentials are brokered server-side and never enter the machine. The agent asks for the call; the service that already holds the credential makes it.

The last two tests are answered by where the stack runs, and that part deserves a careful read rather than a slogan. Kortix gives you three arrangements. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. A self-hosted install is one Docker Compose stack on a Linux server you control, installed and updated by kortix self-host, with the database, API and web app in that stack. Sessions do not run on that server. They run on Platinum sandboxes the platform provisions, which is the split a review should read twice. One isolated sandbox per session. Each session has its own isolated machine and branch.

The work survives as commits too. Only what the agent pushes to its branch is still there tomorrow, which is why the repository is the record and not a transcript.

What self-hosting does not fix

Self-hosting does not move the model onto your hardware. The provider your project connects still receives the prompt, so the data-processing question follows the model, not the server rack. Pick the provider on those terms and write the answer down.

It does not remove operations either. A self-hosted Kortix instance is one Docker Compose stack, and the install needs DNS A/AAAA records for the instance domain and its api host plus a wildcard preview domain, ports 80 and 443 open, an admin email and a Platinum API key (PLATINUM_API_KEY) for kortix self-host configure. The model provider key is a later step, added in the web app after the first sign-in. Sessions run on Platinum sandboxes, not on the server, so the host carries the control plane. The first sign-in also warns about open sign-ups. Close those the same day.

What it does fix is the part buyers usually cannot recover later. The configuration is text in a repository you own, the grants are readable, and the vendor can be replaced without rebuilding the setup from a support ticket. Whether that matters is a business decision. Whether it is true is a fact about the file.