What the installer puts on your server

This page only applies if you chose to install the optional server agent. By default Panelbot connects over the panel API and nothing at all lands on your server.

If 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 with a small tmpfiles.d entry, one system account that cannot log in, four sudoers drop-ins you can read, one weekly cron file, and, on a server running CSF, one outbound firewall rule. That is the whole footprint, and each piece is listed below.

The directory

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

Path	Owner	What it holds
`/opt/panelbot-agent/bin`	root	The helper scripts the agent is allowed to run
`/opt/panelbot-agent/releases`	root, agent group	Installed agent versions, so a bad update has something to fall back to
`/opt/panelbot-agent/trust`	root	The keys used to verify that a release really came from us
`/opt/panelbot-agent/state`	agent account, mode 0700	Runtime state. Locked to the agent account, unreadable by anyone else
`/opt/panelbot-agent/rollback`	root, mode 0700	The rollback marker used if an update fails its health check
`/opt/panelbot-agent/tmp`	root, mode 0711	Temporary files for the helper scripts, kept here instead of `/tmp` so the system’s temp cleaner cannot delete them mid-run

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.

Alongside it the installer writes /etc/tmpfiles.d/panelbot-agent.conf, two lines that stop the system’s temp cleaner from deleting the service’s private temp directory while it runs. Some distributions, CloudLinux 9 among them, would otherwise clean it out from under the service.

The cron file

/etc/cron.d/panelbot-wp-cli, one weekly line run as root that keeps the agent’s fallback copy of the WordPress command-line tool current (it downloads a fresh one only when the copy is more than 90 days old). When that fallback is used on a customer account, a copy is placed in a .panelbot-agent folder in that account’s home directory.

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 files

Four drop-ins under /etc/sudoers.d/:

panelbot-agent, the main allow-list of commands the agent may run with elevation.
panelbot-agent-updater, which lets the agent call the root-owned helper that validates and replaces the main allow-list when the catalog changes, and nothing else.
panelbot-agent-updater-agent, which lets the agent call the root-owned helper that verifies and swaps in a new agent release, and nothing else.
panelbot-agent-uninstall-self, which lets the agent run the uninstaller when you remove it from your dashboard.

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 your Panelbot dashboard address, the one in the install command. The installer TCP-probes this before it does anything, so a blocked firewall fails immediately with a clear message rather than half-installing.
Outbound access to the message bus port, a TLS-encrypted connection the agent receives its work on (port 6379 by default; the server tells the installer the exact host and port when it enrolls). The installer tests it during install and, if it is blocked, prints the exact host and port to open; the agent still installs and reports over HTTPS until you open it.
On a server running CSF, the installer opens that bus connection for you: it appends one scoped, permanent outbound rule to /etc/csf/csf.allow (only the bus host and port, marked with the comment panelbot-agent bus egress) and reloads CSF. No other firewall is changed.
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 (or choose Uninstall agent on your Servers page, which runs it for you) and it reverses everything above except the CSF rule:

Tells Panelbot the server is no longer enrolled.
Stops and disables panelbot-agent.service, then removes the unit file and /etc/tmpfiles.d/panelbot-agent.conf.
Removes all four sudoers drop-ins.
Removes /etc/cron.d/panelbot-wp-cli and the .panelbot-agent copies in account home directories.
Removes /opt/panelbot-agent and everything under it.
Deletes the panelbot-agent account and group.

What it does not remove: the outbound rule in /etc/csf/csf.allow on a CSF server. It is scoped to the bus host and port only, but if you want it gone, delete the line ending in # panelbot-agent bus egress (scoped, permanent) from /etc/csf/csf.allow and run csf -r.

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
ls -la /etc/sudoers.d/ | grep panelbot
cat /etc/sudoers.d/panelbot-agent
cat /etc/cron.d/panelbot-wp-cli /etc/tmpfiles.d/panelbot-agent.conf
grep panelbot-agent /etc/csf/csf.allow
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.