Updates & versioning

Updating a self-hosted Proliferate is one command on the server, and your users' desktop apps follow automatically; you never coordinate a separate desktop rollout.

Update the server

Run ./update.sh from your deploy directory (the extracted proliferate-deploy bundle you deployed from). Under the hood it runs the sequence:

The script also re-checks that generated secrets exist, refreshes the runtime binaries on the host under /opt/proliferate/bin when the cloud sandboxes add-on's runtime-binary variables are set, and health-checks the stack before it exits, so a completed run means the new version is actually serving.

To confirm the version after an update:

curl -s https://proliferate.company.com/meta

Version pinning: a release tag vs stable

The server image is ghcr.io/proliferate-ai/proliferate-server, published with per-release version tags and a stable tag. You choose which one you track with PROLIFERATE_SERVER_IMAGE_TAG in .env.static:

• Pin a release tag (for example 0.3.0) for change-controlled environments. update.sh then only moves you when you edit the tag, so an update is an explicit, reviewable change.
• Track stable to pick up releases whenever you run update.sh, with no file edits.

Releases are published on GitHub as server-vX.Y.Z, and the deploy bundle (proliferate-deploy.tar.gz) is attached to each release. The support intent is N releases back: staying a few releases behind is fine, and update.sh is the one operator motion that catches everything up.

How desktops stay in lockstep

The server you run is the version root for the whole fleet:

• GET /meta on your server reports serverVersion, desktopVersion, runtimeVersion, and minDesktopVersion. Each server release is stamped with the desktop and runtime versions it shipped with.
• Connected desktop apps check GET /desktop/updater/latest.json on your server, which responds with a 302 redirect to the official CDN update manifest for the version your server pins. When the manifest for that exact version is not published (a server built ahead of a desktop release, or a release that predates versioned manifests), the server redirects to the latest stable manifest instead, so update checks always land on a valid manifest. Your server carries only a version number; it never builds or serves desktop binaries.
• The desktop app verifies every update against the signing key baked into the official build, no matter which endpoint served the manifest. A server can choose which version desktops run, but it can never ship a modified build.
• minDesktopVersion is the compatibility floor: desktops older than it are told to update before they can keep working against your server.

The net effect: when you run update.sh, your users' apps converge on the matching desktop version on their own.

Data retention & backups

All persistent state lives in named Docker volumes on the host: the Postgres data volume (everything about your orgs, users, and sessions), Caddy's certificate volumes, and the small first-run setup-state volume. That means:

• Back up Postgres, with pg_dump or a volume snapshot, on whatever schedule your org requires. Taking a backup before running update.sh is cheap insurance, since migrations move the schema forward.
• Data is kept until you delete it. The server does not yet ship automated retention windows for session data; scheduled purging is on the roadmap. If you have a hard retention requirement today, get in touch.
• Telemetry is separate from retention and is covered in Telemetry & privacy.