AI Agent Hosting: The Real Trade-Off Before You Self-Host

AI agent hosting means running an autonomous software process, one that can browse, call APIs, write files and make decisions in a loop, on infrastructure you control rather than inside a vendor's managed platform. If you're asking whether to self-host, the honest answer is this: it buys you data control and predictable infrastructure cost, and in exchange it hands you an autonomous process with a network connection running unsupervised on your own hardware. That second part gets glossed over constantly, and it shouldn't be.

What does self-hosting an AI agent actually mean?

It means the agent's runtime, memory, and file access live on a machine you own or rent, rather than on a SaaS vendor's servers. You install it, usually as a Docker container, point it at a model API, give it credentials for whatever it needs to touch (your email, your codebase, a browser), and let it run in a loop. The vendor version trades that control for convenience: someone else patches it, someone else's network gets probed if it goes wrong. Self-hosting flips that. You see exactly what it's doing and exactly what it can reach, but you're also the one who finds out if it does something it shouldn't.

What's the real trade-off, in plain terms?

Self-hosting gives you two genuine wins: data never leaves your infrastructure unless you explicitly send it somewhere, and your compute cost is a flat monthly server bill rather than a usage-based platform fee that scales with how hard you use the thing. Those are real and worth having.

The cost is the part people skip past. You now have an autonomous process running on your network, one that can read files, hit internal services, and act on instructions it pulls from the open web, sitting on infrastructure with no vendor security team watching it. If that process is compromised, prompt-injected, or simply misconfigured, it's your network it's misbehaving on, not someone else's. Self-hosting an agent is not like self-hosting a static website. A website waits for requests. An agent goes looking for things to do.

What do these workloads actually have in common?

Product names in this space change every few months, so it's more useful to know the shared shape of the workload than to memorise a list of tools that will be out of date by the time you read this.

• They're memory-hungry, not CPU-hungry. Most of the heavy lifting, the actual reasoning, happens on the model provider's infrastructure via API. Your server just holds conversation state, runs orchestration logic, and juggles browser or tool sessions. That eats RAM fast and rarely touches CPU hard, so specs built for a compute-heavy web app are the wrong shape here.
• They run in Docker. Almost every serious self-hosted agent ships as a container image because the dependency chains (headless browsers, Python or Node runtimes, specific library versions) are painful to manage any other way. Check Docker's install documentation before you assume your host has a compatible setup.
• They need persistent storage for state. Agent memory, task queues, vector stores, logs of what it did and why, all of that has to survive a container restart or you've lost the agent's history every time it crashes.
• They're I/O sensitive on container starts. Slow disk means slow container boots, which matters a lot if your agent restarts frequently or runs as short-lived jobs rather than one long process.
• They call a hosted model through an API key. Almost none of these tools run a large language model locally by default. The agent is an orchestration layer making API calls to OpenAI, Anthropic, or similar. That means your model bill is separate from your server bill, and it's usually the bigger of the two.

How much server do you actually need?

Less CPU than you'd guess, more RAM than you'd guess. A single agent doing moderate work, browsing, calling tools, holding conversation context, will generally run fine on a modest number of vCPUs paired with a healthy chunk of memory, the kind of ratio you'd normally over-provision for a web app. What kills performance isn't the processor. It's running out of RAM when the agent holds a large context window or spins up multiple browser sessions at once, and swap on a slow disk turning every operation into a wait. If you're running more than one agent, or letting one spawn sub-tasks, budget for RAM headroom rather than core count. Docker's own guidance on resource constraints is worth reading before you set memory limits on the container, because an unconstrained agent container will happily eat everything on the box if something goes into a loop.

What's the security posture that actually matters here?

This is the section worth reading twice, because it's where most self-hosted agent setups fail quietly rather than loudly.

Run it on a dedicated machine with nothing sensitive on it. Don't install an agent on the same box that holds your production database, your customer files, or SSH keys to other systems. If the agent is compromised, everything reachable from that machine is at risk. A clean, isolated box with only what the agent needs is the baseline, not the paranoid option.

Use least-privilege API keys with spending caps. Don't hand the agent a full-access model API key with no limit. Set a spending cap on the model provider side so a runaway loop costs you fifty pounds, not five thousand. Scope any third-party API keys (email, calendar, cloud storage) to the narrowest permission set that lets the agent do its actual job.

