Self-host Agent Zero on a VPS

What Agent Zero is, and where the danger sits

Agent Zero is an open-source, Docker-first agent framework. A primary agent can spawn subordinate agents, each running in its own isolated Docker container, and each can execute code, drive a browser, and run shell commands. You control the whole thing from a Web UI. It is capable and genuinely fun to use, and it runs on hardware as small as a six-dollar VPS.

The danger is the Web UI. It is the control panel for a system that runs commands and writes files, so an exposed, unauthenticated Web UI is a remote foothold into exactly that. And here is the trap most setup guides walk you straight into: the standard docker run publishes the interface on port 50001 on every network interface, which on a public VPS means it is reachable from the whole internet the moment the container starts. Fixing that is the first thing you should do, not the last.

What you need

You need a VPS with Docker installed, an API key for a language model or a local model to point it at, and a couple of gigabytes of RAM to start. Agent Zero runs wherever Docker runs, from a small VPS up to a GPU server. If Docker is new to you, the Docker basics guide covers what the commands below assume.

Install with Docker, bound to loopback

The documented quick start is a single docker run. The important change from the copy-paste version you will find elsewhere is the address you publish on. Do not publish to every interface on port 50001. Publish to loopback:

docker run -d --name agent-zero \
  -p 127.0.0.1:5080:80 \
  -v a0_usr:/a0/usr \
  agent0ai/agent-zero

-p 127.0.0.1:5080:80 binds the Web UI to the server's loopback address only, so it is not reachable from the internet. Reach it from your own machine over an SSH tunnel:

ssh -L 5080:127.0.0.1:5080 you@your-vps

Then open http://127.0.0.1:5080 locally, and configure your model provider in the UI. For a permanent multi-user setup, put it behind a VPN or an authenticating reverse proxy instead, but never publish the raw UI to the open internet.

Where the other guides stop, and why you should not

Search for how to install Agent Zero and you will find plenty of guides, including ones from hosting companies, that get you to a running Web UI on port 50001 and end there. That is precisely where the risk begins, not where it ends. Two things finish the job. First, keep the UI private, as above. Second, put a default-deny firewall in front of the box so a stray container or a future mistake cannot expose a port you forgot about:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Follow the firewall basics for the full picture, and mind the IPv6 gap, because a service on :: is reachable over IPv6 even when your IPv4 rules look tight.

Container isolation protects the agents, not your server

Agent Zero's design is genuinely good about one kind of isolation: subordinate agents run in separate containers, so they are walled off from each other. That is worth having. But it is easy to read that as "it is sandboxed, so I am safe" and stop there. Container isolation protects the agents from one another. It does nothing to protect your server from the internet, or to stop an exposed Web UI from handing control to a stranger. Those are your job, on the host.

Secrets, users, and the host

Keep the model API key and any other credentials in Agent Zero's config or an environment file that only the right account can read, out of your shell history and out of any repository. Administer the box as an unprivileged user rather than root, per least-privilege users, and move SSH to key-only authentication, as in SSH hardening. Then walk the checklist below so nothing is missed.

If you are comparing agents, this is the same security posture the OpenClaw hardening guide and the OpenHands guide take: keep the control surface private, run as an unprivileged user, firewall by default, and treat the host as one that runs code it did not write.

The concepts underneath any of these are in building your own AI agent on a VPS, and Dify is another self-hostable platform worth comparing.

FAQ

Is Agent Zero safe to self-host?

It is, if you keep its Web UI private and harden the host. Agent Zero runs code, a browser, and a shell, and it is controlled from a Web UI that is published on port 50001 by default, so the danger is an exposed interface, not the framework itself. Bind the UI to loopback and reach it over SSH or a VPN, put a default-deny firewall in front, and run it as an unprivileged user.

Does Agent Zero expose a Web UI to the internet by default?

The standard docker run publishes the interface on port 50001 on every network interface, which on a public VPS means it is reachable from the internet as soon as the container starts. Change the published address to 127.0.0.1 so the UI listens on loopback only, then reach it through an SSH tunnel or a VPN.

Can Agent Zero run on a small VPS?

Yes. Agent Zero runs wherever Docker runs, including a small, inexpensive VPS, though heavier tasks and larger local models want more memory. If you point it at a self-hosted model rather than a hosted API, size the box for the model, not just for Agent Zero.

How is Agent Zero different from OpenClaw or Hermes?

They overlap but aim differently. Agent Zero is a Docker-first framework built around a primary agent that spawns subordinate agents in isolated containers, driven from a Web UI. OpenClaw and Hermes are personal assistants you reach through chat apps. The security posture is the same for all of them: keep the control surface private and harden the host.