Self-hosted AI agent platforms: what you actually control

The answer, and the layer most shortlists skip

n8n — the platform most people land on first when they search this — is not open source. It ships under the Sustainable Use License, which permits use for internal business purposes and restricts hosting or reselling it as a service (LICENSE.md). A self-hosted AI agent platform is an orchestration layer you run on your own infrastructure — the graph engine, the tool sandbox, the queue, the logs. The model call is still a vendor API. So the question is not which platform, but which of those four layers you are actually taking back.

Most teams take back three of four and call it self-hosted. That is a defensible choice. It is not the same as running your own stack, and the difference shows up on the invoice and in your data-flow diagram.

Layer 1 is the only one with a hard cost floor you cannot engineer away. Layers 2 through 4 are software you can run on a $40/month box until volume forces otherwise — in n8n's case that means a Postgres database for execution history and, in queue mode, a Redis instance for the job queue (scaling docs). If your reason for self-hosting is "we cannot send customer data to a third-party model provider," moving layers 2–4 in-house does not solve it. The prompts still cross the boundary. If your reason is that you need audit logs of every tool call and the retry logic in git, layers 2–4 solve it completely, and you can keep buying inference.

Name your reason before you name your platform.

The disappointing self-hosting projects are almost always teams that self-hosted the orchestrator to fix a problem living at the model layer.

What each project's license actually permits

Licenses on this list are not decoration. Three of the most-recommended self-hostable agent platforms are source-available with commercial restrictions, and the restriction is specifically the thing a software company wants to do: embed it in a product and charge for it.

Read the actual file, not a blog post about it. "Open source" in a comparison table is frequently doing the work of "you can download the code," which is a different claim — the Open Source Initiative's ten-clause definition requires no restriction on fields of endeavour, which is exactly the clause these licenses add (OSD). If you are building something you intend to sell — and if you are unclear on what that even means when the product is an agent, I wrote about the two senses of AI SaaS — a source-available core is a rebuild you have scheduled without knowing it.

The token bill does not go away

Self-hosting the orchestrator changes your hosting cost. It does not change your inference cost by a single token, because the tokens are still going to a vendor.

Price the shape first. A lead-research agent reads a company page, checks two data sources, drafts an outreach angle. Roughly 25 model turns per run. Context grows as the transcript accumulates, so call it ~12,000 input tokens per turn and ~800 output. Two thousand runs a month.

That shape is 300,000 input tokens and 20,000 output tokens per run, so 600 million input and 40 million output tokens a month. Input dominates by 15 to 1, which is why prompt caching and transcript trimming move the bill more than output limits do.

Move the model picker. That spread between the frontier model and the cheap one is the single largest cost variable in an agent system, and it dwarfs the difference between a $40 VPS and a managed control plane. It is also the argument against self-hosting weights at low volume: a GPU is a fixed cost you pay whether the agent runs or not, and 2,000 runs at 25 turns is 50,000 model calls spread over a 730-hour month — about 68 calls an hour, which leaves a dedicated accelerator idle for most of every hour.

The volume where self-hosted open weights beats per-token pricing depends on your utilisation curve, your model choice, and whether you can keep a batching server like vLLM saturated. Measure it. Do not assume it.

Where these break in production

Unbounded loops. An agent that can call itself, retry, or spawn subtasks will eventually run until something stops it — the failure OWASP catalogues as LLM10:2025 Unbounded Consumption (OWASP GenAI). The cap belongs in the orchestrator: a step cap and a wall-clock cap, enforced outside the model. For the 25-turn shape above, a 40-step ceiling and a 10-minute timeout leave normal runs untouched and stop a runaway inside one billing cycle. A model instructed to stop after ten steps is a request, not a limit. This is the first thing I would build, and it is the whole subject of your first agent, with hard caps.

Context growth. Cost per turn rises through a run as the transcript accumulates. A 40-turn agent is not four times a 10-turn agent. It is worse, because the later turns carry more input tokens. Summarise or truncate on a schedule you chose.

Prompt injection into tool calls. OWASP ranks prompt injection first — LLM01:2025 — in its Top 10 for LLM Applications and lists excessive agency at LLM06:2025, meaning an agent holding more permission than its task requires (OWASP GenAI). A self-hosted agent with a browser tool reads attacker-controlled text all day, into the same context window as your instructions.

Lost state on restart. Most agent frameworks hold run state in process memory. Redeploy mid-run and the run is gone — or worse, half-applied: the email sent, the CRM not updated. This is why a durable execution engine like Temporal keeps showing up underneath agent stacks: it persists an event-sourced history of every step and replays it after a crash or deploy (durable execution docs). Retry and checkpoint semantics are a solved problem in workflow engineering and an unsolved one in most agent frameworks.

Credential blast radius. One service account with write access to everything is how a bounded mistake becomes an unbounded one. Scope per tool.

None of these are exotic. All of them are cheaper to prevent than to debug, and the ways agentic systems break in marketing work are the same five wearing different clothes.

What I would not use

I would not build a product on a source-available core. n8n Community and Dify are good software, and both restrict hosting for third parties. If your plan involves customers running your thing, that plan contains a legal review and a migration you have not scheduled yet. Use the permissive options — LangGraph (MIT), Letta (Apache-2.0), Temporal (MIT), vLLM (Apache-2.0) — or accept that you are building internal tooling and stop pretending otherwise.

I would not run production agents on a drag-and-drop canvas. Visual builders are genuinely faster for the first version. Then you need to review a change, and there is no diff. You need to know why last Tuesday's run behaved differently, and the answer lives in a JSON blob nobody can read. You need two environments; the canvas has one. Agent logic is code. Code belongs in git, with a reviewer and a rollback. I have taken products from zero to $15M ARR and from $50K to $1.5M ARR, and the pattern held both times: the thing you cannot diff is the thing that breaks silently.

I would not self-host the model as the first move. Ollama on a laptop is the right way to develop; it is not a serving strategy. Self-host weights when you have a measured reason — data residency, a fine-tune you own, sustained utilisation high enough to beat per-token pricing — and not because it feels more self-hosted. GPU capacity planning is a full job. You already have one.

The stack I would reach for, running agents in production for the zero-human company I am building in public: permissively licensed orchestration in code, a durable execution layer under it, vendor inference at the model layer until the numbers say otherwise, and tools behind the Model Context Protocol — open-sourced by Anthropic in November 2024 — so the same tool server works against a hosted model today and a local one later (modelcontextprotocol.io).

Match the architecture to your actual reason

The middle rows are the expensive ones. If you are in the top or bottom rows, self-hosting is a weekend of Docker Compose and a decision about where the logs go.

The sandbox is the part almost everyone under-builds

An agent that can run code needs somewhere to run it that is not your application server. A container is a start, not an answer. Shared kernel, shared risk. gVisor intercepts syscalls in a user-space kernel written in Go, so the container never talks to the host kernel directly (repo); Firecracker gives you a microVM with hardware-level isolation per run. Its specification commits to ≤ 125 ms from the InstanceStart API call to the guest’s /sbin/init, and ≤ 5 MiB of VMM memory overhead for a 1-vCPU, 128 MiB microVM — workload-dependent, and enforced by CI (SPECIFICATION.md). At any plausible rate of agent runs, that start-up cost is noise next to the model call.

Then close the network. Default-deny egress, with an allowlist per tool — specific hostnames on port 443, not a CIDR block that happens to contain the internet. This is the control that turns a prompt injection from an incident into a log line: the injected instruction to POST your environment variables to an attacker's endpoint fails at the firewall regardless of what the model decided to do. Set it at the sandbox, not in the prompt.

One more, and it is the one I would not ship without: every tool call logged with its arguments, before execution, to an append-only store the agent cannot write to. Not the model's summary of what it did. The actual call, the actual arguments, the actual response, timestamped, with a retention window you set deliberately rather than inherit. When something goes wrong at 3am on a run you did not watch, that log is the entire difference between a fix and a shrug.