---
copyright: "© 2026 DSR Corporation"
title: "Rebrand in a minute"
slug: tenancy-and-branding
order: 30
type: doc
description: "Logo, colors, and fonts — every visual is editable live and hot-applies with no rebuild."
seoTitle: "White-label docs: live branding, no rebuild"
seoDescription: "White-label your documentation in minutes — swap logo, colors, and fonts from the admin panel. Changes hot-apply live, with no rebuild, redeploy, or engineering ticket."
icon: Palette
visibility: public
llmSummary: "DSR Docs treats visual identity as configuration, not code: an admin edits site name, logo, favicon, brand/text/background colors, fonts, and footer from a single panel and the change hot-applies live via CSS variables — no rebuild, restart, redeploy, or engineering ticket per visual tweak. Because the brand is data on disk and the platform is self-hosted, the identity is per deployment on the customer's own infrastructure rather than rented per-request from a SaaS. Branding is per-deployment, not per-request (one identity per running container), so white-label portals for multiple clients run one instance per brand. Uploaded SVGs are sanitized with DOMPurify — scripts, event handlers, and javascript: URLs are stripped and the cleaned asset is stored (only an SVG left empty by sanitization is rejected), and branding is an admin-only capability separate from content editing, resettable to baseline."
faq:
  - q: "Can I white-label DSR Docs with my own logo, colors and fonts?"
    a: "Yes, from a single admin panel: site name, logo, favicon, brand color, text and background colors, separate fonts for body, headings and code, and the footer with your Privacy and Support links. The result is your product's identity, not ours."
  - q: "Do branding changes require a rebuild or a redeploy?"
    a: "No. Changes hot-apply through CSS variables, so the site re-skins live — no rebuild, no restart, no redeploy, and no engineering ticket for a color tweak. Open the editor in one tab and the docs in another, and the site changes as you type."
  - q: "Is DSR Docs multi-tenant — can one instance serve several brands?"
    a: "Branding is per deployment, not per request: a running instance carries one identity at a time. For a white-label portal serving several clients, the standard pattern is one lightweight instance per brand, each with its own config and domain."
  - q: "Is it safe to upload an SVG logo?"
    a: "Yes. Logo and favicon uploads are sanitized on the way in — any SVG is run through DOMPurify, which strips scripts, event handlers and javascript: URLs before the cleaned file is stored. An SVG that sanitization leaves empty is rejected outright."
  - q: "Who is allowed to change the branding?"
    a: "Admins only. Branding is deliberately separate from day-to-day content editing: editors own the words, admins own the deployment's identity. A single button resets everything to the baseline."
---

# Rebrand in a minute

DSR Docs ships ready to look like *your* product, not ours. Logo, colors, fonts, and footer are all editable from a single admin panel — and changes **hot-apply through CSS variables**, so the site re-skins instantly. No rebuild, no restart, no redeploy.

Because the brand is data on disk — not compiled in — a color change ships in seconds instead of a release cycle: no build step, no redeploy, no engineering ticket per visual tweak. And because DSR Docs is self-hosted, that identity is per deployment and lives on your infrastructure — you're skinning your own container, not renting a look from someone else's SaaS. The theme you're reading right now *is* that same engine applied to us; swap the three brand colors and it would be your product, top to bottom.

Open the editor in one tab and the docs in another, and watch the whole site change color as you type.

## Everything visual, in one place

| You set | It updates |
|---|---|
| **Site name** | Header wordmark and browser tab |
| **Logo & favicon** | Header mark and the tab icon |
| **Brand color** | Buttons, active nav, links, accents — everywhere |
| **Text & background** | Body copy, headings, panels, chrome |
| **Fonts** | Separate families for body, headings, and code |
| **Footer** | Footer text plus your Privacy and Support links |

One deployment, your identity — top to bottom, in a couple of clicks.

## Is this multi-tenant, or one brand per deployment?

Branding is **per deployment, not per request**: a running instance carries one identity at a time, so you don't serve Client A's brand and Client B's brand from the same URL. If you run a white-label developer portal for several clients, the standard pattern is one lightweight instance per brand, each with its own config and domain. See [Ship a white-label developer portal](/docs/use-cases/ship-a-white-label-developer-portal) for the full multi-tenant model, the WCAG-contrast behavior, and the deployment walkthrough.

## Safe by default

Logo and favicon uploads accept the usual image formats and are sanitized on the way in: any SVG is run through DOMPurify, which strips scripts, event handlers, and `javascript:` URLs, then stores the cleaned file (an SVG that sanitization leaves empty is rejected). Your brand assets land clean, every time.

## Built for the right hands

Branding is an **admin** capability, kept separate from day-to-day content editing. Editors own the words; admins own the deployment's identity. Reset to the baseline at any time with a single button.

> [!IMPORTANT]
> **Want this on your own documentation?** Write to docs@dsr-corporation.com. Ask about migration, licensing, or anything this page didn't cover.