Comparison · vs Self-hosted
Self-hosting makes you the security team.
Self-hosting an agent gives you total control — and makes you the security team. monopea is the hosted-but-governed alternative: gate, vault, isolation, and Swiss storage maintained for you.
The case for self-hosting an AI agent is real and worth stating plainly: your data never leaves hardware you control, you can read and modify every line, there is no vendor between you and your agent, and the software is often free. For some threat models — and some temperaments — that is decisive, and no hosted product honestly beats it on those terms.
The cost is equally real: the moment the agent is yours, so is its security. Patching CVEs the week they drop, keeping the port off the public internet, vetting every skill and dependency, handling credentials the agent process can read, building your own approval and audit layer — 2026 showed at population scale what happens when that burden lands on busy operators. monopea is the other branch: hosted, governed, and honest about the trade.
What are you actually signing up for when you self-host?
Running an autonomous agent yourself means owning four jobs indefinitely: patching (agent frameworks are young and CVEs are frequent — OpenClaw alone disclosed five in 2026), exposure management (roughly 30,000–43,000 self-hosted agent instances were found open to the internet, ~93% unauthenticated), supply-chain vetting (335 malicious skills were found in one community registry), and secrets hygiene on a box where the agent process can read the disk.
None of these is exotic — they are ordinary operations security. That is precisely the problem: they are somebody’s day job, and if you self-host, that somebody is you. The population-level data is unforgiving about how this goes for operators whose actual day job is running a business. An unpatched agent with your credentials is not a private deployment; it is an unattended liability.
- Patching: CVE response time is yours, including weekends
- Exposure: one wrong reverse-proxy rule is a public agent
- Supply chain: every skill and dependency is code you are trusting
- Secrets: config files on disk are readable by the process — and its exploits
What does hosted-but-governed mean?
It means the controls you would have to build yourself are the product. A default-deny approval gate: mutation-capable tool calls become pending proposals, the run blocks until you approve, unknown tools fail closed, and autonomy grants are explicit and auditable. A write-only vault: secrets go in, never come back out — the agent references {{secret:NAME}}, plaintext is substituted only at dispatch and scrubbed from results, so the model never sees the value.
Around that: two-layer tenant isolation (app-level scoping plus Postgres row-level security under runtime-minted tenant JWTs), an Ed25519-signed audit chain over every proposal and dispatch, and platform patching on infrastructure that is not reachable as a port on your network. This is the part of self-hosting nobody actually wants — done as someone’s day job, so it is not yours.
What do you give up — honestly?
Physical custody. Self-hosting keeps your data entirely on your own metal; monopea does not and will not pretend otherwise. Your persistent data is stored in Zurich, Switzerland, and processing runs on EU infrastructure — named jurisdictions with strong data-protection law, but a hosted service nonetheless. If your threat model requires that no third party ever holds your data, self-hosting is the right answer and this comparison is easy.
You also trade unlimited modifiability for a governed surface: you can bring any MCP tool and choose any model — including a Swiss track of Infomaniak-hosted open weights where inference stays in Switzerland — but you are not patching the runtime itself. What softens the custody trade in practice: the vault is envelope-encrypted and write-only even to you, memory is inspectable and revocable, incognito mode runs a turn with no durable writes, and the audit chain is yours to verify.
How should you decide?
Ask one question first: who is your security team? If the honest answer is “a competent person who will patch, isolate, and audit this indefinitely” — you, a technical cofounder, an ops engineer — self-hosting is a legitimate choice, and running it dark (no public exposure, authentication on, skills vetted) makes it a defensible one.
If the honest answer is “nobody, really,” then the choice is not between control and convenience; it is between a governed hosted agent and an ungoverned self-hosted one. In that case the gate, the vault, the isolation, and the audit chain are not features you are buying — they are the job you were never going to do, done properly. That is the trade, stated straight; both branches are respectable once you know which one you are on.
At a glance
| Self-hosted agent | Monopea | |
|---|---|---|
| Data on hardware you control | ||
| Data jurisdiction | Wherever your metal is | Stored in Zurich · processed in the EU |
| Who patches CVEs | You | Monopea |
| Exposure surface | Your ports, your proxy rules | Hosted API, tenant keys, RLS isolation |
| Approval gate | If you build one | Default-deny, built in |
| Unknown tools | Run if installed | Fail closed to review |
| Secrets | Files the process can read | Write-only vault — model never sees values |
| Audit trail | Your logging stack | Ed25519-signed audit chain |
| Modify the runtime itself | ||
| Ongoing cost | Your time and vigilance | Subscription |
Where the difference shows
The security team you were not going to hire
Patching, exposure management, skill vetting, and credential hygiene are the product’s job, not yours. The 2026 exposure data shows exactly what happens when they default to busy operators.
Controls you would otherwise have to build
Default-deny proposals, fail-closed unknown tools, a write-only vault, tenant isolation, and a signed audit chain — the governance layer around the agent, present from the first session rather than on your roadmap.
An honest trade, in a named place
You give up physical custody; you get named jurisdictions — Zurich storage, EU processing, optional Swiss-hosted inference — plus inspectable memory, an incognito mode, and a vault that stays write-only even to you.
FAQ
Monopea vs self-hosting, in short
- Isn’t self-hosting always more private than a hosted agent?
- On physical custody, yes — data on your own metal is a guarantee no hosted service can match, and we do not claim otherwise. In practice, privacy also depends on patching, exposure, and credential hygiene; an unpatched, internet-exposed instance is far less private than a governed hosted tenant.
- What does Monopea do that my self-hosted stack does not?
- Out of the box: a default-deny approval gate with fail-closed unknown tools, a write-only secrets vault substituted only at dispatch, two-layer tenant isolation, an Ed25519-signed audit chain, and platform patching — with data stored in Zurich and processed in the EU. Each is buildable yourself; together they are a security team’s backlog.
- Can I keep some things self-hosted and still use Monopea?
- Yes. monopea connects to tools over MCP, so self-hosted systems you expose as MCP servers become governed abilities — every mutation still passes the proposal gate. You can keep data-heavy systems on your own infrastructure and let the governed agent operate them.
Keep exploring
OpenClaw alternative
OpenClaw proved what autonomous agents can do — and 2026 proved what happens without governance. Monopea is the same class of autonomy with a gate, a vault, and Swiss storage built in.
Monopea vs enterprise agent platforms
Platforms like Dust, Lindy, and Relevance AI sell team workflow automation to IT. Monopea sells governed personal and practice autonomy — self-serve, with residency as architecture.
Monopea vs Claude Code
Claude Code is best-in-class for developers shipping code. Monopea is governance around general-purpose autonomy for operators — and Claude is one of the models you can run inside it.