What is white-label and custom domain support?
White-labelling means your platform can run under a customer's own brand instead of yours — their logo, their colours, and critically, their domain name. A customer using your SaaS product visits app.theirclient.com.au instead of app.yourplatform.com.au. From their clients' perspective, it looks like the customer built the software themselves.
This goes beyond a logo swap. Custom domains require DNS configuration (the customer points a CNAME at your servers), automated SSL certificate provisioning for each domain, per-tenant theming stored in your database, and the removal of any "powered by" attribution from the interface.
It's a significant infrastructure and product investment, but it unlocks a tier of B2B customers — agencies, resellers, enterprise buyers — who won't buy without it.
When does your app need it?
- You're selling to agencies or businesses who resell your platform to their own clients
- Enterprise procurement requires that end-users don't know which vendor is behind the product
- You have a multi-tenant SaaS and want to offer white-label as a premium tier
- Your customers have strong brand requirements and your domain appearing in URLs is a deal-breaker
- You're building a platform that powers other businesses' customer-facing experiences
- Your competitors offer white-label and you're losing deals because of it
How much does it cost?
Adding white-label and custom domain support typically adds 11–21 hours of development — roughly $2,000–$5,000 AUD.
Lower end: Per-tenant theming (logo, colours, name) with a fixed subdomain per tenant on your own domain (e.g. clientname.yourplatform.com). DNS is handled entirely by you; no custom domain provisioning required.
Higher end: Full custom domain support where each tenant brings their own domain — automated DNS verification (CNAME check), SSL certificate provisioning via Let's Encrypt with automated renewal, per-tenant theme editor in the admin settings, domain validation and error handling, and removal of all platform branding from the white-labelled experience.
How it's typically built
Custom domain support requires your server to accept requests for arbitrary hostnames and map them to the correct tenant. This is typically implemented at the reverse proxy layer using Caddy (which handles Let's Encrypt certificate provisioning automatically) or at the application layer using cert-manager in a Kubernetes environment.
The onboarding flow for a tenant's custom domain: they enter their domain in settings → your platform generates a CNAME record for them to add to their DNS → your server polls for the CNAME to propagate → once verified, certificate provisioning begins → the domain goes live. This flow needs clear error messaging at each step.
Per-tenant theming stores a theme configuration object in your database (logo URL, primary colour, font preference) and applies it on each render. With CSS variables and a token-based design system, this is straightforward. Without one, it requires more bespoke work.
Questions to ask your developer
- Do you need true custom domains or just custom subdomains? Subdomains on your own domain (
client.yourplatform.com) are much simpler — no SSL automation required. - How many tenants will use this? SSL certificate automation and DNS verification logic becomes critical at scale.
- What does the customer onboarding flow for domain setup look like? Customers need clear instructions and feedback at each step.
- What happens when a certificate expires or a domain is transferred? Renewal automation and failure alerting need to be part of the build.
- How granular does per-tenant theming need to be? Logo and primary colour is simple; full custom CSS is complex and risky.
See also: Admin panel · Content management CMS · App cost calculator