ProxMorph repaints Proxmox with 24 themes that survive product updates

Themes that live in the native selector instead of overriding it

ProxMorph provides custom themes for Proxmox VE, Proxmox Backup Server and Proxmox Datacenter Manager, and the first thing the feature list says is that the themes appear in the built-in Color Theme dropdown for all three products.

That is the design decision that makes this different from a stylesheet you drop into a directory. The native integration means a user picks a theme from the same dialog everyone already knows, the choice is stored by Proxmox itself, and there is no separate configuration to teach your team.

The other headline features explain the rest of the work. Auto-patch on updates means the themes are automatically re-applied after product updates, which matters because Proxmox upgrades replace the files the theme patches. The hybrid engine is CSS for styling plus JavaScript for dynamic chart patching, which is what a static stylesheet cannot do to a live chart. A server-side default theme can be picked for browsers that have not chosen one, with a user's own selection always winning.

There are opt-in entries per collection for automatic light and dark, described as following the system colour scheme live, and they are noted as available on PVE and PBS. A custom UI font can be applied on top of any theme, from an installed system font or from an embedded WOFF2 or TTF, with the icon fonts left untouched, also on PVE and PBS.

One optional feature is genuinely beyond theming. Hardware sensor monitoring adds optional CPU and storage temperatures, fan speeds and UPS status to the node Summary dashboard on PVE, which is a plugin rather than a colour scheme.

The primary language is CSS, the default branch is main, and the repository is not archived with the last push on 2026-10-16.

Twenty four themes across ten collections

The theme catalogue is where the project's personality shows, and the README is clear about both the count and the structure.

There are 24 themes across 10 collections on PVE, PBS and PDM, with a full gallery linked in THEMES.md. The collections are:

