What a self-hosted open source AI agent platform runs on

The machine you are pricing belongs to the model

A self-hosted agent platform is a web application and a database. Ask what it needs and the honest answer is a Linux machine with Docker on it, disk for Postgres, and a URL a sandbox can call back to. Nothing in that sentence involves an accelerator.

The GPU belongs to a different workload that happens to share the words "self-hosting AI". Teams add the two together and budget a rack of cards for a platform that would have run on a laptop. Kortix's self-hosted page keeps them apart: the platform is "One Docker Compose stack, built from the same images the managed cloud runs", and "The same artifact runs on a laptop, a VPS or a cloud VM."

From there the sizing question mostly answers itself. Model access is sold per token by providers who keep their hardware busy. A card you buy is paid for whether an agent is thinking or not. Rent the intelligence, own the records.

What the Compose project contains

The self-hosted page groups the services into three planes, and the list is shorter than the name suggests. The application plane is three services. frontend is the web app you log into. kortix-api is the REST API at /v1, and it relays any /v1/llm request that reaches it to llm-gateway. `llm-gateway` is the standalone LLM gateway, with its own image and memory limit, and it calls the model providers your projects connect. The data plane is Supabase: supabase-db for Postgres, supabase-auth for sign-in, supabase-rest for the query layer, supabase-storage for files, and supabase-kong in front of them as their proxy. Two more finish the work. kortix-migrate applies the schema change on each release, and kortix-updater checks once a day, then starts the new services before it stops the old ones.

The edge plane holds only what you chose: caddy terminating TLS when you point a domain at the box, or cloudflared in tunnel mode. Nothing in that list wants an accelerator, and Postgres is the one service whose appetite grows with use.

What actually makes the box bigger

Kortix publishes the floor: a machine of 2 vCPU and 4 GB, with 4 vCPU and 16 GB for real use (self-hosted page). Take that as the entry point and size above it from the four things that move:

• The Postgres data directory: accounts, projects, session history, policies, the audit record. It grows with time rather than with headcount.
• The storage directory beside it, which grows with the files agents keep.
• The edge, when the box terminates TLS and answers preview hostnames.
• Disk headroom for the updater, because every release pulls a new image set before the old one stops.

Concurrency looks like it belongs on that list, and it is how a model server gets sized. Sessions do not run on your machine. One isolated sandbox per session. Each session has its own isolated machine and branch, and the machine comes from the sandbox provider you configure: Platinum. Your instance routes to it and records what happened. It does not compute. Thousands of agents in parallel on one config, each on its own cloud computer, and the box in the middle stays about the same size.

The machine classes are ordinary, then. A laptop carries a trial. A small VPS carries a team and a cloud VM carries a company, with the same Compose project on all three, which is why the page calls a domain "one environment variable, not a different deployment". Pick the smallest host that holds your data with room to grow, and put the difference into model access.

The model is the only line that could want metal

A model has no fixed price the way a server does. It has a rate per token, and where the tokens come from decides the bill. Kortix's pricing page lists the routes, and only the last one needs hardware.

Managed models run on credits at the provider's base price plus a 5.5% platform fee, with zero data retention at the model provider. Your own key sends usage straight to the provider, where the first $1,000 a month is free before Kortix adds 5%, paid from credits. A connected ChatGPT subscription spends no credits at all. A self-hosted instance carries no managed lineup, so it runs on the two middle rows: your keys, or the subscription you already pay for.

The last row is the one people reach for and rarely need. A card pays off when it stays busy, and agent work arrives in bursts. Between two busy hours sit a queue, a batching decision, a quantisation choice and a driver stack that changes under you. Where the weights must not leave your network, running them yourself is a real reason to own the machine. Where the motive is a cheaper month, a per-token rate usually wins, because you pay for thought instead of uptime.

Four things to have before the first boot

1. A Linux host with Docker and the Compose plugin.
2. A URL a sandbox can reach: a domain pointed at the box, or a Cloudflare tunnel while you evaluate. Sessions call back to the instance, so a tunnel address that changes on restart breaks them.
3. A Platinum API key. The page is blunt about this one: "This is the one credential the stack genuinely cannot start without."
4. An admin email for the first account, optional at install and settable later.

You prepare none of the passwords. The CLI generates every port, internal URL, password and signing key, along with the whole docker-compose.yml and .env, and writes them to one instance directory at mode 0600. The updates that follow pull their images without registry credentials. A GitHub connection and a model key are not asked for at this point on purpose; both are set in the dashboard once the stack is up. Backups are just as plain: "The Postgres data directory, the storage directory, and the .env that holds every key the instance uses." Copy those three and you have copied the instance, with nothing to export from anyone else's account.

One box, and a provider for everything else

Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. The governance travels with the records, wherever the box sits. Session work reaches main through a change request. Merge is default-deny for agents.

The setup walkthrough takes the same four prerequisites through the commands that consume them, the self-hosting decision page weighs the box against the managed cloud, and the pricing page works the credit rates through a few team sizes.