--- title: "Branding" description: "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. ```yaml 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`](/slopscale/ref/webhooks) is a bare address - the title of an [ntfy](/slopscale/ref/webhooks) 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 `` 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 social card 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](/slopscale/ref/roles) may see.