Everything Proxploy does

The App Store gives the community-scripts catalog a web interface: search and filter hundreds of installers that each build an LXC container and install a service into it. Every install pins the exact script version, shows it diffed against upstream, takes your explicit consent to run it as root, and streams the output to you line by line.

Afterwards the app stays managed rather than forgotten. Update badges appear when upstream ships a new version, and applying one runs the same pin, diff, consent and stream flow.

Virtual machines sit alongside containers rather than in a separate product. Start, stop, reboot, pause and resume any VM, with the noVNC console one click away on the VM's own page.

Snapshots are listed, created, rolled back and deleted from the same place, with the with-RAM option surfaced rather than hidden, because the difference between a snapshot that captures memory state and one that does not is the difference between a clean rollback and a surprise. Creating a VM is a guided flow from an ISO or a template, and existing VMs can be cloned in full or as linked clones.

VM options — the name, on‑boot behaviour, boot order, OS type, QEMU agent and other settings that normally live in Proxmox's config panels — are editable directly in Proxploy, with pending changes shown before they are applied and restricted options flagged so you never edit something the hypervisor will silently ignore.

Nobody starts with an empty Proxmox host. When you connect a host that already has containers on it, Proxploy discovers them and presents them in a separate panel for adoption, rather than pretending they do not exist or demanding you rebuild them through the App Store.

Adoption works one at a time or in bulk, and Proxploy suggests catalog matches where it can recognise what a container is running, so an existing Jellyfin container becomes a managed Jellyfin app rather than an unnamed guest. Nothing is reinstalled and nothing inside the container is modified by adopting it.

Every datastore across every connected host in one view: its type, its capacity, how much of it is used, and its health. When a disk is filling up, you see it before something stops writing.

The content browser goes a level deeper, listing and managing the ISOs, container templates, backup archives and disk images each datastore holds, including uploads. It is the part of Proxmox you usually visit only when something has gone wrong, and it is easier to keep tidy when it is not buried.

Once you run more than one host, moving a container or VM between them becomes something you actually want to do, and it is normally a manual exercise in backup files and restore commands.

Proxploy takes both paths. Where your hosts share a Proxmox cluster, it uses the cluster's native migration. Where they do not, and plenty of homelabs run several standalone nodes, it falls back to a backup-and-restore migration that achieves the same result. In both cases you get an honest downtime estimate before you commit, rather than discovering afterwards how long the guest was unavailable.

Proxploy exposes the full Proxmox VE firewall — rules, aliases, IP sets, options and logs — at every scope the hypervisor supports: cluster-wide, per‑node, per security group, and per guest, both containers and VMs. Every scope gets the same interface, so a rule you learned to write on one guest works the same on another, and the firewall log is one click away instead of buried in a syslog you rarely check.

Rules are ordered with drag‑to‑reorder, aliases and IP sets keep rule lists readable rather than a wall of raw addresses, and the log is filterable by time range so you can answer 'was that blocked or was the service just down' without leaving the interface.

Every state-changing action is written to an append-only audit log: who did it, what they did, which host and guest it touched, and when. Installs record the script hash that was consented to, so the record says what actually ran and not merely that something did.

The audit log is free-tier functionality. Per-client audit and compliance reporting built on top of it is a Team feature, but the underlying record exists for everybody, because a management tool that cannot tell you what it did to your infrastructure is not one you should trust.

Alert rules cover the conditions that actually wake people up: sustained CPU load, disk filling, a node going unreachable, and an app dropping out of its running state.

Delivery goes to ntfy, Telegram, email or a webhook, which between them cover self-hosted push, chat, the inbox and anything you want to automate. This is free-tier functionality, because being told your storage is full is not a premium feature.

Local login with TOTP two-factor authentication is free-tier functionality, because an interface that can destroy containers should not be protected by a password alone regardless of what you paid.

The Team tier adds role-based access control with owner, admin, operator and viewer roles enforced on every API route rather than only hidden in the interface, team-scoped access so a given user sees only the hosts and apps they should, and single sign-on via OIDC against your own identity provider. Scoped API tokens, personal or service, are hashed at rest and individually revocable.

Add as many Proxmox hosts as you run and Proxploy presents them as one system: fleet-wide CPU, memory and storage rings, per-node cards with running-guest counts, and an Apps grid spanning every host with the host shown on each tile.

Installing gains a host picker, so you choose where an app lands from the same dashboard rather than logging into a specific node first. Combined with cross-host migration, the practical effect is that adding a second or third machine stops multiplying the number of browser tabs you keep open.

A live activity feed runs across the whole fleet: installs, lifecycle actions, backups, migrations and alerts, in the order they happened.

Everything the interface does, it does through Proxploy's own REST API, which is documented with OpenAPI and available to you directly. Anything you can click, you can script.

That matters most to people running Proxmox for other people, where onboarding a client or standing up a standard set of services should be a pipeline rather than an afternoon of clicking.