Self-hosted vs managed open source agents: who owns the control plane

Two bills hide inside the self-host question

Most comparisons of self-hosted and managed AI agent platforms argue about principle: residency, vendor trust, who holds the keys. Those questions are real. They also miss the line that changes size when you switch. Every option here carries two costs. One is the control plane: accounts, projects, repos, secrets, policies, audit. The other is compute for the agents themselves. Self-host or managed decides who runs the control plane. Compute gets rented either way.

Kortix makes the split visible because it sells only half of it. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free. Sandbox compute does not travel with the control plane. A self-hosted Kortix still runs sessions on a sandbox provider you configure, with a key you supply. That makes a self-hosted deployment mixed by design: the company's records sit on your disk, and the machines your agents work on get billed by someone else. Which is the honest shape of the decision, and it changes what the options in the comparison table are competing on.

What sits on your box, and what never does

Kortix's self-hosted page draws the line item by item. On your box: Postgres as a directory you can back up, and file storage as a second directory beside it. Every project repo and every secret the platform holds stays there, along with accounts, roles, policies, triggers, channels and the audit record. The LLM gateway your sessions route through lives there too. Off the box: agent sandboxes, which run on the provider you configure, and the image registry, which needs no credentials.

A compliance reviewer would read that list as the useful half of the answer. The control plane holds what an audit asks about: who exists, what each person may do, and what happened. Sandboxes hold work in progress, and the good ones get thrown away.

Kortix keeps the throwaway part strict. One isolated sandbox per session. Each session has its own isolated machine and branch. The file one session breaks is not on the next session's disk.

The arithmetic, at published rates

Kortix's pricing page prices the agent computer, not the account. One credit is $0.01. Eleven credits buy one hour of the default machine: 2 vCPU, 4 GB of memory, 20 GB of disk. Billing runs by the second, and a stopped computer costs nothing. The same page prices the parts at $0.0324 per vCPU-hour and $0.0108 per GB-hour of memory.

The rate reconciles once you do the multiplication. Two vCPU at $0.0324 is $0.0648 an hour. Four GB at $0.0108 is $0.0432. Add them and you get $0.108, which is the 11 credits the page quotes, or $0.11 an hour.

Three team sizes, one rate. A solo builder running one agent 40 hours a month spends 40 × 11 = 440 credits, so $4.40. The Free plan's 500 credits a month cover it with 60 to spare. A month where that agent idles costs nothing.

A five-person team at 25 agent hours each spends 5 × 25 × 11 = 1,375 credits, so $13.75. That fits inside the smallest paid tier: $50 a month for 5,000 credits, which is 454 agent-computer hours.

A forty-person company at 20 agent hours each spends 40 × 20 × 11 = 8,800 credits, so $88. The $100 tier carries 10,000 credits, or 909 hours, and the tiers run to $50,000 a month for 5,000,000 credits at the same 100 credits per dollar.

The compute line stays small. Forty people using agents twenty hours a month each cost $88, which is $2.20 a person. Idle hours bill nothing, so the quantity to forecast is hours of real work rather than cores reserved.

The control plane is the other line. On a self-hosted instance the software costs nothing, and the box is your provider's invoice. Kortix publishes its size, a 2 vCPU and 4 GB floor with 4 vCPU and 16 GB for real use, and no price. That price belongs to whoever sells you the machine.

Four things that decide it before price does

A URL the sandbox can reach. Sessions run on a remote sandbox and call back into the control plane, so the installer asks first how the instance is reachable. A VPS with a domain and an api. subdomain is the production answer. A Cloudflare tunnel is the evaluation answer, and its URL changes on every restart. Use it to try the product, not to run on it.

Who holds the keys. On a self-hosted Kortix the gateway lives in your stack, model calls route over your own domain, and Kortix holds no credential in that path. The one credential the stack cannot start without is your sandbox provider's key. Teams that must show an auditor where the model keys live get a straight answer here.

Update cadence and rollback. A self-hosted Kortix updates itself. The updater checks once a day at a time you set, runs the migration, then starts the new services before stopping the old ones. You track a stable channel, the latest channel, or a version you pin. Dify's self-host docs go another way, asking you to compare each release's environment example against yours and re-apply your changes onto the new compose file. Cloudways takes a third, shipping validated releases with daily backups and a restore checkpoint. All three work. Only one of them asks nothing of you on a Friday.

What happens when the sandbox provider changes. Kortix runs sandbox compute on Platinum, with a legacy fallback whose removal is already scheduled. Any deployment whose control plane and compute have different owners carries that risk: one of them can change supplier without asking the other. Isolated topologies, where the compute has to move inside your network too, are scoped with Kortix rather than self-served.

The cost nobody puts in the table

Flowise wound down in 2026. Feature development stopped on 29 July, the repository went to public archive on 10 August, and end of life followed on 31 August. The code stays public and forks are yours to keep, so a self-hosted Flowise does not vanish. It stops receiving releases. The package you installed keeps working until something under it moves.

That is the continuity risk self-hosting genuinely carries, and the vendor comparison pages leave it out. Control of the code is not a supply of patches. A managed option buys the patches and gives up the code. A self-hosted option keeps the code and takes on the question of who maintains it when the maintainer leaves. Ask any self-host candidate which of the two it is, and what the exit looks like.

Where the managed side earns its place

Managed hosting fits a small team with nobody who wants to own a server, a handful of agents, and a preference for backups arriving done. Cloudways sells that in four tiers, Scout through Swarm, with your own model keys passed through and no bundled credits. Dify's cloud plans do something similar for app builders at $590 a workspace a year on the plan their pricing page shows.

Neither is a mistake. Both hide the same compute bill behind a different invoice. Neither lets you move the control plane in later without changing products.

The verdict

Run the two lines separately and most teams should start mixed. Rent everything for the first month, measure real agent hours, then move the control plane onto a box you own when a requirement shows up: residency, an audit, or a provider relationship you would rather not share. Kortix is built for that path. The self-hosted instance and the cloud run the same images on the same release train, and the move is a host switch in a CLI rather than a migration.

The safety machinery that makes either side usable is the same. Session work reaches main through a change request. Merge is default-deny for agents. A person approves the merge or grants the capability that skips it. Approval gates you set. Off until you set them.

The pricing page breakdown works the credit rates through a second time, and the self-hosted setup walkthrough covers the install. Start with the hours your agents actually run. Everything else follows from that number.