Favicon

The site favicon is generated once, from a single uploaded source image, and deployed automatically with every build. Upload it under Settings (the favicon upload control); the app generates every size browsers and installable web apps expect.

Uploading

Settings’ favicon control accepts PNG, JPEG, SVG, or ICO files up to 5 MB. On save:

The source is size-checked (“roughly square”: an aspect ratio no wider than ~1.25:1, because scaling a wide wordmark into an icon produces an unusable sliver). Non-square uploads are rejected with a clear message rather than mangled.
A generated icon set is produced: favicon-96x96.png, apple-touch-icon.png (180×180), web-app-manifest-192x192.png, web-app-manifest-512x512.png, an SVG wrapper embedding the 96×96 rendering (favicon.svg), and a favicon.ico (taken verbatim when you uploaded an ICO, otherwise derived from the 96×96 PNG).
Files land in two places: the assets/ directory (the source of truth for the next static build) and public/ (so the CMS can serve them immediately).
The save triggers a rebuild, and the action is audited (“Favicon updated by ”).

Fresh installs ship a default set (the Chinaski mark), which the upload replaces.

Where the favicons appear

At build time, the full favicon set is copied to the site root of the output (not under any language prefix) and included in the signed build manifest. The standard _head.tt partial then emits the favicon <link> tags for enabled sites: favicon PNG, apple-touch-icon, and the .ico shortcut.

Removing it

The Settings favicon delete control removes the uploaded source and all derivatives from both directories, clears the setting, and triggers a rebuild; the restored state is the shipped defaults (or no favicon <head> links if the shipped defaults are absent).

Failure modes to know about

Where is the favicon not working? The generated set lives in assets/; if the static build happens elsewhere, a build-log entry tells you. favicon.svg generation failure is logged as a warning (non-fatal), while the PNG/ICO set is what the <head> references.
Root-owned leftovers: generated and copied files replace rather than modify; a stray root-owned favicon left behind by a deploy tooling action can’t wedge the save; the write path requires directory-level writability instead of file-level ownership.
If the process can’t write the assets directory at all, the flash error names the directory and points at ownership/permissions; that’s your fix, not retrying.