What is a self-hosted AI agent platform?

Software for building and running AI agents that you deploy on infrastructure you control — your own cloud account, cluster, or servers — rather than calling a vendor's hosted service. The goal is usually data residency, operational control, or freedom from lock-in. Open-source frameworks and some commercial platforms with a self-host tier both qualify.

What are the best self-hosted alternatives to closed agent platforms?

It depends on how much you want to operate yourself. Open-source frameworks like LangGraph, CrewAI, and AutoGen give you full control and full responsibility. Batteries-included open platforms like Dify and n8n trade some control for speed. Langfuse covers self-hosted observability. Managed platforms with a self-host tier, OBTO among them, aim for ownership without running everything.

Is self-hosting an AI agent platform actually cheaper?

The license is often free; the operation is not. When you self-host you take on scaling, uptime, backups, patching, and secret rotation. For a team with platform engineers that can be a good trade. For a small team, the time spent running the stack can cost more than a managed plan.

Do I have to self-host to avoid vendor lock-in?

No. Portability and self-hosting are different things. What actually prevents lock-in is the ability to export your prompts, tools, traces, and memory, and the freedom to switch model providers. A managed platform that lets you take your work and your model choice with you can be more portable than a self-hosted tool that traps your data in its own schema.

Can OBTO be self-hosted?

OBTO runs as a managed cloud by default, and self-hosting on your own Kubernetes is available on the Enterprise tier, together with bring-your-own-models. On every tier your app is stored as data you can query and export, so ownership does not depend on which way you host.

← All articles Guides

Self-hosting your AI agents: a clear-eyed guide to the alternatives

OBTO Team · Insights from the Glass Box

"Self-hosted" is one of those words that sounds precise and isn't. Ask three teams why they want a self-hosted agent platform and you will get three different answers. One means the agents have to run inside their own network, because a compliance reviewer said so. Another means they refuse to hand a vendor the only copy of their workflows. A third just wants out from under a pricing page that charges per seat for software they intend to run ten thousand times a day.

Those are different problems, and they do not share one answer. Before you shortlist anything, it pays to know which promise you are shopping for, because most "self-hostable" tools are strong on one and quiet about the rest. What follows is a map: what each kind of option is good at, and the tradeoffs the marketing pages skip.

The three things "self-hosted" usually means

Pull the word apart and you find three separable goals hiding inside it:

Data residency. The agent and the data it touches stay on infrastructure you control: your VPC, your cluster, your region. This is normally a hard compliance or security requirement, not a preference.
Operational control. You decide when to upgrade, how to scale, and what to patch. Nothing changes under you because a vendor shipped on a Friday afternoon.
Portability. You can leave. Your prompts, tools, traces, and memory come with you, and you are not welded to one model provider or one company's roadmap. That last freedom is the heart of what we mean by engineering around lock-in.

A tool can deliver one of these and quietly fail the other two. An open-source framework hands you all three, plus the operational weight to match. A polished managed service often gives you none of them by default, but takes the weight away. Knowing which of the three you truly need is most of the decision already made.

The open-source frameworks you run yourself

If maximum control is the goal, the agent frameworks are the honest answer. LangGraph is MIT-licensed and free to deploy on Kubernetes, Docker, or a plain VM; CrewAI and Microsoft's AutoGen are open source too. You get the code, you get to read it, and nothing phones home.

The catch lives in the word "yourself." With the open framework you also own scaling, persistence, secret storage, retries, and the upgrade treadmill. LangChain now sells the managed version of exactly this as LangSmith Deployment, renamed from "LangGraph Platform" in late 2025, precisely because running the open library in production is real work. For a team with platform engineers and a reason to control every layer, that is a fair trade. For a team that just wants an agent shipped this quarter, it is a second job nobody budgeted for.

The batteries-included open platforms

A step up in convenience are the open-source application platforms. Dify gives you a visual builder, RAG, and agent tooling you can run as a free, self-hosted Community Edition. n8n brings four hundred-plus integrations and a workflow canvas that increasingly runs AI steps inline. Both are genuinely self-hostable and genuinely useful.

Read the license before you build a company on one. Dify ships under a source-available license, based on Apache 2.0 with extra conditions that restrict multi-tenant resale without permission. n8n uses the fair-code Sustainable Use License: free to run for your own work, restricted once you want to sell it as a service, with SSO and a few enterprise features held behind a key. None of that is a knock; it is how these projects stay funded. But "open source" and "do whatever you want commercially" are not the same sentence, and the gap can matter a great deal at scale.

Observability is its own decision

Building the agent is half the job. Seeing what it did is the other half, and it is frequently a separate tool with its own self-host story. Langfuse is MIT-licensed and built to self-host; you can have it running under Docker Compose in an afternoon. LangSmith, by contrast, is a proprietary SaaS that offers self-hosting only on its Enterprise plan. If "runs on our infrastructure" is a firm line for you, that one distinction settles the choice. We go deeper on this exact tradeoff in our breakdown of choosing between OBTO, LangSmith, and Langfuse.

The tradeoff nobody puts on the pricing page

Every self-hosted option shares one hidden line item. You are now the operator. Upgrades, uptime, backups, scaling under a spike, rotating the credentials, patching the CVE that landed this morning: that work does not vanish when you self-host. It moves to your team. The framework is free. The pager is not.

This is the real fork. Managed platforms take the operational weight, and too often take your portability with it. Pure open source hands back the control and the weight in one motion. The question worth sitting with: can you get the ownership without signing up to run a small cloud? That narrow gap is where a few newer platforms are trying to live.

What to check before you commit

Whatever lands on your shortlist, the same six questions separate a real alternative from a re-skinned trap:

License fine print. Can you use it commercially, at the scale you actually plan, without a separate agreement?
Data export. Can you get your prompts, tools, traces, and memory out in a usable format today, not after a "contact us"?
Model portability. Are you free to switch model providers, or is the platform quietly a wrapper around one of them?
Observability. Is a real trace of every run included, or is it a second vendor you bolt on later?
Operational load. Who answers the page at 3 a.m.? Be honest about whether that is a team you have.
Pricing shape. Per seat, or per app? Per-seat pricing taxes the exact thing agents are best at, which is running without a human in the chair.

Where OBTO fits, honestly

We will be straight about our spot on this map. OBTO is managed cloud by default: you describe a tool, ship it, and it runs on our infrastructure in minutes, no cluster to stand up. Self-hosting on your own Kubernetes is the Enterprise tier, alongside bring-your-own-models, not every plan. If your one hard requirement is "the binary runs in my VPC, free, on day one," a pure open-source framework will beat us to it, and we would rather you knew that now.

What we optimize for is ownership without the operator tax. Your app is data: the pages, tools, routes, and policies are records you can query and export, not opaque state stuck inside our console.

// in OBTO an app is data -- every page, tool, and route is a record you can export
{ "collection": "pltf_page", "name": "pricing", "app": "ob_www", "domain": "www" }

Every run also leaves a Glass Receipt, an itemized record of models, tokens, cost, and tools, on by default, so observability is not a second product you wire in. Because the platform is model-agnostic, moving from Claude to GPT to an open model is a config change, not a migration. And pricing is per application, not per seat, so an agent that runs ten thousand times a day does not cost you ten thousand logins. The trade is plain: on the lower tiers you do not run the substrate yourself, and in return your work stays portable and your costs stay legible. Whether that beats a self-hosted framework depends entirely on which of the three promises you came for. It is the same conviction behind building OBTO headless-first.

If you would rather see the receipts than read about them, the free Builder tier is enough to ship one real tool and watch a real trace come back.