Think about network egress before you deploy, not after. An agent that can reach the open internet can be told, directly or through content it reads, to send data somewhere it shouldn't. If the agent's job doesn't require open outbound access, restrict it. Firewall rules on the host are cheap insurance.

Assume anything reading the open web can be prompt-injected. If your agent summarises web pages, reads emails, or processes documents from outside sources, treat every piece of that content as untrusted input that could contain instructions aimed at the agent, not at you. This isn't theoretical, it's the standard attack shape against these tools. An agent can reach whatever its host can reach, so the host's blast radius is the agent's blast radius. For the wider principles behind this, our piece on web hosting security and what actually protects your site covers the fundamentals that still apply once you've added an autonomous process to the mix. Our security section has more on hardening the host itself.

VPS, dedicated, or something else?

For most people, a VPS is the right starting point. It's cheap enough to isolate per-agent (one VPS, one agent, no shared blast radius), and you can resize RAM without a hardware swap if the agent turns out hungrier than expected. Shared hosting is off the table entirely, since it won't run Docker and won't give you the isolation an autonomous process needs. Dedicated servers make sense once you're running several agents at real scale or need guaranteed resources that a noisy neighbour on a VPS host can't disturb, but that's a later problem for most setups, not a starting one. If you're comfortable with hardware and want full control over the network the agent sits on, self-hosting on your own box at home is also viable. Our guide to hosting your own web server at home covers the groundwork, though for anything customer-facing or business-critical a proper VPS is the more sensible default.

Which tools actually fit this pattern?

OpenClaw is a self-hosted, open-source AI agent, previously known as Clawdbot and then Moltbot before settling on its current name. It runs as a Docker deployment and fits the exact pattern described above: memory-hungry, needs persistent state, calls a hosted model via API key. If you're evaluating hosts for it specifically, our OpenClaw hosting guide walks through the practical requirements.

n8n is a workflow automation tool that has added AI nodes, letting you build agent-like chains (trigger, call a model, act on the result, loop) without writing an agent from scratch. It's a different starting point to a purpose-built agent framework, more visual, more workflow-shaped, but it runs on the same infrastructure logic: Docker, persistent storage, an external model API call. See our n8n hosting guide for the specifics.

Where does the money actually go?

The server is the small number. A VPS sized properly for a single agent is a modest, predictable monthly line item, the kind of cost that barely moves whether the agent is idle or moderately busy. The token bill is the number that surprises people, because it scales with usage in a way server costs don't. An agent that browses ten pages to answer a question, holds a long conversation history, or runs continuously rather than on-demand can rack up model API charges that dwarf the hosting fee within the first month. Before you commit to self-hosting for cost reasons, model your expected token usage against the provider's own pricing page. The infrastructure was never where the money was going.

Frequently asked questions

Do I need a GPU to self-host an AI agent?

No, not for the common case. Most self-hosted agents are orchestration layers that call a hosted model over an API rather than running inference locally, so the workload is memory and I/O bound, not GPU bound. You'd only need a GPU if you're deliberately running a local open-weight model instead of calling a hosted API, which is a different and heavier project.

Can I run an AI agent on a cheap shared host?

No. Shared hosting doesn't give you Docker support, root access, or the process isolation an autonomous agent needs, and most shared hosting terms of service aren't written with long-running background processes in mind. A basic VPS is the realistic entry point.

Is it safe to give an agent access to my email or files?

Only with scoped, least-privilege credentials and a clear sense of what the agent can and can't reach from its host. Full-access credentials on a general-purpose machine are how a single prompt injection turns into a real incident. Isolate the machine, scope the keys, and assume anything the agent reads from the web is untrusted.

How do I stop an agent from running up a huge model bill?

Set a spending cap directly on the model provider account the agent's API key belongs to, not just a budget alert you might miss. Also cap the agent's own retry and loop logic where the tool allows it, since a stuck loop calling the model repeatedly is the most common cause of an unexpectedly large bill.

Should you self-host

Self-host if you actually need the data control or want to stop a usage fee that's growing faster than your server bill ever would, and you're willing to treat the box it runs on as a genuine security boundary, not an afterthought. Skip it if you don't have the time to isolate the machine, scope the credentials, and cap the spending, because an unmanaged agent is a worse outcome than an expensive managed one. Start with a single isolated VPS, a capped API key, and one agent doing one job. Expand once you've watched it behave.