Branding a Help Centre in Under Five Minutes
Branding a SupportPages help centre: automatic brand detection from your repository, logo and colour overrides, and custom domains with SSL.
The tell on a hosted help centre is usually the header. Product logo in the corner, everything else - the type, the spacing, the blue of the links, the shape of the search box - belonging to whoever built the platform. Customers notice, not consciously, but in the way they notice a shop with a different carpet in the back room. It reads as somewhere else, which is exactly the feeling you do not want at the moment somebody is trying to trust your instructions.
Getting out of that is mostly automatic now, because the information is already in your repository.
What gets detected without asking
When a project is first analysed, one of the things the analyzer does is work out what your product looks like. Not by asking you - by reading.
It compiles your actual stylesheet and extracts the design tokens: the colour variables, the type scale, the spacing and radii, whether they live in a Tailwind config, CSS custom properties or a framework theme. It finds your fonts. It finds your logo files and pulls the ink colour out of them to decide whether your brand reads light or dark. All of that gets cached for the project and used both for your help centre chrome and for the mockups inside your articles.
The practical effect is that a help centre generally looks like the product on the first run, before anyone has opened a settings page. Which is the right default, because the number of teams who will happily spend an afternoon in a theme editor is small and the number who need their docs to not look borrowed is all of them.
The four things worth overriding
Detection is good, not clairvoyant. Four cases come up often enough to be worth knowing about.
The repo is not the brand. Plenty of products have a marketing site with the real brand and an application built in whatever the framework shipped with. Detection reads the application, so it finds the framework. Upload your real logo and set the primary colour, and everything downstream - including generated mockups and walkthrough title cards - picks it up.
The logo has a background. Logos exported for a light website look wrong on a dark help centre header. Upload a transparent PNG or SVG if you have one, and a light version for dark backgrounds if your help centre is dark; it is the single most common fix.
Detection picked the wrong primary. It sometimes lands on a high-frequency accent rather than the actual brand colour - a warning red used all over an admin UI, for instance. Setting it explicitly takes a minute.
Fonts are licensed. If your brand font is not web-licensed for a third-party host, set a fallback deliberately rather than letting the browser choose one.
The domain is the part people underrate
Everything above is cosmetic compared to the URL. A help centre at yourproject.supportpages.io is visibly hosted, and visibly hosted things get trusted less - by customers reading instructions, and by search engines consolidating authority to your actual domain.
Custom domains are a CNAME plus a wait. Point help.yourcompany.com at your subdomain, and certificates are provisioned automatically through Cloudflare for SaaS; if you run your own DNS through Cloudflare, keep the record proxied. Propagation is usually minutes rather than the twenty-four hours the internet always promises.
One detail that catches people: once the custom domain is active, the original subdomain redirects to it. That is deliberate - two live URLs for the same content splits your search authority and gives you two sets of analytics for one help centre.
There is no escape hatch, deliberately
Branding controls are deliberately narrow. There is no arbitrary CSS injection, no template overriding, no layout editor. You get a logo (plus a version for dark backgrounds), colours, a light or dark scheme, any Google Font for headings and body, a choice of four hero styles, domain and a badge toggle on paid plans.
That is a real limit and I am not sure it is the right one forever. The argument for it is that every escape hatch becomes a support surface - custom CSS breaks on every layout change, and then the layout cannot change. The argument against is that some teams have a design system they genuinely want applied, and "close enough" grates.
There is also no per-section theming and no light/dark toggle for readers. You choose light, dark, or "match the reader's system", and the help centre follows that. For most products that is correct and for a few it is not.
Five minutes, honestly
Upload a transparent logo, check the primary colour matches the one in your design system, add the CNAME.
The rest was read out of your repository before you got there.
About the Author
Simon Moxon has been building SaaS companies since 2009. He's scaled teams to 20+ people, hit £2m ARR, and learned most of the lessons the hard way. Now he's building SupportPages.io - help docs that write themselves when you ship code. He writes about what's changed in SaaS and what hasn't.