Updating Proxploy

Not published yet

Proxploy has no public release, so there is no release channel to update against yet. This page documents the update path as it will work once one exists.

In-app updates (lxc and systemd)

On the lxc and systemd shapes, Proxploy can apply its own updates. GET /meta/update reports the current version, the available version, and whether this shape can self-apply. POST /meta/update launches proxploy-update outside the app’s own systemd cgroup: the updater restarts proxploy.service, and anything running inside that same cgroup would be killed partway through, leaving the symlink swapped and nothing serving.

proxploy-update runs these steps in order, and the order is the point; each step exists to protect the one after it:

1. Backup: the database is backed up before anything is downloaded, so a full disk during download can’t cost you data you already had.
2. Download: fetch the new release’s manifest, signature, and tarball.
3. Verify: check the Ed25519 signature over the manifest and the tarball’s checksum, before unpacking anything. Nothing unverified is ever written into the releases directory.
4. Migrate: run database migrations against the new release’s code, before switching to it. A migration that fails here leaves the old version running, untouched.
5. Switch: move the current symlink to the new release.
6. Health-check: wait for the same readiness signal the app itself uses, not just for the process to start.
7. Roll back automatically: if the health check (or anything from the switch onward) fails, the update rolls back rather than leaving the node on a half-applied version.

A failed update is designed to be a non-event: you should land back on the version you started with, running, with your data intact. Rolling back stops the service first (so the restore isn’t racing a crash-looping process for the same database file), clears any transient systemd start-limit lockout so the service can actually come back up, and restores the pre-update database with the correct file ownership rather than whatever ownership the backup happened to be written with. Only once the service reports healthy again does the rollback consider itself done.

Docker: no self-apply

A Docker install does not use proxploy-update at all. POST /meta/update returns 409 Conflict on that shape; see Installing with Docker for why, and run docker compose pull && docker compose up -d to update instead.