Self-Hosted White-Label Developer Portal
Ship a white-label developer portal
The problem: your docs carry the wrong name
What DSR Docs does: branding as configuration
Who edits it, and why that matters
When it's the right fit
When it isn't
Ship a white-label developer portal If you ship developer portals under a brand that isn't your own — an agency delivering per client, an OEM, a platform vendor white-labeling docs into a larger product — the site has to read as their product, down to the name, logo, favicon, and brand color. DSR Docs makes that visual identity editable live from the admin panel an admin changes it, saves, and the running site re-skins itself in seconds — no code change, no rebuild, no redeploy. When a client nudges the brand color or swaps the logo the week before launch, that's a save, not a release cycle. DSR Docs treats branding as configuration, not code three hex values drive the whole palette. The problem your docs carry the wrong name If you're an agency, an OEM, or a platform vendor, the developer portal you ship is part of the deliverable — and it has to read as the customer's product, not yours and not a tool vendor's. The moment a docs site shows someone else's default theme, a generic wordmark, or a favicon that isn't the client's, the whole thing looks unfinished. Worse, the brand tweaks that matter most tend to land last a color that's a shade off, a logo that changed after sign-off, a footer that needs the client's legal links. If every one of those is an engineering ticket and a redeploy, you're shipping release cycles to move a hex value. What DSR Docs does branding as configuration DSR Docs makes the full visual identity editable from the admin panel while the app is running. An admin sets the site name (header wordmark and browser-tab title), uploads a logo and favicon, picks brand, text, and background colors from three hex values, chooses body, code, and heading fonts, and configures a footer with text plus labeled links. On save, the config hot-applies through CSS variables and re-renders the header, sidebar, and chrome in place — no rebuild in the loop. The reader on the page sees the new brand without refreshing their tab. Nothing about this touches the content the same OpenAPI, GraphQL, Doxygen, and Markdown pages render underneath, just wearing a different skin. Who edits it, and why that matters Because branding lives in the panel and not in a stylesheet, the person adjusting it doesn't have to be an engineer. A designer, a project lead, or the client themselves can dial in the palette and swap the logo without a pull request. That's the difference between "we'll get to the brand color next sprint" and "done, refresh the tab." SVG logo uploads are sanitized on the way in, so handing that control to a non-developer doesn't open an XSS hole. When it's the right fit Reach for this when you ship docs under a brand that isn't the tool vendor's and that brand changes without warning agencies delivering portals per client, vendors white-labeling docs into a larger product, or any team that wants its documentation to look like it was built in-house. It fits especially well when the people who own the brand aren't the people who own the codebase, and you don't want a deploy standing between them and a color change. Because DSR Docs is self-hosted — one container that runs inside your environment — each client portal stays isolated, with its own config, access rules, and optionally its own domain. When it isn't Branding is per-deployment, not per-request. One running instance has one identity at a time; it can't serve Client A's brand and Client B's brand from the same URL depending on who's asking. If you were hoping a single site would shape-shift its look per visitor, that's not the model — the pattern is one lightweight instance per brand. See Expose API docs to external customers for how access modes and per-page visibility stack on top of branding once the portal is live. [!IMPORTANT] Sounds like your case? Write to docs@dsr-corporation.com. We'll show you the engine on documentation like yours, and say plainly what a move would involve.