Branding authentik per domain with brands and custom CSS

The authentik branding documentation describes external user redirects as a brand setting that decides where a user goes when a login request arrives on that brand's domain. A brand can apply to a single domain, a domain wildcard, or as the default, so the domain the user types in selects the brand and its redirect. The field names and the rules for which users count as external are set out in the docs, so read them against the version you run before you design around them. In practice, one authentik deployment can present different entry points to different customers without a separate instance for each. Confirm the behavior in a test environment first.

Send a customer to its own identity provider or portal when its staff must authenticate against systems it controls, or when a shared login would confuse its users or show the wrong brand. Common cases are:

• The customer runs its own directory or single sign-on and already manages its users and MFA there.
• The customer's contract or security review requires its users to sign in on the customer's own domain.
• The customer needs a self-service portal that belongs to the customer, not to your tenant.

Keep the shared login for users whose accounts you manage. Decide per customer and write the decision into the scope so the customer, your team and any auditors see the same answer.

A wrong redirect target usually sends users to a page where they cannot sign in, or into a loop between two login pages. Other failures include a customer's users landing on your shared login and seeing another organization's branding, or a domain with no brand of its own falling back to the default brand and its flows. Users then report lockouts that look like password problems, which slows diagnosis. Check each brand by signing in from its domain with a test account for each user type, and watch the authentik logs for repeated redirects. Treat the redirect target as a change to production access and write the rollback step before you switch it.

Test each brand with one account per user type, starting from the domain the customer will actually use. Use a staging instance with the same brand settings as production. Record the expected landing URL for each scenario, and include a domain with no brand so the default brand path is covered. Check that the redirect target accepts the sign-in, that the return path works, and that no login loop appears in the browser or in authentik's event log. Repeat the test after every upgrade, because branding and flow behavior can change between releases, and check the release notes for the version you run.

It can, depending on who signs in and how your design counts them. The authentik pricing page lists three editions: Open Source at no charge with community Discord support only, Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. The enterprise-only features named on that page do not include branding, but confirm which edition your redirect design needs. Before you commit, ask authentik how users who authenticate through another portal are counted, and get the answer in writing with your quote.

Your platform team usually owns the brand objects, default flows and redirect settings in authentik, because they change the access path for every domain. The customer owns its own portal, its domain certificates, its user lifecycle and its MFA policy when it runs its own identity provider. Put both lists in the written scope with a named contact on each side. Without that split, a change to a customer domain can break sign-in, and each side may assume the other tested it. Review the split whenever a customer adds a domain or changes its identity provider.

Yes, as part of a fixed-scope engagement, provided the redirect work is written into the scope. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and this includes authentik. Most engagements agree scope, deliverables and timelines in writing before work starts, and a quote follows from that written scope. To scope redirects accurately, bring the list of domains, the customers and their identity sources, the expected landing page for each, and the test accounts you will use. Ongoing support and upgrades are available as retainers.

The main cost driver is how many brands you need and how different they are. Each brand needs its own logo, favicon, title, background and optionally custom CSS, plus a default flow, and each of those choices has to be designed, reviewed and tested against every login path your users take. Costs split into one-time design and build work, testing across browsers and devices, and any later changes. Ask for a written scope that lists each brand, each domain or wildcard it applies to, which flows it uses, and whether custom CSS is in or out. A brand that reuses the default look and flows is far less work than one with its own CSS and enrollment behavior.

The duration depends on the number of brands, the amount of custom CSS, and how many flows each brand must change, so there is no standard figure to quote here. Ask for a written scope with a timeline that separates design approval, build, testing against each domain, and cutover. Timelines also depend on how quickly your team reviews visual designs and how many rounds of revision you expect. A rollout that moves a few brands with default flows will be much shorter than one that rebuilds login pages for many customers at once.

You need a named approver for brand designs, someone who can supply final logos, favicons and background images, and an owner for DNS and the reverse proxy that serves each domain. Your team also needs to confirm which domains or wildcards each brand covers, and which users are routed to each brand. If you use custom CSS, expect a technical reviewer who can check it against the authentik version you run. Ask the partner to list these inputs in the written scope so that delays are visible before work starts.

Yes, a team with administrator access to authentik can create brands in the admin interface, upload images and set default flows. The harder part is custom CSS: it must be written against the markup of the authentik version you run, tested on each domain, and kept working through upgrades. Confirm your team's experience with the admin interface, CSS, and your reverse proxy configuration. If those skills are thin, a fixed-scope engagement can cover the design and build while your staff take over operation.

Adding a domain means creating or extending a brand that matches the new domain or wildcard, then confirming the default flow, branding title, logo and any CSS behave correctly on that domain. You also need DNS, TLS certificates and reverse proxy routing for the domain to reach authentik. Each new domain adds test cases for login, enrollment and recovery, because those flows may be served under different brands. Ask whether the scope includes ongoing additions and how each new domain is tested before it goes live.

Brand settings that use built-in fields are generally stable, but custom CSS depends on page structure that can change between releases, so it should be retested on every upgrade. Custom CSS support was added in 2025.4, so older deployments need that version or later before you can use it. Confirm the target version with the authentik release notes before you design the look, and include CSS regression checks in your upgrade plan.

The main risks are a brand that does not match the domain a user actually visits, default flows that send users to the wrong enrollment or recovery path, and CSS that hides form fields or error messages. Test each brand with real domains, check that error states remain readable, and confirm that branding does not change security settings. Ask the partner how they test brands on each domain and how a broken brand is rolled back.