Guides

Managed vs self-hosted AI agents: how to choose

When you decide to run an AI agent like Hermes or OpenClaw, you have three real options: a fully managed cloud service that handles everything for you, a plain VPS where you manage every layer, or an optimised-VPS middle path — a managed server with you in control of the agent. There is no universally correct answer; the right choice depends on your time, budget, technical confidence, and data requirements.

Trade-offs at a glance

DimensionManagedSelf-hosted
Time to deploy~30 seconds30–120 minutes
Ongoing maintenanceNone — handled for youOS patches, updates, logs
Data ownershipProvider holds dataFull — your hardware, your logs
Cost (compute)Bundled in plan priceRaw VPS cost — often cheaper at scale
Automatic updatesYes — zero downtimeManual — you decide when
BackupsDaily — includedYou set up cron + storage
Uptime SLAMonitored + alert on failureYou configure monitoring
Vendor lock-inTied to the platformNone — migrate any time
Custom infra / integrationsLimited to platform featuresFull flexibility
HTTPS + domainAuto-provisionedYou configure Caddy / Nginx / Certbot

indicates the stronger option for that dimension. “Tie” rows have no icon.

When managed hosting wins

Choose a fully managed agent deployment when you need to move fast and do not want to spend time on Linux administration. A managed service provisions a dedicated VPS, installs the agent, configures HTTPS and DNS, sets up daily backups, and monitors uptime — all in the time it takes to enter a credit card number.

Managed is also the right choice for non-technical founders, solo operators running production workloads, or anyone who prefers paying a modest premium to reclaim that operational time.

Good fit for managed:

  • You want to be live in under a minute
  • You do not have a dedicated DevOps engineer
  • Downtime directly costs you revenue
  • You want automatic updates without breaking changes

When self-hosting wins

Self-hosting makes sense when data sovereignty is non-negotiable — for example, if you operate in a regulated industry or process sensitive user conversations that must stay on your infrastructure. It also pays off when you are running at scale, because raw VPS compute is significantly cheaper than managed tiers at high volume.

If you want to fork the agent, run a custom model, or deeply integrate with internal tooling, the self-hosted path gives you full flexibility. You maintain it, but you own it completely.

Good fit for self-hosted:

  • You have Linux / DevOps skills in-house
  • Data must never leave your own servers
  • You need deep customisation of the agent
  • Cost at scale is a primary concern

The middle path: optimised self-managed VPS

AgentOcean offers a third option: a pre-optimised cloud VPS (security hardened, monitoring included, SSH access open) where you install and run the agent yourself. You get the performance and control of self-hosting with the convenience of a properly configured base server. Backups and server-level monitoring are managed; the agent layer is yours.

This is the best of both worlds for teams that have light DevOps capacity but still want root access and no platform lock-in.

What self-hosting actually costs: a measured example

Most comparisons of this kind, including the sections above, argue from generalities — “you maintain it”, “operational overhead”. Here are real numbers instead. We recently installed thirteen software stacks — agents, databases, WordPress, n8n, the coding CLIs — on roughly thirty disposable cloud VMs, driving the whole path from provisioning to TLS to a live LLM completion, and recorded everything that broke.

The part that surprises people: the servers were nearly free

Thirty short-lived VMs cost $0.54 in total. Infrastructure is not what self-hosting costs you. Every real cost is in the failures — and in the hours between hitting one and understanding it.

The simple installs were genuinely fine

This deserves saying plainly, because it argues against paying anyone for management: installing Node, Python, Docker, or the Claude Code and Codex CLIs on a clean Ubuntu box worked first time, every time. If that is the whole of your requirement, self-hosting is not hard and you should not let anyone tell you otherwise.

The trouble starts where components meet

Everything that cost us real time sat at a boundary rather than inside a package. A reverse proxy already owning port 80, so the container could never bind it. DNS answering “no such host” for another thirty minutes after the record went live, because a single premature lookup had been negatively cached. Two official images of the same application disagreeing about which user id owns the files. An agent that installed perfectly and could not answer a single prompt, because the API key behind it had hit a spend cap.

WordPress alone took five separate fixes, each one only visible after the previous was solved — the kind of sequence where an evening disappears and the site still is not up. None of these are exotic. They are what self-hosting is, once you get past the install command.

The one worth taking seriously

One failure produced no error at all. Docker writes firewall rules that are evaluated before UFW's, so a database container published in the ordinary way is reachable from the public internet even though ufw status reports the port denied. We measured a PostgreSQL port going from unreachable to open the moment the container started, with no firewall rule changed and nothing logged anywhere.

A careful self-hoster who set up UFW correctly, checked it, and saw the port denied would still have been running an internet-facing database. That is the category that matters — not the failures that shout at you, but the one that quietly leaves your data exposed and never mentions it. The VPS security guide has the measurement and the fix.

How to read this

We ship these same stacks, so we hit each of these once and fixed them for everyone on our platform. A self-hoster meets them fresh, in their own evening, usually while trying to do something else. That is the honest shape of the trade: not that self-hosting is hard, but that the difficulty is unevenly distributed and lands without warning. If your stack is a runtime and a CLI, that risk is small. If it is a database, a proxy, TLS and an agent talking to a paid API, it is not.

Quick decision guide

Can you spend 1–2 hours on setup and maintenance?

No → Managed Yes → Self-hosted

Is data sovereignty a hard requirement?

No → Managed Yes → Self-hosted

Are you running at significant scale (>10 agents)?

No → Managed Yes → Consider self-hosted for cost

Do you need a custom agent fork or private model?

No → Managed Yes → Self-hosted

Try both — no lock-in

Start with a managed plan for speed, or pick a VPS and self-host with our step-by-step guides. AgentOcean supports both models.

Related