Managed Hosting vs Self-Hosting an AI Agent on a VPS

An AI agent needs three things running at the same time: the harness that runs its logic, the model it calls out to, and the state that remembers what it's doing. Hosting an agent means keeping all three alive together, not answering requests one at a time. That's a different job from hosting a model, and it's why the usual price comparisons for AI hosting miss the point entirely. The real question isn't server cost. It's who ends up doing the work of keeping a stateful, tool-using process alive day after day, including the 2am parts, and most people get that math wrong by an order of magnitude.

Model hosting platforms like SageMaker, Hugging Face Endpoints, and Vertex AI serve predictions on demand. Each call is stateless: send a prompt, get a response, forget everything. Agent hosting is a different animal. An agent using tools, holding a conversation, tracking progress on a multi-step task, needs its history, its files, its credentials, all still sitting there the next time it wakes up. Products like OpenClaw, Hermes, and Claude Code share this property, even though they get deployed in different ways. Three real paths exist for keeping that process alive: a self-hosted VPS, serverless functions, and a managed agent runtime. Only one of them actually fits how agents behave, and it isn't either of the first two. People pick those anyway, usually for reasons that have nothing to do with what the agent needs.

What self-hosting on a VPS actually requires, before the agent does anything useful

Self-hosting means the operator owns every layer: installing the agent, running setup, patching the OS, configuring API keys, locking down the server, watching uptime, managing backups, scaling resources when load picks up. Nobody does this for the operator. That's the deal, and most people signing up for a $20 VPS don't realize they've signed up for that whole list too.

For a single agent, the typical stack is Docker running on a VPS costing $20 to $50 a month, through a provider like DigitalOcean, Hetzner, or AWS Lightsail. Multi-agent production setups tend to move to Kubernetes on AWS or GCP, which raises the bar considerably. On hardware, most agents get by fine with 2 vCPUs and 4 GB of RAM, since model inference happens on external APIs rather than on the VPS itself. The VPS mostly carries Docker, messaging integrations, and browser automation, and that last piece is the hungry one: browser automation alone tends to need at least 8 GB of RAM.

A persistent agent process is closer to hosting a database than hosting a website. It needs storage that survives a reboot, state that survives a crash, and a process supervisor watching over it long-term, not just an HTTP handler answering requests as they land.

Installation is a single task, done once. Running an agent is a recurring job: rotating model credentials, keeping channel gateways connected, securing remote access, upgrading dependencies, figuring out what broke overnight. Shared hosting is out of the question here, and not by a small margin: process time limits, other tenants competing for the same resources, no root access, no way to install custom software. None of that works for a process meant to run continuously.

A VPS is the floor for this kind of work, not the ceiling. Dedicated resources, root access, and a stable background process are the bare minimum to attempt this at all. They don't make the job easy, they just make it possible, and plenty of people find that out the hard way, three weeks in.

The operational jobs that don't appear on the server bill

Security isn't a box checked once during setup. It's a recurring schedule, and skipping a cycle is how instances end up exposed. The OS and the container runtime both need patching on an ongoing basis. Running as non-root, turning on authentication, using Docker for isolation: each of these is its own configuration task, not a default that comes free.

Credential exposure is a known risk with self-hosted agent instances. A dedicated VPS with an inbound firewall set to deny by default is the standard recommendation, not something that ships out of the box. This isn't abstract risk. A Linux kernel bug tracked as CVE-2023-2163 scored a full 10.0, critical, under Google's own CNA assessment, and a runc container-escape flaw, CVE-2024-21626, scored 8.6, high. For an agent executing LLM-generated or otherwise untrusted code, these aren't numbers on a chart somewhere. They describe a real path from a compromised container to a compromised host. Getting to something closer to production-grade hardening adds its own setup time and its own maintenance load on top of everything already listed.

Monitoring has its own quiet failure mode. A cron job that stops firing doesn't send an alert by default. On a self-managed host, silent failure is the normal case, not the exception, and the operator only finds out once something downstream breaks. A crash or a restart wipes whatever state was sitting in memory, and getting that context back is a manual job. Nothing does it automatically.

Every incident routes to whoever's on call: a failed restart, an expired credential, a gateway that quietly disconnected, a disk that filled up while nobody was watching. Containers sharing a host also share a kernel, so one kernel vulnerability can, in principle, reach across every workload on that node. Control over the environment is not the same thing as isolation from what runs next to it.

Put a number on the time and the real cost gets clear fast. At an operator's hourly rate of $100, and DevOps eating 8 hours a month, that's $800 a month in opportunity cost, something like 27 times the sticker price of managed hosting at the low end. Most stories that end with "tried to run an agent, gave up" don't start at installation. They start weeks later, at the first silent failure or the first security scare nobody caught in time.

