CLI Reference

Panopticon CLI Reference

Panopticon includes a command-line interface that lets you manage it entirely from a shell — no web browser required. This is the right tool for scripted deployments (Ansible, Puppet, Chef), CI/CD pipelines that provision or reconfigure Panopticon automatically, and day-to-day administrative tasks that are simply easier to script than to click through. It is also the only way to install Panopticon when web access to the server isn't available.

Invoking the CLI

php cli/panopticon.php <command> [options] [arguments]

The php binary must be the CLI binary, not the CGI or FastCGI variant. If you're unsure which one you have, run php -v and check that the first line says (cli), not (cgi-fcgi). See CLI setup for details.

Commands follow a namespace:verb pattern. For example: site:add, user:list, config:set. To see every available command:

php cli/panopticon.php list

To see detailed help for a specific command, including all its options and arguments:

php cli/panopticon.php help <command>

For example: php cli/panopticon.php help site:add

Output formats

Many listing and query commands accept a --format option. The default is always table, which produces a human-readable ASCII table. Other values:

Format	Description
table	Human-readable ASCII table (default)
json	JSON array — pipe to jq or other tools
yaml	YAML output
csv	Comma-separated values — suitable for spreadsheets or further processing
count	Prints a single integer (the number of results) — useful in scripts

For example, to get a machine-readable list of all sites:

php cli/panopticon.php site:list --format json

Exit codes

The CLI follows the standard UNIX convention: exit code 0 means success, any non-zero value means an error occurred. This makes it straightforward to check for failures in shell scripts with if, &&, or ||.

Conventions

Numeric IDs. Sites, users, tasks, and other objects are identified internally by numeric IDs. Most commands that operate on a specific object take its ID as an argument. Use the corresponding list command to find the ID you need — site:list, user:list, task:list, and so on.

Interactive vs. non-interactive. Some commands prompt you for missing values when run without all required options — user:add and group:add are the main examples. This is convenient when running commands manually, but it breaks automation. To use these commands non-interactively in a script, supply every required option on the command line.

Long-running commands. Several commands wrap background task callbacks and loop until the task completes, printing progress to stdout as they go. You don't need to poll or wait manually — just let the command run.

Pausing task processing. task:pause and task:unpause stop and resume all background task processing across the whole installation. Use this when you need to perform maintenance (database imports, file restores, configuration changes) without Panopticon's background workers interfering.

Command namespaces

Namespace	What it does	Reference
config:*	Read and write Panopticon's system configuration	CLI config
database:*	Install and back up the database	CLI config
site:*	Add, configure, and operate the sites Panopticon manages	CLI site
user:*	Manage Panopticon user accounts	CLI user and group
group:*	Manage Panopticon user groups	CLI user and group
task:*	Inspect and manage background tasks	CLI task and schedules
backup:schedule:*	Manage Akeeba Backup schedules	CLI task and schedules
scanner:schedule:*	Manage PHP File Change Scanner schedules	CLI task and schedules
mailtemplate:*	Export and customise email templates	CLI maintenance
selfupdate:*	Update Panopticon itself	CLI maintenance
log:*	Rotate log files	CLI maintenance

The config:* and database:* namespaces are documented together on CLI config because they cover the same concern: getting Panopticon's own installation into a known state. The rest are each on their own page.