An App Store for Proxmox, powered by community-scripts
The community-scripts project already automates installing hundreds of self-hosted services on Proxmox VE. Proxploy gives that catalog a web interface, shows you what is about to run before it runs, and keeps managing the app afterwards.
Pin, diff, consent, stream
Every install in Proxploy follows the same four steps, in the same order, with no way to skip past the middle two.
Pin
Proxploy stores the exact version of the script it will run, rather than fetching whatever is at the top of the branch the moment you click install. The script that you approve is the script that executes, even if upstream changes a minute later.
Diff
Before anything runs you see the pinned script side by side with the current upstream version. If the community has changed something since Proxploy pinned it, that change is on screen instead of buried in a commit history you were never going to read.
Consent
The install does not start until you explicitly acknowledge that the script runs as root on the node you chose. No dark pattern, no pre-ticked box, and the consent is recorded in the audit log with the script hash you agreed to.
Stream
Output arrives line by line while it runs, the same text you would see in an SSH session, and the whole log is archived with the job. If an install fails at line 200, you can read line 200 instead of guessing.
One app, one container
Proxploy installs one app per LXC container and keeps that boundary. It is the model community-scripts already uses, and it is the reason an app can be backed up, moved, rebuilt or removed without touching anything else you run. When you uninstall an app, what gets destroyed is unambiguous, because it is exactly one container.
A service that internally runs several processes, like Immich with its server, database and machine-learning worker, is still one app and one tile. The split matters to the software, not to you.
What Proxploy does after the install
This is the part that does not exist when you paste a script by hand. The app becomes a tile with a status light and live resource bars, and its own page: open its web UI in a tab, start, stop, restart or shut it down, tail its logs, or drop into a shell. When the upstream project ships a new version, the tile shows an update badge and the update runs through the same pin, diff, consent and stream flow as the install did.
The script Proxploy used is saved with the app and you can edit it, so a service you had to customise stays customised the next time it is rebuilt.
the limits
Two honest limits
Not every script in the catalog can run unattended. Some prompt for choices partway through in a way that has no sensible non-interactive answer. Proxploy marks which scripts it can install cleanly rather than letting you start one that will hang halfway waiting for a keystroke nobody is there to press.
The catalog's categories are also not perfect. Proxploy parses the community-scripts project's own metadata for the catalog itself, but a small category map is maintained on our side to make browsing coherent. It is a gap in the first version, not a permanent design, and the underlying scripts and their sources are always the project's own.