Why serverless functions don't solve the stateful agent problem either

Serverless platforms like AWS Lambda, Google Cloud Run, and Azure Functions are stateless by design, and they run on a clock. Both choices cut directly against how agents behave: long sessions, dependence on memory, steps that build on each other over time.

The execution ceilings come straight from the vendors, not from outside guesswork. AWS Lambda caps standard functions at 15 minutes of runtime, though Durable Functions, introduced in December 2025, can now stretch a workflow out to a year. Google Cloud Run and second-generation Cloud Functions default to 5 minutes, extendable to a 60-minute cap. Azure Functions, when triggered over HTTP, hits a wall at 230 seconds no matter what timeout gets configured, because the platform's own load balancer times out idle connections at that point.

When an agent outlives its execution window, it doesn't just disconnect and pick back up later. It loses its place entirely, unless the developer already built extra machinery to checkpoint state somewhere outside the function itself.

The isolation serverless offers is real, worth saying plainly. AWS Lambda runs workloads on Firecracker micro-VMs, and Blaxel has reported resume times under 25 milliseconds from a warm standby snapshot, against the mid-hundreds of milliseconds a standard Docker container takes to start cold. That's a genuine advantage. It just doesn't touch the statelessness problem at all.

Making serverless behave like a stateful agent needs a durability layer bolted on top: external storage, checkpointing, some way to reconstruct where the process left off. That's exactly the engineering complexity serverless was supposed to remove in the first place. It's cheap while idle and well-isolated when running, but it isn't a simpler version of a VPS. It's a different set of trade-offs that happens to look simpler from a distance, and that gap is where a lot of serverless agent projects quietly stall out.

What the self-hosted path looks like when it's working well, and what it still costs

On June 28, 2026, Pieter Levels (levelsio) posted a thread, viewed roughly 1.2 million times by mid-July, describing nearly a year of coding entirely on a VPS with Claude Code. The stack: Hetzner, SSH, Tailscale, Cloudflare Tunnels, an inbound firewall set to deny by default. Over that year, he reported two outages, each lasting around 10 seconds. He ran solo on production, with a team working on staging. Agents kept working overnight on standing instructions, and because the code already lived on production infrastructure, finished work went live immediately, no separate deploy step. No laptop stayed open. No battery drained overnight. The VPS is what actually owns the persistent runtime.

This case proves self-hosting works, at a high level of competence, and that's exactly the catch. Levels runs a deliberately hardened, deliberately minimal stack, and he clearly knows what he owns and what he doesn't. Look at what the stack actually requires, though: SSH access configured correctly, a firewall set up on purpose, Tailscale wired in for secure remote access, Cloudflare Tunnels layered on top. None of that comes standard. All of it is labor someone has to do once and then keep doing forever.

Claude Code shipped self-hosted runners in version 2.1.224, on August 7, 2026. The claude self-hosted-runner command lets a Claude Code session run its tool execution on infrastructure the operator owns, while orchestration stays on Anthropic's control plane. It's available on Team and Enterprise plans, and it adds real capability, but it also adds another layer of configuration that belongs to the operator, not the vendor.

Self-hosting only makes sense under a narrow set of conditions: real DevOps capacity already sitting there, a team that wants control over every layer on purpose, a hard requirement around data sovereignty or private-network access, and someone credible actually taking the on-call shift. For most people building a product rather than running a personal setup, at least one of those is missing, which is the whole argument against defaulting to a VPS, and it's a stronger argument than most people give it credit for. The honest test is simple: can the workflow keep running while the laptop is closed, and if it breaks at 3am, who fixes it? If the answer is "my server and me," self-hosting is at least being honest about the price of that answer.

What managed hosting actually delegates, and what it doesn't

Managed agent platforms take on infrastructure provisioning, OS patches, container orchestration, uptime monitoring, restart-on-failure, TLS, often billing controls too. That's the whole list of recurring jobs from two sections ago, handed off to someone else.

What managed hosting doesn't remove: provider rate limits, internet outages, a model API going down, policy constraints, the work of configuring integrations correctly. That layer sits above the infrastructure and stays with whoever's building the product, managed or not, and pretending otherwise is how teams get surprised later.

The clearest way to see the split is Hermes against FlyHermes. Hermes Agent runs self-hosted, on a laptop, a dedicated machine, a Docker host, or a VPS, the operator's choice. FlyHermes is the hosted version: a Hermes workspace running on someone else's infrastructure, with model access and tooling handled for the user. A buyer on FlyHermes never touches a VPS, never wires up separate model accounts, never exposes a dashboard, never maintains a gateway process.

That's a real transfer of accountability, worth being precise about: the operator of a managed service owns the hosted layer underneath. The buyer still owns whatever gets configured on top of it. Not everything moves, just the part that used to eat a founder's week, which, for most founders, is the part that actually matters.

