Branding

Put your own name, description, light and dark logos and social card on the console, the server's pages and its mail, set in the configuration file.

A slopscale server can carry your own name, logo, description and link preview instead of the product’s. The console, the pages the server renders in a browser, the Apple configuration profile, the browser tab and the mail the server sends all follow these settings, so a company deploying it internally does not hand its staff somebody else’s brand.

Every value comes from the configuration file. They are read once at startup: changing any of them needs a restart.

branding:
  title: "Example VPN"
  description: "The Example Inc private network"
  logo_path: /etc/slopscale/logo.svg
  logo_dark_path: /etc/slopscale/logo-dark.svg
  social_image_path: /etc/slopscale/social.png

Each setting stands on its own. Renaming without a logo leaves the built-in mark in place; a logo without a rename keeps the name Slopscale. logo_dark_path is the exception: it is a variant of logo_path, so the server refuses to start with only the dark one set.

Like every other setting, these can come from the environment instead, which suits a container or a systemd unit:

SLOPSCALE_BRANDING_TITLE="Example VPN"
SLOPSCALE_BRANDING_DESCRIPTION="The Example Inc private network"
SLOPSCALE_BRANDING_LOGO_PATH=/etc/slopscale/logo.svg
SLOPSCALE_BRANDING_LOGO_DARK_PATH=/etc/slopscale/logo-dark.svg
SLOPSCALE_BRANDING_SOCIAL_IMAGE_PATH=/etc/slopscale/social.png

The title

branding.title is the name of the server everywhere a person reads one:

the console’s sidebar, its sign-in page and every browser tab title
the pages the server renders for a device login, a registration, an error and the platform instructions
the name macOS shows for the installed configuration profile
the display name on the mail the server sends, when notifications.smtp.from is a bare address
the title of an ntfy notification

What stays the product’s own: the slopscale command, the configuration keys, the API, the X-Mailer header and the “Powered by Slopscale” line in the footer of a rendered page. Those name the software, not your service.

The description

branding.description is the one line under a link to this server: what a chat or a feed prints beneath the preview, and what a search engine reads as the page description. It defaults to the product’s own pitch, which is the wrong sentence for an internal deployment.

An empty value is refused rather than treated as “leave it out”, the same way an empty title is, because a page with a blank description reads as a mistake to whatever is unfurling it.

The logo

branding.logo_path is a file on the server: .svg, .png, .jpg or .webp, up to 1 MB. It must be readable by the user the server runs as.

The file is read at startup and served from memory at /branding/logo, so a page render never touches the disk and a file deleted later does not break the console. The address carries a hash of the file, which lets a browser cache it forever and still pick up a replacement after a restart.

The logo replaces the built-in mark in the console’s sidebar, on the sign-in page, at the top of every rendered page, and as the browser tab’s icon.

It is always fitted, never stretched. The sidebar gives it the square slot the built-in mark sits in, next to the name, so a square icon suits it best; a wide wordmark is legible on the sign-in page and on the rendered pages, but shrinks to fit the sidebar and repeats a name the sidebar already prints.

One logo or two

A mark that carries its own background, the way an app icon does, reads on both themes and needs only logo_path. A logo drawn in one flat colour does not: a dark wordmark disappears against the console in dark mode. Give logo_dark_path for that case and the server serves it from /branding/logo-dark, with its own hash.

Who picks which depends on where the logo is drawn. The console follows the theme in effect, so switching its light/dark control swaps the logo even when that disagrees with the browser’s own preference. The pages the server renders carry no such control, so they offer both through <picture> and the browser chooses by prefers-color-scheme. The browser tab’s icon is always the light logo, because there is no way to hand a browser two.

Without logo_dark_path, everything above serves logo_path.

The picture a chat or a feed draws for a shared link is baked with the product’s mark and name, so a server with its own logo_path stops offering it: the link unfurls without an image rather than with the wrong one.

branding.social_image_path gives it back. It is a .png or .jpg on the server, up to 4 MB, served from /branding/social under a hash of the file like the logos. Make it 1200×630; that is the shape every unfurler crops to. The server reads the real size out of the file and tells the unfurler that, rather than assuming, so a picture in another shape is at least described honestly.

Set it whenever you set a logo. The card is the only branding a person sees before they open the link at all.

What it does not change

Branding is presentation. It does not rename the tailnet, the base domain or any user-visible address, and it grants nothing: a console page still shows only what the signed-in role may see.