Proxmox Custom Themes: What Survives Updates?

Yes, you can make Proxmox look like a cyberpunk control room, a UniFi console, Dracula, Tokyo Night, or almost anything else CSS can produce. Just keep in mind that custom themes are not an officially supported Proxmox feature, and that starts to matter once the novelty wears off.

A custom theme looks harmless because it changes colors, backgrounds, charts, logos, and typography, and leaves storage and networking alone. Many server-side themes, though, work by modifying files installed by Proxmox packages. A future update can replace those files, wipe out the customization, or break assumptions the theme made about the old UI structure.

Modern community projects handle that lifecycle much better than older ones did, although "it's only CSS" still isn't an operational plan.

Can Proxmox VE really be themed?

Yes, but "theme" can mean two very different things. Proxmox VE already has an official Color Theme selector. The web interface can follow the browser preference or use Proxmox's supported light and dark styles. That's the safe path, since those styles ship with the product.

Community themes go further. They can replace the color palette, restyle cards and navigation, change chart colors and typography, add branding, and make the interface look like a different product entirely.

A recent cyberpunk experiment showed why this surprises so many administrators. It changed the familiar Proxmox interface so much that the most common reaction was some version of "I did not know Proxmox could do this."

The creator said the styling was built with AI in roughly an hour, after first testing the design against a Cockpit installation. Changing the basic colors was easy. Getting the banner and other parts of the existing UI to behave was the hard part, and that describes the job pretty well. When you theme a mature admin interface, you're adapting someone else's HTML, ExtJS components, CSS structure, charts, spacing, icons, and update lifecycle, which takes a lot more than picking neon purple.

For the wider platform context, the Mr.PlanB Proxmox hub covers the parts of Proxmox that matter far more than appearance once the lab becomes infrastructure.

Does Proxmox officially support custom themes?

No. Proxmox staff have said plainly that official theming support is limited to the built-in theme options.

In a 2025 support discussion, a Proxmox staff member answered a question about third-party themes by saying there was no theming support beyond dark mode. Another experienced contributor explained why: projects such as PVEDiscordDark work by installing theme files and patching original PVE web files.

So the theme depends on the internal structure of the web interface staying compatible. If Proxmox changes a class name, moves a template, changes a JavaScript component, or updates the widget toolkit, the theme can break visually or functionally.

That doesn't make community themes bad, but you have to think of them as custom modifications. Plenty of open source systems work the same way: the code and assets are available, so you can change almost anything, but that doesn't make every change a supported extension point.

Why do custom themes sometimes disappear after an update?

Package upgrades can overwrite the files the theme modified. Older Proxmox theme projects often made users rerun an installer every time pve-manager or related UI packages were updated. PVEDiscordDark, for example, documents that its install command has to be rerun after a Proxmox update because the relevant files get replaced.

The same concern came up right away with the cyberpunk theme. One long-time user remembered playing with themes years earlier and said they stopped partly because an upgrade could overwrite the changes.

Say a theme edits a file under /usr/share/pve-manager/ or /usr/share/javascript/proxmox-widget-toolkit/. Those paths belong to installed packages. When APT installs a newer package, it can put the vendor version of those files back, and your theme is gone, partly gone, or patched against a layout it was never tested with. A theme that looks perfect today still needs an update strategy.

How does ProxMorph make themes more persistent?

ProxMorph builds update persistence into the theme system, so you don't have to remember it. The project currently supports Proxmox VE 8.x and 9.x, Proxmox Backup Server 3.x and 4.x, and Proxmox Datacenter Manager 1.x. It offers 23 themes across several collections, including Catppuccin, Dracula, Nord, Gruvbox, Solarized, Tokyo Night, UniFi, GitHub Dark, and Blue Slate.

The installation process matters more than the theme count. ProxMorph copies CSS files into the Proxmox widget toolkit, patches the theme map so the new choices show up in the native Color Theme selector, injects the JavaScript or CSS needed for charts and product specific UI elements, and installs an APT hook. That hook re-applies the local patches after relevant Proxmox updates. An upgrade can still replace the modified files, but the theme system then tries to patch the fresh copies automatically. That beats telling the administrator to remember a shell command after every upgrade.

