Apps

Proxploy never shows you a raw CT list. Every LXC container it manages is presented as an App, one card with a name, install source, status, and the actions that matter: start, stop, restart, open the app’s own web UI, view its logs, open a console, and inspect the install script that created it.

Lifecycle actions

Start, stop, and restart run against the app’s underlying container directly; there’s no extra confirmation step for these, since none of them destroy anything.

The install script, pinned and diffable

Every App remembers the exact install script that created it, archived as a version at install time. The app’s Config tab shows that pinned script alongside a live diff against whatever the catalog’s upstream script looks like today, computed fresh every time you open it, never cached, so it reflects upstream drift even if that drift happened after your install. If you see a diff there, it means the community-scripts project changed the installer since you ran it, not that anything changed on your node.

The Config tab also offers an Edit mode: you can modify the pinned script and save a new version, or Revert back to the upstream script from the catalog. Each edit creates a new version in the history, and reverting also pins a fresh upstream copy rather than deleting anything: the version history is the record, and nothing is ever lost. An edited script blocks automatic updates on purpose, since there’s no way to know whether the upstream changes are compatible with your edits. Reverting clears that block.

Uninstalling and reconfiguring

An app’s detail page has two more buttons: Uninstall and Reconfigure.

Uninstall has two outcomes, and the choice is the whole point of the confirmation dialog: the default path destroys the container and its disk on PVE, permanently, and asks you to type the app’s name back before it runs. Checking “keep the container” does the opposite instead, Proxploy forgets the app but leaves the container running on PVE, untouched. No confirmation is needed for that path, since nothing is destroyed. Reach for destroy when you’re actually done with the workload, and for keep when you just want Proxploy out of the way.

Reconfigure resizes an app’s CPU cores, memory, and swap, applied to the container immediately, or edits how Proxploy presents it (its name, web port, protocol, path), which never touches PVE at all. Disk size isn’t a field here: growing a container’s disk on PVE is one-way, PVE can’t shrink it back, so it’s deliberately its own decision rather than a quiet field on this form.

Logs: not implemented

The Logs tab’s promise of tailing a container’s own log is a permanent gap, not a bug in progress. Proxploy has no channel today for running a command inside a guest container, only on the host itself, over SSH, for the install/update/migration scripts it already runs. Rather than fake a log feed, the app says so plainly. This is not planned.

Updating an app

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

Update all queues one update job per stale app, each with its own independent outcome; one failure doesn’t block the others.

If an app’s script has been edited, updates are blocked until the script is reverted to the upstream version. The Config tab tells you so plainly.

Migrating an app to another host

An app can be moved to a different Proxmox host through the Migrate dialog. Before anything runs, preflight inspects the source and destination hosts live and reports:

• Which strategy will be used (cluster-native, shared-storage, or vzdump+SFTP)
• Estimated transfer size and downtime
• Any blockers or warnings for that guest-and-host pair

The actual migration runs as a tracked job.

Opening an app’s web UI

The Open button resolves the app’s configured web protocol, port, and path into a full URL and opens it in a new tab. The resolution is server-side so the URL is always correct even if the app’s network configuration changed since the page loaded.

Adopting containers Proxploy didn’t install

If a host already has LXC containers Proxploy didn’t create, the Cluster page’s discovered-CT panel lets you bulk-adopt them into Apps rather than requiring a fresh install. Adopting the same host/container combination twice is refused, and the refusal rejects the whole batch rather than adopting some entries and silently skipping others, so you never end up with a partial result that’s hard to reason about afterward.