Command line
ProxDock is administered through its web interface. The binary's command line is deliberately small: it covers the things you do on the host, before there is a UI to reach or when you cannot reach it, and nothing you would do every day.
There is no proxdock deploy, no proxdock backup, no proxdock migrate.
Those are operations on cluster state, they go through the API so they are
replicated and audited, and the UI is how you reach them.
Subcommands
This is the whole list.
| Command | What it does |
|---|---|
proxdock serve |
Run the node service. This is what the systemd unit invokes; you should not need to run it by hand |
proxdock recovery-password |
Mint a single-use login for this node. Root only, this node only, fifteen minutes |
proxdock version |
Print the version and the commit it was built from |
proxdock help |
The usage banner |
Three more exist for the Debian package's own use during install. They are stable, but they are plumbing rather than an interface:
| Command | What it does |
|---|---|
proxdock addrs |
Print this node's management addresses, one per line. The postinst uses it for the web UI banner |
proxdock configured |
Print yes/no and exit 0/1 depending on whether node setup has completed |
proxdock resync |
Wipe the local replica and Raft state so the node comes up blank and is re-seeded by the leader |
Flags
proxdock serve -config PATH # default /etc/proxdock/config.yml
proxdock recovery-password -config PATH
proxdock recovery-password -initial # install-time: longer validity, quiet
PROXDOCK_DATA_DIR overrides the state directory, which is what you want for
running a second instance locally during development.
Getting back in
If you are locked out of the web UI, this is the way in. Run it as root, on the host itself.
proxdock recovery-password
It prints one password. Sign in with an empty username and that password. It is good once, on that node only, for fifteen minutes.
Scripting against ProxDock
Use the HTTP API rather than the binary. Every node serves the whole API, reads
come from the local replica and writes are forwarded to the leader, so any node
is a valid endpoint. resync aside, nothing above will change cluster state
for you.
To be written: the API reference. Until it exists, the browser's network panel against the UI is an honest guide, since the UI is an ordinary client of the same API.