Built to hold the keys to your Proxmox clusters
ProxCenter stores the credentials of every cluster it manages. Here is what protects them, what leaves your network, and how to reach us when something is wrong.
Cluster credentials
Built in public, signed, inventoried
Published images come out of our public GitHub Actions workflow, and you can check it.
- Each image carries a build provenance attestation signed with Sigstore and recorded in a public transparency log
- Each release ships a CycloneDX SBOM of the frontend image, attached to the release and attested against its digest
- Third-party actions in the workflow are pinned to a commit
gh attestation verify oci://ghcr.io/adminsyspro/proxcenter-frontend:<version> --owner adminsysproHard to guess, harder to replay
Local accounts, single sign-on and sessions are handled on the server.
- Local passwords hashed with argon2id
- TOTP two-factor authentication with recovery codes, required per user or for every super admin
- LDAP and OIDC single sign-on: Entra ID, Keycloak, Okta, Auth0Enterprise
- Sessions stored server side and revocable, with 12 h idle and 7 day absolute limits
- Optional lockout per account and per IP, and an always-on limit on wrong 2FA codes
Each user sees only their share
Permissions are enforced by the server, not just hidden in the interface.
- Custom roles built from 60 permissionsEnterprise
- Access scoped to a connection, node, VM, tag or poolEnterprise
- Virtual data centers isolate each tenant to its own resourcesEnterprise
- API tokens stored hashed, scoped, expirable, and never broader than their creator
- Audit log of user actions and failed sign-ins, forwarded to syslog or a SIEMEnterprise
Credentials stay encrypted in the database
A copy of the database alone does not reveal your cluster credentials.
- Proxmox credentials, 2FA secrets and API keys encrypted with AES-256-GCM
- The key is derived from a secret generated at install time, kept outside the database
- API tokens are kept as a keyed hash, never in clear
Strict about where it connects
ProxCenter talks to your infrastructure, and checks every address it is asked to reach.
- Outbound requests refuse loopback, link-local and cloud metadata addresses
- The backend re-checks the address at connection time, which defeats DNS rebinding, and never follows redirects
- SSH host keys pinned on first use; a changed key is refused
- The installer serves HTTPS from the start, TLS 1.2 minimum, with ACME certificates available
What we recommend you turn on
Securing the deployment remains the operator’s responsibility.
- Require two-factor authentication, super admins first
- Replace the self-signed certificate, then redirect HTTP to HTTPS and enable HSTS
- Keep the interface off the internet, behind a firewall or a VPN
- Enable the login lockout policy, off by default
- Keep certificate verification on for Proxmox connections, with least-privilege accounts
- Stay on the latest release: only it receives security fixes
No telemetry. No analytics.
The only connections ProxCenter starts on its own:
- Update check, GitHubWhen: Hourly
Sends A plain request, no instance data
Off switch
PROXCENTER_OFFLINE - Template catalog, GitHubWhen: Daily
Sends A plain request
Off switch
TEMPLATE_CATALOG_AUTO_UPDATE=false 
License portal, proxcenter.ioWhen: Daily, only once you connect the instanceSends A signed message: instance ID, version, connection names and node counts, license IDs
Off switchLeave it unconnected
- Google Fontsfonts
- flagcdnflags
- OpenStreetMapmap tiles
The tile provider is configurable.
No internet at all? The air-gapped bundle installs ProxCenter with no outbound connection.
Found a vulnerability?
Please write to us privately rather than opening a public issue.
We acknowledge every report within 48 hours and send an initial assessment within 7 days.
Fixes ship first, then the advisory is published. With your permission, we credit you in the release notes.
Checked on every change
- CodeQL
- SonarCloud
- Semgrep
- golangci-lint
- Trivy
- govulncheck
- gitleaks
- Dependabot