What the installer puts on your server

Every file, service, and account the Panelbot agent installer creates, where each lives, what it can reach, and what the uninstaller removes.

You are about to run our installer on a machine that holds your customers’ data. You should know what lands on it before you do, so here is the full list. Everything on this page you can verify yourself with ls about ten seconds after the install finishes.

The short version

One directory under /opt, one systemd service, one system account that cannot log in, and one sudoers file you can read. That is the whole footprint.

The directory

Everything the agent owns lives under /opt/panelbot-agent. Inside it:

PathOwnerWhat it holds
/opt/panelbot-agent/binrootThe helper scripts the agent is allowed to run
/opt/panelbot-agent/releasesroot, agent groupInstalled agent versions, so a bad update has something to fall back to
/opt/panelbot-agent/trustrootThe keys used to verify that a release really came from us
/opt/panelbot-agent/stateagent account, mode 0700Runtime state. Locked to the agent account, unreadable by anyone else
/opt/panelbot-agent/rollbackroot, mode 0700The rollback marker used if an update fails its health check

Note who owns what. The directories holding executable code are owned by root and the agent cannot write to them. The agent only owns its own state. That split is deliberate: a compromised agent process cannot rewrite the code it runs next time.

The service

/etc/systemd/system/panelbot-agent.service, enabled and started by the installer. It runs as the panelbot-agent account, not as root. You can stop it, disable it, or check on it with the same systemctl commands you use for anything else on the box.

The account

A system account and group, both named panelbot-agent, created with useradd --system, with /opt/panelbot-agent as its home and /usr/sbin/nologin as its shell. Nobody logs in as it, including us. It has no password.

The sudoers file

/etc/sudoers.d/panelbot-agent, and an updater drop-in at /etc/sudoers.d/panelbot-agent-updater.

This is the part worth reading carefully, because it is where a support tool would be dishonest if it wanted to be. The agent does not run as root, but some hosting operations genuinely need elevation, such as reading another account’s mail log or restarting a service. Rather than run the whole agent as root, the installer writes a sudoers file listing the specific commands it may run with elevation, and nothing else.

Read that file. It is plain text, it is on your server, and it is the actual boundary rather than a promise about one. If a command is not in it, the agent cannot run that command with elevation, whatever anyone tells it to do.

What it needs from the machine

  • Python 3.9 or newer. Already present on essentially every cPanel or DirectAdmin box.
  • Outbound HTTPS on port 443 to api.panelbot.io. The installer TCP-probes this before it does anything, so a blocked firewall fails immediately with a clear message rather than half-installing.
  • Root access to run the installer itself, which is how it creates the service account and the systemd unit. The agent it installs does not keep that access.

No inbound ports are opened. Nothing listens. The connection is always outbound, from your server to us.

Footprint

The agent is a small Python service. In normal operation it sits idle waiting for work, and it does not index your filesystem, tail your logs continuously, or run scheduled scans of its own. Work happens when a customer conversation asks for it. Disk usage is dominated by the installed release and the previous one kept for rollback.

Uninstalling

Run the uninstaller and it reverses every line above:

  1. Stops and disables panelbot-agent.service, then removes the unit file.
  2. Removes both sudoers drop-ins.
  3. Removes /opt/panelbot-agent and everything under it.
  4. Deletes the panelbot-agent account and group.
  5. Tells Panelbot the server is no longer enrolled.

What it does not touch: your panel, your customers’ accounts, your data, and anything else on the machine. The agent never held any of that; it read from your panel and acted through it.

Verifying any of this yourself

You do not have to take our word for the list. After an install:

ls -la /opt/panelbot-agent
systemctl status panelbot-agent
cat /etc/sudoers.d/panelbot-agent
id panelbot-agent

If what you see does not match this page, tell us, because one of the two is wrong and we want to know which.