ProxMorph also backs up original files before modifying them and provides an uninstall command to restore them. I'd weigh those two features above the visual polish. A customization is much easier to justify when you already know how it gets restored after updates and how to remove it.

Is ProxMorph actually part of Proxmox?

No. It integrates with Proxmox's native theme selector, but it's still a third-party community project. Once installed, a ProxMorph theme appears in the normal Color Theme dropdown, so from the user's side it can feel native. Underneath, the installer still patches files.

Its documentation is unusually open about that. It lists exactly what changes, where CSS is copied, how the theme map is modified, which index templates are touched, where the update hook lives, and where backups are stored. That's what you want from this kind of tool.

The installer runs as root, so don't let "it's just a theme" talk you out of reading the script. ProxMorph now publishes SHA256 manifests and build provenance for releases, and its documentation recommends reviewing install.sh before running it. That's good advice for any community script you run on a hypervisor.

Is theming a production Proxmox server a bad idea?

Not necessarily. How much risk is acceptable depends on how the theme is implemented. The most conservative view is that the management interface is operational tooling, so changing it adds little business value and one more moving part. Several administrators reacted that way: if the cluster is production infrastructure, they'd rather leave the interface alone.

The other side has a point too. A CSS theme is a long way from modifying Ceph, corosync, kernel modules, or VM storage. Some organizations use custom branding, boot logos, color systems, or visual differences between environments without trouble.

Visual distinction can even help operationally. If production is dark red, staging is blue, and a lab cluster is cyberpunk purple, it's harder to mistake one environment for another. That only works if the customization stays predictable.

I would apply three rules:

1. The theme must be removable.
2. The original files must be recoverable.
3. A Proxmox update must never depend on the theme remaining compatible.

If the web interface becomes unusable after an update, you should still be comfortable managing the host over SSH and removing the customization.

A Proxmox Health Check won't judge your color palette, but it's a good reminder to get the cluster's operational basics healthy before you spend time on how it looks.

Is browser-side theming safer?

Yes, if all you want is a different look. One suggestion from the Proxmox community is to apply custom CSS through a browser extension such as Stylus and leave the server files alone. The customization then lives entirely on the client, and Proxmox stays untouched. If the theme breaks, disable the stylesheet. If one administrator wants cyberpunk neon and another prefers the standard interface, both get what they want.

A browser-side theme can still break when Proxmox changes its DOM or CSS, but the breakage stays in the browser and never touches the admin server. That makes it especially attractive for production.

The downside is that the theme follows the browser instead of the cluster, and some dynamic elements such as charts may need more than simple CSS. Server-side projects can produce a more complete and consistent result. You're trading convenience and completeness for isolation.

What is the safest way to experiment with a custom theme?

Treat it like any other nonessential modification and make it easy to reverse. A good sequence is:

1. Confirm SSH access works before touching the web UI.
2. Back up any files the theme will modify.
3. Read the installer instead of piping an unknown script directly into a root shell.
4. Prefer a tagged release or pinned commit over an arbitrary moving branch.
5. Test on a noncritical node or lab environment first.
6. Apply the theme.
7. Test login, console access, storage views, backup views, charts, tasks, and mobile layouts.
8. Run a normal Proxmox update.
9. Confirm the interface still works after the update.
10. Test uninstall or rollback before you forget how it works.

People tend to skip the update test. You don't really know a theme works until you've seen what happens after the packages it modifies get replaced.

Customizing Proxmox is easy, but maintaining it takes work

The cyberpunk experiment shows how little time modern CSS plus AI assistance needs to produce something visually dramatic. That makes experimenting easier, but the maintenance still has to happen.

Proxmox's own light and dark themes are supported, so treat everything beyond that as a customization layer that may have to keep up with changes in the web interface.

If you only want different colors, client-side CSS is the lowest risk option. If you want a polished system-wide theme, a project such as ProxMorph is more attractive because it integrates with the native selector, documents what it changes, keeps backups, and re-applies patches automatically after updates.

And if you want to build your own cyberpunk interface, go ahead. Just make sure the rollback procedure is a lot less exciting than the theme.