For a solo founder, or a small team without deep infrastructure experience, self-hosting friction tends to be exactly where projects stall out. Managed hosting moves that stall point somewhere else, toward product decisions, which is a far better place for a founder's time to go.

Claude Platform on AWS reached general availability in May 2026, and Claude Managed Agents launched on it in public beta around the same window, with scheduled deployments and vault credentials arriving alongside the Fable 5 release on June 9. Managed hosting for coding agents is now a real, shipped tier, not a side experiment somebody's still testing.

Per-user agent isolation: why the unit of scale matters when you're building a product, not just running one agent

Running a single agent for personal use is a solved problem, and it's been solved for a while now. Running one agent per customer, provisioned automatically, secured automatically, recovered automatically, as the customer count climbs into the hundreds, is the actual hard version of this problem. It's also the version most self-hosted setups quietly fail, and this is where the whole VPS argument falls apart.

At scale, the self-hosted path forks into two bad options, and neither one is a real choice. Either customers share an instance, which is a data isolation failure waiting to happen, or each customer gets a dedicated VPS or container, which multiplies provisioning, credential management, and recovery work by the number of customers on the books. Neither path gets cheaper as the business grows. Both get more expensive, per customer, every single time, which is the opposite of what a growing product needs.

The right unit of scale for an agent-driven product is one isolated, persistent agent per customer, spun up automatically the moment someone signs up, not hand-configured by a founder at 11pm because a new customer just paid. The isolation requirement is a hard line, not a soft goal: one agent's failure, one agent's data breach, one agent burning through tokens out of control, none of it should touch any other customer's agent. That has to be a property baked into the design, not something caught later by a monitoring dashboard.

This is where the isolation technology underneath actually matters. gVisor sandboxing offers a meaningfully different level of kernel isolation than a standard Docker container, for agents running code that might be untrusted or LLM-generated. Each sandbox gets its own filesystem and its own disk quota, and tenants genuinely cannot see each other's data.

The architecture that answers this cleanly is a managed Cloud API model: one API call provisions a sandbox for one customer. That sandbox holds onto files, memory, and connected tools across as many sessions as the customer needs, until it's explicitly deleted. That's not a convenience feature. It's the actual structural answer to a provisioning problem self-hosting can't solve at any scale worth building toward.

Platforms that support managed agent deployment: what they offer and where they differ

Dashboard-based instances run from a Basic tier at $3.99 a month (bring-your-own-key, 1 vCPU, 4 GB RAM) up through a Max tier at $99.99 a month (4 vCPU, 16 GB RAM, team roles built in). On the Cloud API side, there's no subscription fee at all: a prepaid balance covers compute metered by the minute while a sandbox is actually running, plus disk metered until it's deleted, starting at $1.99 per agent per month.

On the Basic plan, users bring their own API keys, which pass straight from the container to the model provider with nothing in between. Users can also authenticate through an existing ChatGPT subscription. Claude subscription authentication is a different story: Anthropic's terms prohibit it, so it isn't supported here. Move up to Plus and above, and bundled free models come with it, GPT-5.6 Luna, DeepSeek V4 Flash, Mercury 2, each with usage limits on a rolling 5-hour window plus a weekly cap on top.

On security, the platform holds SOC 2 Type II certification, enforces gVisor sandboxing, and encrypts data both in transit and at rest. Prompts, files, and terminal sessions aren't collected, and none of it trains any model. Every request comes in through Cloudflare's edge over TLS. Integrations cover Gmail, Slack, WhatsApp, GitHub, Google Calendar, and thousands of other apps through Composio, in one click.

FlyHermes takes the managed path for Hermes specifically: a hosted workspace, supported model API access, tooling infrastructure, the core channels (Telegram, Slack, WhatsApp, Discord, web chat), persistent memory, scheduled jobs, and a monthly usage allowance. Nobody buying into it needs to spin up a VPS, wire in separate model accounts, expose a dashboard, or babysit a gateway process. That doesn't stretch to unlimited model usage, every possible custom integration, or immunity from a provider's own outages, so current plan limits and supported surfaces are worth checking directly before committing.

Relevance AI, LangChain Cloud, and n8n Cloud all sit in the broader managed category too, positioned more as general agent and workflow platforms than as per-user sandbox infrastructure specifically. Pricing and feature scope on these move fast enough that they're worth checking directly rather than trusting a snapshot from an article.

On the model-provider side, Anthropic's own Claude Managed Agents reached general availability across the Claude API and Claude Platform on AWS between May and June 2026, with scheduled deployments and vault credentials included. Self-hosted runners exist as a separate option layered on top, for teams that want orchestration to stay with Anthropic while tool execution runs on infrastructure they control themselves.