How to Self-host Agent Zero on VPS Safely

Wetin Agent Zero be, and where the danger dey

Agent Zero na open-source, Docker-first agent framework. One primary agent fit spawn subordinate agents to break job into focused parts. The agents fit execute code, control browser, and run shell commands, all inside Agent Zero Docker container. You fit control everything from Web UI. E get plenty capability and e dey genuinely fun to use. E fit run for hardware as small as six-dollar VPS. If na the multi-agent setup you want, instead of the framework itself, two Claude Code sessions for the same box fit message each other directly, and na much smaller thing to run and secure.

The danger dey inside Web UI. Na the control panel for system wey dey run commands and write files. So, if you expose Web UI without authentication, e become remote foothold into that same system. And na here be the trap wey most setup guides dey lead you enter directly: the docker run examples publish the interface without specifying address. As of 2026-10-12, the README direct command maps host port 80 (-p 80:80), the A0 Install launcher dey use port 5080, and the VPS deployment guide recommends 50080. Guides wey cover releases up to v0.9.x line dey use port 50001. Any port wey you choose, mapping wey no specify address go listen on every network interface. For public VPS, this means say the whole internet fit reach am immediately container start. Fix this one first. No wait till the end.

Wetin you need

You need one VPS wey get Docker installed, API key for one language model or local model wey you fit point am to, plus few gigabytes of RAM to start. Agent Zero dey run anywhere wey Docker dey run, from small VPS reach GPU server. If Docker new for you, Docker basics guide explain the things wey the commands below assume.

Install with Docker, bind am to loopback

The documented quick start na one docker run. The important change from the copy-paste version wey you go see elsewhere na the address wey you publish on. No publish am to every interface, the way -p 80:80 dey do. Publish am 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 bind the Web UI to the server loopback address only, so internet no fit reach am. Reach am from your own machine through an SSH tunnel:

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

Then open http://127.0.0.1:5080 locally, configure your model provider for the UI, and set UI login and password under Settings, Authentication. The official docs talk say make you do this before you open the instance to anybody else. For permanent multi-user setup, put am behind VPN or an authenticating reverse proxy instead. But never publish the raw UI to open internet. Make this habit apply to every other tool for the box wey get interface to control sensitive things. Na so self-hosted open-kritt scanner suppose dey reachable too, through tunnel to its UI instead of published port.

Where the other guides dey stop, and why you no suppose stop there

Search for how to install Agent Zero and you go find plenty guides, including ones from hosting companies, wey go take you reach running Web UI for published port (50001 for the older ones, 80, 5080 or 50080 for newer ones) and stop there. Na exactly for that place risk dey start, no be where e end. Two things go complete the work. First, keep the UI private, as we explain above. Second, put default-deny firewall in front of the machine so any service wey you forget no fit answer internet request:

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

But you gats know the limit: Docker dey route traffic for published container ports before UFW rules apply, so the firewall no cover container port wey you publish to every interface. Na why the loopback bind above matter, and how Docker ports dey bypass UFW explain the details. Follow the firewall basics for the complete picture, and remember the IPv6 gap, because service for :: fit reachable through IPv6 even when your IPv4 rules look tight.

Container isolation dey protect agents, e no dey protect your server

Agent Zero design good well for one kind isolation: framework and every agent wey e create dey run inside im Docker container instead of directly for your host. So, code wey dem write and run go enter the container, e no go enter your home directory. This protection dey useful. Subordinate agents dey share that one container with the primary agent. So, the boundary dey between the agents and your host, not between the agents themselves. E easy to read all this as “e dey sandboxed, so I dey safe” and stop there. Container isolation dey keep the agents' work away from the host. E no protect your server from internet, and e no stop exposed Web UI from giving stranger control. Na your responsibility be those things for the host. Decide from the beginning how much work agent fit do when nobody dey monitor am. Na the same kind judgment behind Claude Code permission modes. Unattended server suppose use tighter setting than laptop wey dey in front of you.

Secrets, users, and the host

Keep Agent Zero model API key and any other credentials for Agent Zero config or an environment file wey na only the correct account fit read. No put dem for shell history or any repository. The same rule apply to anything else for the box wey dey protect secrets. For example, hardening pass for Vaultwarden depend on the admin token and backup file, no be the encryption wey the app already dey handle well. Administer the box with unprivileged user instead of root, as least-privilege users explain. Change SSH to key-only authentication, as SSH hardening show. Then follow the checklist below so nothing miss.

If you dey compare agents, na this same security posture OpenClaw hardening guide and the OpenHands guide dey use: keep the control surface private, run with unprivileged user, enable firewall by default, and treat the host as system wey dey run code wey you no write. For side-by-side view of all five agents, see the best self-hosted AI agents for 2026.

The concepts behind all these dey for building your own AI agent on a VPS, and Dify na another self-hostable platform wey worth comparing.

FAQ

Agent Zero safe to self-host?

E safe, if you keep im Web UI private and harden the host. Agent Zero dey run code, browser, and shell, and you dey control am from Web UI for any host port wey you publish. So, na exposed interface be the main danger, no be the framework itself. Bind the UI to loopback and access am through SSH or VPN. Set UI login and password. Put default-deny firewall in front. Run am as unprivileged user.

Agent Zero dey expose Web UI to internet by default?

The documented docker run commands publish the interface without address (README use -p 80:80). Mapping like that dey listen on every network interface. For public VPS, this mean say internet fit reach am as soon as container start. UFW no go stop am because Docker dey route published ports around UFW. Add 127.0.0.1 to the published address so the UI go listen on loopback only. Then access am through SSH tunnel or VPN.

Agent Zero fit run on small VPS?

Yes. Agent Zero fit run anywhere Docker fit run, including small and cheap VPS. But heavier tasks and bigger local models need more memory. If you point am to self-hosted model instead of hosted API, size the box based on the model, not only Agent Zero.

How Agent Zero different from OpenClaw or Hermes?

Dem overlap, but dem get different focus. Agent Zero na Docker-first framework wey dey center around primary agent. This agent dey spawn subordinate agents inside im container, and Web UI dey drive the whole process. OpenClaw and Hermes na personal assistants wey you access through chat apps. Security posture na the same for all of dem: keep the control surface private and harden the host.