Installing Proxploy

Not published yet

Proxploy has no public release yet. The commands on this page and the pages under it will not fetch, verify, or install anything until a release ships. This section documents the install path as it will work once one exists.

What installing does to a node

An install is a versioned code drop, never an in-place patch. install.sh creates a dedicated system user, lays out /opt/proxploy/releases/<version>/ with its own Python virtual environment, fetches a release tarball, verifies its signature and checksum, unpacks it, and points /opt/proxploy/current at it with a symlink swap. Application data (the SQLite database, the master encryption key, uploads) lives outside the release tree entirely, under /var/lib/proxploy/, so every future update is only ever a code swap, never a data migration in place. On the lxc and systemd shapes, Caddy is installed alongside and put in front with a real certificate where a public hostname is available, and a self-signed one otherwise; Proxploy is never left serving plain HTTP.

The three shapes

lxc: a dedicated LXC container on a Proxmox host. The one-liner detects a Proxmox node automatically (it looks for pct and /etc/pve) and, on that path, creates the container and re-runs itself inside it. See Installing in an LXC container.

systemd: a plain Debian 12 host or VM that is not itself a Proxmox node: a separate management box, a VM elsewhere on the network, or a Raspberry Pi. Pass --shape systemd explicitly. Everything else (layout, release verification, the systemd unit, Caddy) is identical to the lxc shape; the only difference is that nothing creates a container for you first.

docker: a container image plus a compose file, for anyone who already runs their infrastructure through Docker Compose. See Installing with Docker. The tradeoff: a Docker install never applies its own updates (below), so pick this shape only if you are comfortable running docker compose pull && docker compose up -d yourself when a new version ships.

Which to pick

• Managing the Proxmox host you are installing onto: use lxc (the one-liner picks this for you on a Proxmox node, no flag needed).
• Managing Proxmox from somewhere else, or you don’t want Proxploy sharing the Proxmox host’s resource pool: use systemd on a separate Debian box.
• Already standardized on Docker Compose for everything you self-host: use docker, and see Updating Proxploy for how updates differ on that shape.