Updating an app

Updating an installed app

When the catalog entry behind an installed app has moved to a newer upstream commit since you installed it, Proxploy marks that app as having an update available. Updating re-runs the community-scripts install script, now pinned to the current upstream commit, over the same SSH connection an install uses, with the same diff-against-upstream and consent step you saw the first time. Nothing about the update path is a separate, less-scrutinized flow; it’s the install flow, run again.

Proxploy checks that the app’s container still exists before running the update, and that the update doesn’t leave a second container behind; but it can’t see whether the community script itself decided to treat a given run as an update or as a fresh install; that decision happens inside the script.

Updating everything at once

“Update all” queues one update job per app that has an update available, each with its own independent outcome; if one app’s update fails or is skipped, it doesn’t block or fail the others.

This is a separate thing from updating Proxploy itself, which replaces Proxploy’s own code, not an installed app’s.