| Collection | Themes | |------------|--------| | Catppuccin | Mocha, Mocha Teal, Macchiato, Frappé, Latte | | Dracula | Classic, Midnight, Pink, Cyan, Green, Orange | | Nord | Dark, Light | | Gruvbox | Dark, Light | | Solarized | Dark, Light | | Tokyo Night | Single theme | | UniFi | Dark, Light, OLED | | GitHub Dark | Single theme | | Blue Slate | Single theme | | ESXi Light (by [@rufftruffles](https://github.com/rufftruffles)) | Single theme (PVE and PBS with bundled Clarity City fonts; PDM palette only, untested) |

The featured ones, with the descriptions the README gives, are UniFi, inspired by the Ubiquiti UniFi Network Application, Dracula as classic Dracula dark with a purple accent, Catppuccin Mocha as the darkest Catppuccin flavor with deep warm tones, and Nord Dark as an arctic dark palette with a polar blue accent. The screenshot in the README compares the default Proxmox Dark theme with the UniFi theme.

Two details in that table are worth pausing on. The ESXi Light theme comes from a different author, and its PDM support is described as palette only and untested, which is a candid admission that a theme is not automatically portable between the three products even when the palette matches.

And the light variants are not a separate aesthetic. The automatic light and dark entries pair a light member with a dark member of the same collection through prefers-color-scheme, and the README lists the pairs: UniFi with UniFi Light, UniFi OLED with UniFi Light, and then Nord, Gruvbox, Solarized and Catppuccin with Latte paired to Mocha.

Installing, and the checksum check that runs before anything else

There is a one-line install and a manual route, and the README is careful about what happens between the download and the install.

The one-liner is:

bash <(curl -fsSL https://raw.githubusercontent.com/IT-BAER/proxmorph/main/install.sh) install

The manual route clones the repository and runs the same script locally:

git clone https://github.com/IT-BAER/proxmorph.git
cd proxmorph
chmod +x install.sh
./install.sh install

The verification story is the part that makes the one-liner defensible. Every release ships a SHA256SUMS manifest and a GitHub build-provenance attestation, and the installer verifies the downloaded tarball against SHA256SUMS automatically and refuses to install on a mismatch, or if the manifest is missing, so it fails closed. That runs on the Proxmox host with tools already present, with sha256sum, so a normal install and update stay a single command with no extra setup.

The README also explains what each check gives you. SHA256SUMS proves the bytes match what was published with the release, which is integrity. The attestation gives a Sigstore and OIDC chain tying the artefact to the repository's Actions build, which lets you check origin against something other than the transport.

And it is honest that this is opt-in. The attestation check is a check you opt into, not something the host enforces, and neither check replaces reading install.sh before running it as root. The section on what the installer changes on your system is there precisely so you can do that.

For an air-gapped environment there is a third route, pointing the installer at your own copy of the release artefacts with the PROXMORPH_RELEASE_BASE environment variable set to the directory that directly contains the tarball and the manifest. Checksum verification still runs, against your mirrored SHA256SUMS.

Verifying a release on your workstation before rolling it out

The README makes a point about where each verification step belongs, and it is a good one. The provenance-level check should be run on your workstation rather than on the Proxmox node, because a stock Proxmox host has no gh CLI, so this step belongs on your machine and not the node.

The commands are given in full:

# integrity: do the bytes match the published manifest?
curl -fsSLO https://github.com/IT-BAER/proxmorph/releases/download/v<ver>/proxmorph-<ver>.tar.gz
curl -fsSLO https://github.com/IT-BAER/proxmorph/releases/download/v<ver>/SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing

# provenance: was it built by this repo's release workflow?
gh attestation verify proxmorph-<ver>.tar.gz --repo IT-BAER/proxmorph

The two lines of comments do the explaining. Integrity asks whether the bytes match the published manifest, and provenance asks whether the artefact was built by the repository's release workflow. The --ignore-missing flag on sha256sum is what lets the check run when the manifest lists more files than you downloaded.

The alternative to the download-and-verify flow is to install from a clone you have already read, which the README presents as a first-class path rather than a fallback:

git clone https://github.com/IT-BAER/proxmorph.git
cd proxmorph
git checkout v<ver>          # pin a release
less install.sh              # read it
./install.sh install         # installs from the local files, no download

Pinning a release with git checkout, reading the script with less, and installing from the local files with no download is the most auditable path available, and the README puts it right after the automated verification for that reason.

Auto light and dark, and the font override

Two of the features go beyond picking a colour scheme, and both are opt-in per host.

Automatic light and dark is enabled once per host and then you pick an (Auto) entry in the Color Theme dialog. Each entry is a small generated stylesheet that imports the light or dark member of a collection through the browser's prefers-color-scheme, so the theme follows the system setting live, without a reload. The entries survive ProxMorph and Proxmox updates while enabled, and the disable command removes them again. They also work as a server-side default, for example the default-theme command with the unifi-auto entry. The README says this is not available on PDM.

The custom UI font replaces the UI text font for every theme without touching the icon fonts. There are three forms of the command:

./install.sh font Inter https://cdn.jsdelivr.net/npm/@fontsource/[email protected]/files/inter-latin-400-normal.woff2

./install.sh font "Segoe UI"

./install.sh font none

The first form fetches a font file over https and embeds it, the second names a family that has to be installed on the viewing machine, and the third removes the override.

The privacy detail is the important one. A font file, which may be a woff2, woff, ttf or otf, either a local path or an https URL fetched once on the host, and up to 4 MB, is embedded into a generated stylesheet, so browsers never load anything from the internet. The stylesheet targets the ExtJS text selectors only and never the .fa, .x-fa classes or the tree expanders, so FontAwesome and the status glyphs are left alone. That last part is the kind of detail that separates a theme that works from one that breaks the interface icons.

The whole feature set is therefore three separate mechanisms: colour themes, a colour scheme that follows the operating system, and a font override, all installed on the host and all re-applied after a Proxmox update.

Where ProxMorph is the wrong tool

Three limits, and the first is about what the tool does to the host.

The first is that a theme system for Proxmox is not a theme system for the web at large. The implementation is CSS plus JavaScript targeting ExtJS selectors inside three specific products, and applying it means patching files on the Proxmox host and re-patching them after every product update. If your requirement is a consistent look across a whole fleet of mixed infrastructure, ProxMorph covers three products and nothing else, and the fact that the auto-theme feature is explicitly not available on PDM is a reminder that the three products are not interchangeable even within the tool.

The second is the trust question. The one-liner install pipes a script from the internet into bash as root on a machine that holds your virtualisation infrastructure, and while the README does the honest thing by shipping SHA256SUMS, verifying the tarball and offering a GitHub attestation, it also says plainly that the attestation is opt-in and that neither check replaces reading install.sh first. That is a reasonable position, but it means the security story is delegated to the operator, and an organisation with a change control process will want the reviewed-clone route rather than the one-liner.

The third is the theme quality per product. A palette that looks right on PVE may not be right on PBS, and the ESXi Light entry is described as PDM palette only and untested. The README's featured themes come with descriptive names but the gallery is the only way to judge them, and screenshots of a specific theme on a specific page do not tell you how it handles a data-dense view, an error state or a modal dialog.

The alternative approach, and it is worth naming, is to leave the native themes alone and accept the Proxmox appearance. The difference in approach is that ProxMorph buys you a consistent brand look on hardware you probably do not show to customers, whereas the native themes are guaranteed to match whatever Proxmox ships in the next release, with none of the patching risk. For a homelab or a consultancy demo environment the case is easy. For a production cluster, the cost of a theme that a Proxmox update can break is rarely worth the look.

Editorial conclusion

Adopt ProxMorph if you run Proxmox VE, PBS or PDM and the built-in colour themes are not what you want, since the themes are wired into the native selector rather than bolted on, the auto light and dark entries follow the system preference live, and the installer re-applies them after a product update. Do not adopt it if you need a theme for a Proxmox interface that is not one of the three covered products, or if you cannot accept a patching tool that modifies files on the host, and note that the ESXi Light theme is marked untested on PDM. Verify first that the installer runs on your Proxmox host with the tools already present, that you read install.sh before running it as root, that the auto-theme and font features are available on your product, since the README says auto-theme is not available on PDM, and that the theme you pick matches the interface you actually use, because the palette for a different product is not the same thing as a working theme there.

Frequently asked questions

Official sources

1. Issues
2. IT-BAER/proxmorph on GitHub
3. README
4. Releases