Self-Hosted AI Agent 101: What You Actually Need

"Self-hosted AI agent" sounds like it should mean running your own model. For a coding agent like Claude Code, it almost never does; the model still runs on Anthropic's infrastructure. What you are actually self-hosting is the environment: the process that holds your session, your repository, your credentials, and your MCP servers, running on compute you control instead of a managed product that runs it for you. That distinction matters because it tells you exactly what you are signing up to own, and this guide walks through each piece.

What you take on when you self-host

A managed cloud agent product, such as Claude Code on the web, quietly handles four things on your behalf: it gives the session somewhere to run, keeps it alive between your visits, makes it reachable from wherever you open your browser, and tells you (or at least itself) when something has gone wrong. Self-hosting does not remove any of those four jobs; it just moves ownership of them from the provider to you.

• Compute. A machine that actually runs the process.
• Persistence. The session survives a dropped connection, a crash, or a reboot.
• Reachability. You can get back into that session from another device, without a static IP.
• Monitoring. Something tells you when the agent has actually stalled, instead of you finding out hours later.

None of these four are unique to AI agents. They are the same four jobs anyone running a long-lived process on their own hardware has always had, from a personal IRC bouncer to a home media server. What makes a coding agent different is only that the sessions tend to be long (an overnight refactor, a multi-hour loop) and that losing one mid-run genuinely costs you work, not just a dropped chat.

Compute: a box that is actually yours

The two realistic options are a machine you already own sitting somewhere in your house (most commonly a Mac mini, because it idles efficiently and can run headless on a shelf) or a small VPS rented from a cloud provider for a few dollars a month. Neither needs to be powerful: the agent CLI itself is a modest Node.js process, and the actual resource draw comes from what you ask it to do (compiling, testing, building) rather than from the agent sitting there waiting for your next prompt.

If you want the specifics for either path, we cover them separately: our Mac mini server guide walks through the macOS-specific settings (power, FileVault, launchd), and our guide to Claude Code in the cloud compares Anthropic's own cloud sessions against renting a VPS yourself. For exact sizing, see our AI agent hosting requirements guide.

Persistence: surviving a disconnect, a crash, and a reboot

"Persistence" is really two separate problems that get conflated. The first is a dropped connection: your SSH session or laptop closes, but the process you started should keep running. A terminal multiplexer like tmux or screen solves this; the process runs inside a detachable session, so closing your terminal does not touch it, and you reattach later from any device to find the exact same running session.

The second problem is the process itself dying, whether from a crash, an out-of-memory kill, or the machine rebooting for an OS update. tmux does not solve this: if the process inside the pane dies, tmux just shows you an empty pane. That is the job of a process supervisor, launchd on macOS or systemd on Linux, configured to restart the process automatically and, in the systemd case, start it again on boot.

Reachability: getting back in without a static IP

Most home internet connections, and plenty of cheap VPS plans, hand out a dynamic IP address that can change without warning, which breaks a hardcoded SSH target. Two common fixes solve this cleanly: dynamic DNS republishes your current public IP under a stable hostname whenever it changes, and a mesh VPN such as Tailscale or WireGuard assigns the box a private address that stays constant regardless of your ISP, reachable from any device also on that mesh without opening a port on your router. The VPN route is generally the safer default, because it never exposes SSH to the open internet at all.

Monitoring: a stalled session looks identical to a working one

This is the piece people skip until it bites them. A hung process, a crashed pane, and a healthy long-running session can all look the same from a glance at a green terminal prompt, especially from your phone. A heartbeat, or dead man's switch, closes that gap: something pings you (Slack, email, a push notification) on a schedule, or specifically when the agent or the box itself has gone quiet for longer than expected. Without it, the honest failure mode is that you find out your overnight run died only when you sit down the next morning.

Self-hosted vs. managed cloud: the real trade-off

Neither side is strictly better. If you would rather not think about a server at all, the managed cloud option is the right default. If you need your own MCP servers, your own credentials wired in, or work that touches files outside any single repository, self-hosting is the only path that gets you there, and the four requirements above are the full cost of entry.

A minimal self-hosted setup, in practice

Stripped to the essentials, a working self-hosted setup is: one box (owned or rented), one SSH key, tmux new -s work before you start the agent, a launchd or systemd unit so the process restarts on its own, a mesh VPN so you can always reach it, and something simple that pings you if it goes quiet. Everything past that (auto-resume on a usage wall, credential isolation, multi-box fleet visibility) is refinement on top of the same four jobs, not a different set of problems.

For the phone-specific side of reaching a self-hosted session, see Claude Code on your phone. For the full comparison of every way to run Claude Code away from your desk, including Anthropic's own cloud, see running Claude Code remotely.

Frequently asked questions