Platform · Custom Domains
Sign-in that lives on your own domain
We put Keycloak behind auth.yourcompany.com with correct hostname settings, a private admin URL, automated TLS and a properly configured reverse proxy — and move you there without breaking redirect URIs or token validation.
- Keycloak hostname v2 configuration
- Separate private admin hostname
- Automated TLS certificates
Standards & integrations
- Keycloak hostname v2
- TLS 1.3
- cert-manager
- Let's Encrypt (ACME)
- Forwarded / X-Forwarded-* headers
- NGINX / HAProxy / Envoy
Overview
Why the hostname matters more than it looks
Keycloak's hostname ends up in every token's issuer, every redirect URI and every cookie it sets. Get it wrong behind a proxy and you see broken redirects, mixed-content errors or tokens your APIs reject. Get it right and users see one consistent, trusted domain, the admin console stays off the public internet, and session cookies stay first-party alongside your apps.
What we deliver
- Hostname and issuer design document
- Keycloak hostname and proxy-header configuration
- Reverse-proxy or ingress rules with an exposed-path allowlist
- Automated certificate issuance and renewal
- DNS cut-over plan with a client update checklist
- Runbook for adding domains and rotating certificates
Capabilities
What Custom Domains covers
Configured, tested and documented on upstream Keycloak — then handed over or operated by us.
Correct hostname settings
Hostname options set so Keycloak builds front-end and back-channel URLs correctly, and the issuer your applications validate never changes by accident.
Private admin console
A separate admin hostname reachable only from your network or VPN, with the public proxy exposing just the paths end users actually need.
Automated TLS
Certificates issued and renewed by cert-manager with Let's Encrypt or your internal CA, terminated at the proxy, re-encrypted, or passed through to Keycloak.
Reverse proxy done right
Proxy-header handling matched to your load balancer, trusted proxy addresses restricted, and forwarded headers from untrusted clients stripped before they reach Keycloak.
First-party cookies
Keycloak on a subdomain of your apps keeps its cookies same-site, avoiding the silent-login and session-check failures that browser third-party cookie restrictions cause.
Per-tenant domains at the edge
Where customers need their own login domain, we handle it at the proxy layer and design how issuer and redirect URIs behave for each one.
How it works
From first call to production
Plan the hostname and issuer change
We map every client, redirect URI, SAML service provider and token validator that depends on the current URL, and decide how the issuer change will roll out.
Build the edge
DNS, certificates, proxy rules and Keycloak hostname options are configured and verified in staging, including admin access, back-channel calls and logout.
Cut over in stages
Clients are updated in waves, DNS is switched with short TTLs, and we watch login errors closely until all traffic has moved to the new hostname.
Use cases
Where teams put it to work
Moving off a vendor-hosted login URL
Replace a provider's default tenant domain with auth.yourcompany.com as part of a migration to Keycloak, so users learn one trusted address.
Locking down administration
Keep the admin console on an internal hostname behind your VPN or zero-trust access, while public sign-in stays open to customers.
B2B products with customer domains
Give enterprise customers a login address under their own brand, routed at the proxy layer to the right tenant configuration.
FAQ
Custom Domains questions, answered
Will changing our Keycloak hostname break existing tokens?
The issuer in each token includes the hostname, so APIs validating against the old issuer will reject tokens from the new one, and vice versa. We sequence the change so validators, clients and short-lived tokens roll over together rather than failing all at once.
Can the admin console use a different hostname?
Yes. Keycloak supports a separate admin hostname, and we pair it with proxy rules so admin paths aren't reachable through the public hostname at all.
Can one Keycloak deployment serve several branded domains?
Keycloak doesn't natively bind domains to individual realms, so we handle this at the proxy layer and design how issuer and redirect URIs behave for each domain. It works, but it needs deliberate design up front.
Should TLS terminate at the proxy or at Keycloak?
Either works. Terminating at the proxy is simplest; re-encrypting to Keycloak or passing TLS through keeps traffic encrypted inside your network. We choose based on your security requirements and load balancer.
Ready to roll out Custom Domains?
Walk us through your requirements on a free strategy call. We'll come back with an architecture, a delivery plan and a fixed scope.