White Label Branding
ProxCenter supports white-label customization, allowing MSPs and organizations to rebrand the interface with their own logo, colors, and application name. Your users see your brand, not ProxCenter's.
Overview
White-label branding replaces ProxCenter's default visual identity with your own. This is particularly useful for managed service providers who offer Proxmox management as a service to their clients, or for enterprises that want the tool to match their internal branding.
Customizable Elements
| Element | Description |
|---|---|
| Application Name | Replaces "ProxCenter" in the header, page titles, and email notifications |
| Logo | Displayed in the sidebar header, login page, and branded email templates. Supports PNG, SVG, and JPG. |
| Favicon | The browser tab icon |
| Primary Color | The accent color used for buttons, links, and active elements |
| Login Background | Custom background image or color for the login page |
| Login Copy | Tenant-facing login page text and presentation |
Asset Requirements
| Asset | Recommendation |
|---|---|
| Sidebar logo | SVG or transparent PNG, wide format around 200x50px |
| Favicon | Square PNG or ICO, at least 32x32px |
| Login background | JPEG or PNG optimized for desktop and laptop screens |
| Email logo | Transparent PNG with enough contrast on a light background |
Avoid uploading screenshots or full marketing banners as logos. Use compact brand assets that remain readable in the sidebar, login page and email templates.
Configuration
- Navigate to Settings > White Label
- Upload your logo (recommended size: 200x50px for the sidebar, square version for the favicon)
- Set your application name
- Choose your primary brand color using the color picker or enter a hex value
- Preview the changes in real time
- Click Save Changes to apply
Changes take effect immediately for all users. No restart or cache clearing is needed on the server side, though users may need to refresh their browser tab.
The tab is reserved for a super_admin acting in the provider tenant, so branding stays a provider decision even in a multi-tenant deployment.
Primary Color
The Primary Color card takes a hex value, either from the color picker or typed into the Hex Color field.
| Accepted | Rejected |
|---|---|
Six digits, #00ECB2 | Named colors, teal |
Three digits, #0EB | Functional notation, rgb(0, 236, 178) |
The same without the leading #, 00ECB2, which is completed for you | Values carrying an alpha channel, #00ECB280 |
Alpha forms are refused on purpose. The color is not painted as is: the whole palette is derived from it, and a translucent value yields nonsense shades on hover and active states.
Leave the field empty for no override, and use the reset control to return to the shipped palette.
While the field holds something that is not a hex color it turns red, explains itself with Enter a hex colour such as #00ECB2. The leading # is added for you if you leave it out., and Save Changes stays disabled. The API refuses the same value independently, so a call made outside the interface cannot store one either.
The primary color feeds the palette that the theme provider builds, and that provider wraps the dashboard and the login page alike. Up to v1.4.7 a value typed without its leading # was stored as typed, and every page of the tenant answered a 500, login page included. There was no interface left to undo it: the only way back was an UPDATE on the settings table.
v1.4.8 closes the class rather than the case. The value is normalized when it is saved and again each time branding is read, the field blocks the save, and the theme provider treats whatever is left as untrusted and falls back to the shipped color rather than throwing mid-render. An instance already stuck on the 500 page recovers on its own after the upgrade: the first branding read repairs the stored value, and saving the page once cleans the row for good.
Contrast
Labels and avatar initials drawn on a surface filled with your primary color now follow the contrast color computed from it, so a light brand color keeps its text readable instead of leaving dark-on-dark or white-on-white. This is visible on the highlighted row of the command palette (Ctrl/Cmd + K), on the profile button and its avatar initials, and on the drag handle of a dashboard widget.
Contrast is still worth checking by eye on a very light or very saturated brand color, see the Validation Checklist.
Validation Checklist
After saving a white-label configuration, verify:
- Sidebar logo readability in dark and light themes.
- Login page logo, background and copy before authentication.
- Button and link contrast with the chosen primary color.
- Email template branding if notifications are enabled.
- Tenant portal consistency when multi-tenancy is enabled.
Login Page
The login page uses the same white-label theme as the authenticated application. Logo, primary color, dark scheme, background, and copy are applied before users authenticate, which is important for customer-facing MSP portals.
If multi-tenancy is enabled, the branded login shell remains provider-controlled so tenants receive a consistent portal identity.
Email Branding
When white-label is configured, outgoing email notifications also reflect your branding:
- The "From" name uses your application name
- Email templates use your primary color
- Your logo appears in the email header
For the best visual result, provide a logo with a transparent background. The sidebar has a dark background, so light-colored logos work best for the navigation area.
White Label branding is available in the Enterprise edition.
Permissions
| Permission | Description |
|---|---|
admin.settings | Read and write the branding configuration |
The White Label tab is additionally reserved for a super_admin acting in the provider tenant.
| Required Feature | Edition |
|---|---|
white_label | Enterprise |