The open-source AI agent stack has matured fast. OpenClaw, AutoGPT, CrewAI, AgentGPT, BabyAGI — every six months a new framework lands, every twelve months a wave of teams rebuild their internal tooling around it. The frameworks themselves are solved problems. The unsolved problem is deployment.
Most teams default to one of two answers, and most teams end up regretting the choice they made.
The three deployment modes
There are roughly three ways to run an open-source AI agent today, and they make completely different trade-offs.
Shared SaaS. You log into someone else’s hosted instance, your prompts and outputs flow through their tenant boundary, and your API keys (if you bring your own) land in their config store. Cheap and instant, but you’ve now signed a tenancy agreement with whoever runs the service. Cross-tenant prompt leakage, shared embedding caches, and unclear data retention policies all compound. For agents touching production data, this is the option that’s hardest to defend in a security review.
Laptop or VPS self-hosting. You spin up your own box, clone the repo, install the runtime, and paste your OpenAI key into a .env file. Maximum control, minimum cost ($5–$20/month VPS), but you’ve now signed up to be a sysadmin. Patching, log rotation, intrusion detection, key rotation, and the occasional 2am OOM crash are all your problem. Operator surveys consistently show roughly 60% of self-hosted agent incidents stem from the host itself rather than the agent runtime.
Per-tenant isolated cloud. Each deployment lands in its own sealed container with no shared state, no shared keys, and no shared network namespace with the next tenant’s instance. You don’t SSH in; you don’t manage the OS; you don’t rotate keys. The provider does that. The cost lands somewhere between SaaS and self-host, and the security posture is the strongest of the three.
The third mode is the one most teams skip past, mostly because it sounds expensive. The numbers say otherwise.
What per-tenant isolation actually buys you
State isolation. A long-running AI agent accumulates state — conversation history, vector embeddings, fine-tuning artifacts, scheduled jobs, partial completions. In a shared SaaS, this state lives in a shared store with logical access controls between tenants. In a self-hosted setup, it lives on a box you didn’t harden. In a per-tenant cloud environment, it lives inside a namespace boundary that physically can’t be reached from another tenant’s runtime. The difference becomes obvious the first time someone asks ‘can you confirm tenant A never touched tenant B’s prompts?’ and you have to either prove a software-level invariant or point at a network-level one. The latter is a much shorter conversation.
Cost. Self-hosting is cheap on paper. The TCO math gets uglier once you include incident time, key rotation effort, and the latency of writing your own observability. A managed per-tenant runtime that bundles compute plus the model API gateway often comes in cheaper per agent-hour than a self-hosted box once you price an engineer’s time at any reasonable rate. A working anchor: if your own time is worth more than $30/hour, self-hosting is more expensive than per-tenant cloud above roughly five hours of monthly babysitting.
Security. Self-hosted agents hold credentials in plaintext for OpenAI, Anthropic, Gemini, and whatever fallback router you’ve added. If the box gets compromised, all of those keys exfiltrate in the first sixty seconds. Per-tenant cloud providers issue scoped credentials per deployment, rotate them automatically, and don’t hand the raw upstream keys to the runtime at all. The blast radius from a single compromised agent shrinks from ‘five vendor accounts’ to ‘one tenant.’
DevOps overhead. Self-hosting an agent isn’t deployment, it’s operating a service. A team running three production agents on three VPS boxes has implicitly committed to maintaining a small fleet of Linux servers, with all the patching, monitoring, and incident-response that implies. Per-tenant cloud collapses that into a click-deploy workflow with no servers to track.
The economics that actually swing the decision
OpenClaw is one of the few managed runtimes that prices the per-tenant model honestly. The standard plan is $89.90 one-time and ships with $90 worth of bundled multi-model API credits drawn from a shared pool — OpenAI, Anthropic, Gemini, plus a couple of lighter routing models. The runtime, the isolated server, and the model gateway are effectively free; you’re prepaying for the API calls you were going to make anyway.
The one-click OpenClaw cloud deployment flow takes about ninety seconds end to end. No SSH, no Dockerfile, no container registry, no Kubernetes manifest. You sign in, pick a region, click deploy, and the agent comes up reachable on a hostname inside its sealed container. The same deployment pattern works for AutoGPT, CrewAI, and most other open-source agent frameworks once you swap the underlying image.
When each mode actually wins
Shared SaaS wins for hobbyist exploration. If you’re running a single agent against synthetic data with no real keys, the convenience tax is fine.
Self-hosting wins for one specific user: the operator who has already hardened their server, runs a single agent, and wants full control over the runtime internals. That operator exists and they’re not the audience for managed cloud.
Per-tenant isolated cloud wins for everyone else — and especially for any team running an open-source agent against production data, customer records, or internal credentials. The threat model is harder to dismiss once the agent starts touching anything you’d hate to see screenshotted on a public forum.
The mode you pick is the deployment story you’ll explain to your security reviewer. Pick the one you can finish that conversation without conceding a point.
— Alex Turner
