Branding

Hibernator shows its own logo on the login page, in the app bar, in its emails and in the exported Help deck. Set a brand and it shows your organisation’s name and logo there instead. A brand is optional: leave the branding values empty and nothing changes.

• The four values
• Setting a brand
• Logo rules
• Where the brand shows
• Where it does not
• When the brand is invalid
• Changing or removing a brand

The four values

Value	Required	Rule	When empty
branding.name	yes	Plain text on one line, 1 to 64 characters	no brand
branding.logo.light	yes	SVG text for light backgrounds, see Logo rules	no brand
branding.logo.dark	no	SVG text for dark backgrounds, same rules	the light logo
branding.accentColor	no	#RRGGBB	the product blue #1976d2

A brand is set when branding.name and branding.logo.light are both given. The name is the logo’s alt text on the login page, in the app bar and in the emails, and the company field of the exported Help deck.

The values are top level, not under config. The chart puts them into their own ConfigMap and mounts it into the API container only. The controller never sees them.

Setting a brand

Put the name and the accent colour into your values file:

branding:
  name: "Example Org"
  accentColor: "#0b5cad"

Pass each logo as a file with --set-file, so the SVG reaches the chart unchanged:

helm upgrade hibernator oci://registry.gitlab.com/cirriton/hibernator/charts/hibernator \
  -n hibernator -f my-values.yaml \
  --set-file branding.logo.light=logo-light.svg \
  --set-file branding.logo.dark=logo-dark.svg

Pass the same --set-file flags on every upgrade, the way you pass the same values file. An upgrade without them drops the logos, and the brand with them. If you would rather keep everything in one file, a block scalar works too:

branding:
  name: "Example Org"
  logo:
    light: |
      <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 240 64">...</svg>

To check the result, ask the API, under your config.externalUrl:

curl -s https://hibernator.example.com/api/v1/public/brand

It answers with the brand, its logos as data: URIs, or {"brand":null} when none is set or the one set is invalid. The API log says the same at start: The brand replaces the product logo with the name, or the warning described in When the brand is invalid.

If you use these logos in a tool of your own, use them only as an image source, such as <img src>. The rules below make a logo safe to draw as an image. They do not make it safe to insert into a page as markup, where an SVG can run script and load from outside.

Logo rules

The API is the only judge of a logo. The chart passes the values through unchecked, so helm install succeeds with a logo the API then refuses. A logo that breaks a rule is refused as it is: nothing is stripped or repaired.

A logo is valid when it is:

• An SVG document. One <svg> root in the namespace http://www.w3.org/2000/svg (xmlns="http://www.w3.org/2000/svg"), and no second element or text outside it.
• Sized by a viewBox with a positive width and height. The aspect ratio is read from it.
• At most 64 KiB. 65,536 bytes pass, counted as you set them.
• UTF-8. Declare encoding="UTF-8" or no encoding at all. A byte order mark is accepted.
• Well-formed the way a browser reads it. Every namespace prefix the file uses is declared, for example xmlns:xlink. No element carries the same attribute twice. No namespace declaration rebinds xml or xmlns, binds their namespaces to another prefix, or binds a prefix to an empty namespace.

It must not contain:

• <script>, <foreignObject>, or any element in the HTML namespace;
• an event-handler attribute (onload, onclick and every other on*, in any case);
• a ping attribute;
• a <!DOCTYPE>. Illustrator’s “SVG 1.1” export writes one: export without it or delete the line;
• <?xml-stylesheet?>, xml:base, or @import in any style;
• a reference out of the document. Every href, xlink:href and url(...) points into the document (#id) or is a data:image/... URI, such as an embedded PNG. data:image/svg+xml is refused, because nothing could check what it carries. In CSS, image-set(), image() and src() are refused too. An animation such as <set attributeName="href"> counts as the attribute it sets.

Two things make a logo work well beyond the rules:

• Convert text to outlines. A browser draws the logo inside an <img>, where it loads no font. Text set in a font the reader does not have falls back to another.
• Keep it small. Every mail carries the logo inline, base64-encoded. A logo near the 64 KiB cap adds about 87 KB to each mail, and a long notification can then pass the size at which Gmail clips a message (102 KB). Run the file through an SVG optimiser before you set it.

Where the brand shows

Place	Logo	Size
Login page	light logo in light mode, dark logo in dark mode	40 px high, at most 200 px wide
App bar	dark logo (the bar is always dark)	32 px high, at most 150 px wide
Sign-in, notification and passkey emails	light logo	at most 200 px wide and 64 px high
Exported Help deck	dark logo on the title and closing slides, light logo on the others	fitted to the slide

Every place draws the logo at its viewBox aspect ratio. A logo wider than its place allows is drawn smaller, and a square logo is drawn at the place’s height, so a wide logo reads best.

The exported Help deck also takes the brand’s name as its company field, and the accent colour as the background of its title and closing slides, behind the dark logo and white text, and as the text colour of its white slides. Pick an accent with a contrast of at least 4.5:1 against white, so both read.

Where it does not

• The favicon is always Hibernator’s own.
• The web UI’s colours stay as they are. The accent colour is used by the exported Help deck only.
• Teams notifications carry no logo.
• The version tooltip in the web UI keeps the logo of cirriton, who makes Hibernator.

When the brand is invalid

A brand that breaks a rule is ignored as a whole. This also applies to a brand that is only half set, such as a name without a light logo or a light logo without a name. Hibernator then shows its own logo everywhere: on the login page, in the app bar, in the emails and in the Help deck. The public brand route answers {"brand":null}.

The API logs one warning at start. It names every value that breaks a rule and, for each, the first rule it breaks. A warning about a reference or CSS also names the element and the attribute it was found in:

kubectl logs -n hibernator deployment/hibernator-app -c api | grep -i brand

The line looks like this, shortened:

{"level":"warn","msg":"The brand is ignored; the product logo shows","problem":"branding.logo.light must not carry a <!DOCTYPE>: a DTD can add entities and attributes the API cannot check; export the SVG without one"}

When several values break a rule, problem lists them separated by ;. A logo that breaks two rules shows only the first, so the second appears after you fix the first and upgrade again.

A valid brand can still give way to Hibernator’s logo in one browser. When the page cannot fetch the brand while it loads, it shows Hibernator’s logo, and a Help deck exported from it carries Hibernator’s logo and blue, until the page is reloaded. Nothing is logged for this. The emails are not affected.

Changing or removing a brand

The API reads the brand once at start. The app pod carries a checksum of the brand, so a helm upgrade that changes any branding value restarts the app pod, and the new brand shows from then on. A browser tab that was already open keeps the logo it loaded until it is reloaded.

To remove a brand, upgrade with the branding values empty. The chart then renders no brand ConfigMap, the app pod restarts, and Hibernator shows its own logo again.