Why run an AI agent on a server (and how to do it safely)
Running Hermes, OpenClaw, T3 Code or Claude Code on an always-on server makes agents more useful and, done right, safer. When it is worth it, which setup fits which harness, and a security checklist.
George Jucan, Founder, Poligon Tech 5 min
Short answer
Run an AI agent on a server when you want it always on: scheduled jobs that run overnight, long tasks that survive closing your laptop, access from your phone, and isolation from your personal files. The agent itself needs little hardware when the model is hosted, so a small VPS or home server is usually enough. Do it safely: a dedicated non-root user, no open inbound ports where possible, container isolation, explicit allowlists, command approvals, and spending limits on API keys.
The first time you use an AI agent, it lives on your laptop. That’s fine for trying things out. But after a while you notice the friction: the long task that dies when you close the lid, the report you wanted every morning that never runs because your laptop was asleep, the agent you can’t reach when you’re away from your desk.
Putting the agent on a server fixes all of that. Done carelessly, it also creates a machine on the internet that can run commands on instruction from a chat message. This guide covers both sides.
Why run an agent on a server
It is always on. Scheduled jobs run at 3am. A two-hour task keeps going after you close your laptop.
You can reach it from anywhere. Through a chat app (Hermes, OpenClaw) or a mobile client (T3 Code), you can start, check and approve work from your phone.
It is isolated from your personal machine. An agent on your laptop can, in principle, reach your browser sessions, SSH keys, documents and password manager. An agent on a dedicated server can reach only what you put there.
It can have more power when needed. Coding agents that build, test and run several tasks in parallel benefit from a machine with more CPU and memory than a laptop.
One place for credentials and logs. API keys, memory, and every action the agent took live on one machine you control, which makes them easier to audit and to revoke.
It is cheap. When the model runs through a hosted API, the agent itself mostly waits on network calls. A small VPS or a spare home machine is usually enough.
When not to bother
- You only use an agent occasionally, interactively, at your desk.
- The work needs your local apps, browser logins or files that shouldn’t leave your machine.
- You aren’t prepared to keep a server updated. An unpatched agent server is worse than none.
Which harness, which setup
Different harnesses are built for different kinds of always-on work. (For a fuller comparison, see AI agent harnesses compared.)
| Harness | What it is on a server | How you reach it | Good for |
|---|---|---|---|
| Hermes Agent | A long-running personal agent with memory, skills and cron | Telegram, Slack, Discord, WhatsApp, Signal and more | Assistants, scheduled reports, monitoring |
| OpenClaw | A gateway daemon connecting an assistant to many chat channels and devices | 20+ chat channels, dashboard | Multi-channel assistants, home and team use |
| T3 Code | A server that runs coding-agent CLIs (Claude Code, Codex, OpenCode…) | Desktop, web and mobile apps | Parallel coding work you follow from anywhere |
| Claude Code / Codex / OpenCode | A coding agent in a terminal session | SSH, or through T3 Code | Long or parallel coding tasks |
Hermes Agent
Install it as a dedicated user, choose a model with hermes setup, switch command execution to the Docker backend, set an allowlist or DM pairing, and install the gateway as a system service. We walk through every step in Hermes Agent: how to run it on a server.
OpenClaw
OpenClaw installs with its own script and an onboarding command that can install its background daemon:
curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon
openclaw gateway statusTwo points from its README matter on a server. First, inbound messages are untrusted input: chat channels that accept direct messages pair unknown senders by default, and you approve them with openclaw pairing approve <channel> <code>. Second, tools run on the host for the main session unless you configure sandboxing. Read its security, exposure and sandboxing guides before connecting other people or exposing the gateway remotely.
T3 Code with Claude Code or Codex
Install your coding-agent CLIs on the server and log in to them there, then install T3 Code and run it as a service:
curl -fsSL https://t3.codes/install.sh | sh
t3 service install
t3 upt3 up lets you choose T3 Connect (a managed tunnel, no open ports) or direct LAN and Tailscale access. Run it as a normal user, not root. Full walkthrough: T3 Code: how to use it.
A bare coding agent over SSH
The simplest version: SSH in, start a tmux session, run Claude Code, Codex or OpenCode inside it, detach, and reattach later. It works, but you lose the comfort of reviewing diffs and approving actions from your phone, which is what tools like T3 Code add.
The security checklist
Whatever harness you choose, these apply:
- A dedicated machine. Not the server that runs your website, database or anything in production.
- A dedicated, non-root user for the agent. Every agent we’ve covered recommends against running as root.
- No open inbound ports if you can avoid them. Messaging gateways connect outwards. For remote UIs, prefer a managed tunnel or a private network such as Tailscale over a public port.
- Container isolation for commands, with CPU, memory and disk limits.
- Explicit allowlists for who can talk to the agent. Never “allow all” on an agent that can run commands.
- Approvals on for dangerous commands, and especially for unattended or scheduled runs.
- Least-privilege credentials. Give the agent its own API keys and accounts, with only the access its tasks need. Read-only wherever possible.
- Spending limits on model API keys, so a runaway loop costs a little, not a lot.
- Secrets files readable only by the agent user (
chmod 600). - Treat pairing codes and links like passwords, and revoke ones you no longer use.
- Update regularly. These projects ship fast, including security fixes.
- Watch the logs for unexpected access attempts and unexpected actions.
For a business
The same reasoning scales up. When we deploy agents for operations teams, they run on infrastructure the client controls, with their own credentials, narrow tools, human approval for anything that matters, and a log of every action. A self-hosted personal agent is a great way to learn how agents behave. A production agent inside an order desk or a finance team needs the same principles, applied more strictly. That’s the work we do, and it starts with a workflow audit.
Frequently asked questions
What is a self-hosted AI agent?
A self-hosted AI agent is agent software that runs on hardware you control, such as a VPS, a home server or an office machine, rather than as a vendor's hosted service. The model can still be a hosted API; what you control is where the agent runs, what it can access, and where its memory and logs are stored.
How powerful does a server need to be to run an AI agent?
If the model runs through a hosted API, very little: the agent mostly waits on network calls. A small VPS is enough for personal agents. Coding agents that run builds and tests need more CPU and memory. You only need a GPU to run the model itself locally.
Is it safe to give an AI agent shell access on a server?
It is safe enough when the access is limited: run the agent as a dedicated non-root user, execute commands in a container with resource limits, keep dangerous-command approvals on, give it only the credentials it needs, and avoid exposing it to the open internet. Never run it on a server that also holds production systems or data it doesn't need.
Should I run Claude Code on a VPS?
It can make sense for long-running or parallel coding work, especially driven from a control surface like T3 Code so you can follow it from your laptop or phone. Keep it on a separate machine from production, use branches or worktrees, and keep permissions supervised for unfamiliar work.