branding

All fields are optional; empty values mean no branding is configured.

Key	Type	Default
branding.org_name	string	empty
branding.logo_path	string	empty
branding.login_notice	string	empty
branding.support_email	string	empty
branding.support_label	string	empty

org_name

string, default empty

The organization name displayed in the web UI (e.g., “Acme Corp”). Empty disables organization-specific branding.

branding:
  org_name: ""

logo_path

string, default empty

The filesystem path to the organization’s logo image. Empty disables the logo.

Accepted types: PNG, JPEG, GIF, WebP, SVG. Maximum size: 1 MB (maxLogoSize in server/controller/logo_image.go). The type is determined from the file’s own bytes, not its extension.

Read once at startup and validated then, so a bad path fails the server rather than producing a broken image later; replacing the file needs a restart. Served from /api/branding/logo, always same-origin, so no third-party host sees the unauthenticated login page’s traffic.

branding:
  logo_path: ""

login_notice

string, default empty

A plain-text message shown on the login page before authentication. Empty disables the notice. Supports newlines for multi-line text.

branding:
  login_notice: ""

support_email

string, default empty

The address of whoever answers for this deployment — the local help desk, not the project. Empty leaves the web UI pointing at its defaults: “contact your administrator” on the login page and the account-disabled page, and the project’s GitHub issue tracker in the footer.

Set it and all three become a mailto: link to this address. One setting covers them because it is one question — “who do I ask about this deployment?” — and a second key would let an operator answer it in one place and forget the other, which is the failure this exists to prevent. admin.contact_email was that second key; it is still read for the account-disabled page when this is unset.

It is served by the unauthenticated /api/branding endpoint and rendered on the login page, so it is public: use the shared support address, never a personal one. It is parsed at startup and a value that is not an address fails the server rather than producing a dead link on the one page a locked-out user can reach.

branding:
  support_email: "support@example.com"

support_label

string, default empty

The link text for support_email, e.g. “the IT service desk”. Ignored when support_email is unset.

Empty falls back to whatever reads best in each place: the address itself on the login page, where it sits in a sentence and is a complete instruction on its own, and “Contact support” in the footer, where a bare address would be noise in a row of links.

branding:
  support_label: "the IT service desk"