Skip to main content
Start Free Trial

Branding and domains

Branding controls the hosted Guardhouse experience. Domain settings control the public issuer and therefore affect every application, API, social callback, and passkey integration.

Availability

Branding controls can vary by plan. Guardhouse Cloud custom domains are available only when enabled for the workspace. A self-hosted operator configures domains and TLS in the deployment instead of using the Cloud domain workflow.

Set organization details​

Open Organization to configure:

  • the application name shown to users;
  • privacy-policy and terms-of-service URLs;
  • which profile fields users may change;
  • whether users may request account deletion or export their data.

Publish valid HTTPS legal links before opening signup. If users may change their email, delete their account, or export data, ensure the corresponding verification, support, and retention processes are ready.

Customize hosted pages​

Open Branding to customize the hosted authentication experience:

  • layout and form position;
  • primary, secondary, and semantic colors;
  • backgrounds;
  • fonts and text;
  • borders, sizes, and spacing;
  • social links and brand-panel content;
  • light and dark logos;
  • light and dark favicons;
  • the email logo and other supported image assets.

Use the preview for multiple page states and test narrow and wide viewports. Verify contrast, keyboard focus, long translated text, validation errors, MFA, and recovery screens—not only the default sign-in view.

Use advanced branding carefully​

Experimental appearance controls and custom HTML/CSS provide more flexibility but also make upgrades and accessibility testing more important.

  • Treat experimental controls as subject to change.
  • Add only trusted HTML and CSS.
  • Do not insert secrets, tracking values, or user-specific information.
  • Keep links and form controls keyboard-accessible.
  • Test every modified page state after a Guardhouse upgrade.
  • Keep a copy of the last known-good configuration for rollback.

Configure a Guardhouse Cloud custom domain​

A workspace can use one active custom domain. The exact setup entry point and availability depend on the Cloud plan and workspace state.

  1. Choose a dedicated hostname, such as an authentication subdomain you control.
  2. Start the domain workflow shown for the workspace. If no control is available, use the customer portal or contact Guardhouse support.
  3. Add the DNS record exactly as Guardhouse supplies it. Do not infer the target from another tenant.
  4. Wait for DNS verification.
  5. Wait for Guardhouse to provision TLS.
  6. Activate the domain only after the workflow reports it ready.

DNS propagation and certificate provisioning are separate steps. Do not route production applications to the new hostname until both have completed.

Plan for an issuer change​

Activating another tenant domain changes the canonical URLs applications use. Before activation:

  • add the new redirect and post-logout URIs to clients;
  • update social-provider callback registrations;
  • update API issuer and JWKS configuration;
  • confirm resource audiences remain correct;
  • update application discovery or authority settings;
  • test login, logout, refresh, introspection, and webhooks;
  • test existing and newly enrolled passkeys.

Passkeys are bound to a WebAuthn relying-party identity. Users may need to enroll a new passkey after a domain change.

Plan a rollback path and verify whether the previous/default hostname remains available for your workspace before relying on it.

Configure a self-hosted domain​

For self-hosted Guardhouse, the operator owns:

  • the canonical server domain used as the issuer;
  • public DNS;
  • reverse-proxy or ingress routing;
  • TLS certificate issuance and renewal;
  • trusted forwarded-proxy addresses and networks;
  • the website and portal domains used for outbound links.

Configure these values before issuing production tokens or enrolling passkeys. The Guardhouse Cloud custom-domain wizard and managed certificate workflow do not apply.

See Guardhouse Cloud and self-hosted deployments for the deployment boundary.