How the installer works
One line installs Proxploy on a Proxmox host or on a plain Debian box. What it builds depends on where you run it, and it is locked down before you ever see a login page.
curl -fsSL https://proxploy.com/install.sh | bashCopy it and paste it into the console on a Proxmox host, the Shell entry in the node’s own menu. It builds the container for you, installs Proxploy inside it, and prints the address to open when it is done.
Where you run it
- On a Proxmox VE node
- Creates an LXC container and installs itself inside it, so Proxploy lives on the node without living in its root filesystem.
- On a plain Debian box
- Installs directly: system packages, a dedicated service user, a verified release unpacked into a versioned directory, and a systemd unit in front of it.
How it is locked down by default
An install is a versioned code drop, never an in-place patch: a dedicated system user, a release tarball whose signature and checksum are verified before it is unpacked, and a symlink swap to make it current. Your data lives outside the release tree entirely, so an update is only ever a code swap.
Caddy is installed in front of it and terminates TLS, with a real certificate where a public hostname is available and a self-signed one otherwise. Proxploy is never left serving plain HTTP. There is no default password either: the first account is yours to create on first visit.
Nothing about the install phones home. The installer fetches the release and its signature and verifies it, and that is the last outbound connection Proxploy makes unless you are on a paid tier, where a license check carries a license key and nothing about your infrastructure.
Connecting your first Proxmox host
Proxploy talks to Proxmox VE through a scoped, minimal-privilege API token that you issue in the Proxmox interface, never a root@pam password. The enrolment flow lets you pick which capabilities to grant — monitoring, lifecycle actions, consoles, backups and node‑power — and generates a token that covers exactly what you selected and nothing more. Every capability is optional; grant only what you need.
Installing, updating and migrating apps is the one thing the API cannot do, because community scripts are shell scripts that run as root on the node. That path uses a dedicated Ed25519 key per host, generated in Proxploy, encrypted at rest, and authorized by you on the node. It is optional: skip it and everything above still works. Grant it and you are granting root on that node, which is the honest cost of the App Store existing at all.
The exact commands for both, and what each privilege is for, are in the getting-started documentation.
Updates
LXC and systemd installs update in place, and every step is reversible until the last one succeeds.
- 01Back up the current install
- 02Download and verify the release signature
- 03Migrate the database
- 04Switch to the new version
- 05Health-check, and roll back on any failure
The actual steps live in the docs
This page covers what the installer does and which shape to pick. The commands themselves, per-shape walkthroughs, and what to do when one of them fails, are documented properly.