Proxion

Proxion

Try it in your browser: https://c2tech-sys.github.io/proxion/ (sample data, no install)

Proxion is a modern, open-source web console for Proxmox VE that overlays the stock UI: daily-driver views for the things you look at all day, vSphere-style object pages for VMs/CTs/nodes, an embedded console and terminal, and deep links back to the stock UI for everything else.

It's a pnpm monorepo: a Vite/React frontend, a Fastify API/proxy server, and a generated Proxmox VE API client. The read-only PVE proxy (/api/pve/*) is permanently write-blocked; the writes Proxion does perform -- guest power actions, rename/notes, snapshots, backup and restore, clone, convert to template, migrate, hardware edits, node reboot/shutdown, storage uploads and deletes, restore, clone, VM creation, migrate, hardware edits, node reboot/shutdown, storage uploads and deletes, console thumbnails and per-user preferences -- each go through their own allow-listed route, checked against your real PVE privileges -- see Feature status below.

Screenshots

Dashboard	VM summary

VM monitor charts	VM hardware

Preferences	Guest action confirmation

Quickstart

Get from nothing to a running Proxion in one docker compose up.

1. Create a read-only PVE user + API token

Run on a Proxmox node as root (or an equivalently privileged user) -- this gives Proxion's live dashboard/task feed just enough to read your cluster, plus console access for the embedded VNC/terminal bridges:

pveum role add ProxionReadOnly -privs "Datastore.Audit,Mapping.Audit,Pool.Audit,SDN.Audit,Sys.Audit,VM.Audit,VM.Console"
pveum user add proxion@pve
pveum aclmod / -user proxion@pve -role ProxionReadOnly
pveum user token add proxion@pve dev --privsep 0

The last command prints the token's secret once -- copy it somewhere safe; you'll paste it into .env as PVE_TOKEN_SECRET below (PVE_TOKEN_ID is proxion@pve!dev). You still sign in to the app itself with your own PVE username/password (Proxion never stores it) -- this token is only for the always-on cluster poller.

2. Get your PVE cert's TLS fingerprint

PVE's default certificate is self-signed, so Proxion pins to it instead of either trusting a real CA or disabling verification:

pvenode cert info
# or: openssl s_client -connect pve.example.local:8006 </dev/null 2>/dev/null \
#       | openssl x509 -fingerprint -sha256 -noout

Copy the Fingerprint (sha256) value into PVE_TLS_FINGERPRINT below.

3. Configure and start

cp .env.example .env
# edit .env: PVE_URL, PVE_TLS_FINGERPRINT, PVE_TOKEN_ID, PVE_TOKEN_SECRET, SESSION_SECRET, ...
cp docker-compose.example.yml docker-compose.yml
docker compose up -d

docker-compose.example.yml pulls the published image (ghcr.io/c2tech-sys/proxion:0.1.0) by default; uncomment the build: . line instead if you'd rather build it locally from this checkout.

Open http:// and sign in with your own PVE username and password.

Try it without a Proxmox host

No cluster handy? Run the UI against static fixtures instead -- no server, no PVE, no Docker:

pnpm install && pnpm demo

Production notes

• Put Proxion behind TLS -- see docs/deploy.md for reverse-proxy config (nginx/Caddy) and the Caddy + Azure DNS kit for a mesh-only deployment with a real Let's Encrypt certificate.
• Set a real SESSION_SECRET (openssl rand -hex 32) -- required in production.
• Review PROXION_COOKIE_SECURE if Proxion itself is served over plain HTTP behind something else that terminates TLS.
• The optional per-node host agent avoids a vncproxy task-log entry for every console thumbnail capture.
• Storage uploads stream through the Proxion container itself, so any reverse proxy in front of it must allow large request bodies (Caddy does by default); see PROXION_UPLOAD_MAX_BYTES below to cap the largest upload this server will forward to PVE.
• After a deploy, a tab left open from before the update shows a banner offering a reload once it notices the server is running a newer build than the tab itself.

Feature status

Reads go through a permanently read-only proxy. The writes this app performs -- guest power actions, rename/notes, snapshot create/delete/rollback, and migrate (below) -- each go through their own allow-listed route, gated on a signed-in session and the matching PVE privilege on that guest. Nothing else here can edit config or otherwise change your cluster -- /api/pve/* itself stays a read-only proxy.