An organization's branding lives under its ALIAS, not its domain

Featurekamo-shared-library
Shipped
August 26, 2026 at 7:22 PM UTC
Author
Kamo
Commit
008ac4f

The folder an organization's logo, colours, favicons and backgrounds are written to in the public bucket was its hostname with the dots turned into dashes — wendys.com became public/wendys-com/. That only ever worked while every organization had a hostname. A domain is optional now: it is what makes white-label branding go live, not what makes an organization exist. So the derivation had nothing to answer with for an organization that had not brought one, and the failure was not an error. On the write side provisioning refused with "No domain configured for this organization"; on the read side the derivation fell through to the platform's own folder, so the organization was painted in Kamo's colours with its own assets sitting correctly provisioned and unreferenced. An alias, by contrast, is mandatory, unique, and already constrained to exactly the characters a path segment may hold. OrgThemeAssets is one definition of this for the whole estate. It was open-coded in a dozen places across six services and three front ends — the provisioner, the quote letterhead, transactional email, the e-signature watermark, the meeting lobby, the sign-in screen — and every one of them had to agree to the character, because a logo written under one key and requested under another is invisible in a way that looks like the upload having failed. The quote letterhead is the first caller moved across. It also documents the split the rest of the estate now follows: the FOLDER names the organization, and the HOST decides only whether the request resolves, since MinIO serves the whole bucket from every theme.<apex> name it answers to.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing