Instance Branding

A Multiforum instance can present its own documentation, source, issue tracker and support contact in place of the upstream project's, and can add its own links to the site footer. Branding is configurable by an administrator in the UI and, for deployments that prefer it, by environment variables.

Branding currently covers footer links and text. Logo, favicon and theme colour fields exist in the schema but are not yet rendered.

What branding controls

The site footer has three rows:

1. Site links — Privacy Policy, Terms of Use, About, Moderation Issues, Report a Bug, Report Harmful or Illegal Content, followed by any extra links you configure. The first six are always present.
2. Support line — an invitation to open an issue in the software's issue tracker, and the instance's support email address. Either half is omitted when it is not configured; the whole row disappears when neither is.
3. Attribution line — Powered by <product name>, with links to the documentation and source code.

Configuring branding as an administrator

Go to Admin Settings → Settings → Branding.

Field	Effect
Name shown in the footer attribution	Replaces "Multiforum" in the attribution line
Documentation URL	Where the footer's documentation link goes
Source code URL	Where the footer's source code link goes — point this at your fork if you maintain one
Issue tracker URL	Where people are sent to report problems with the software itself
Support email address	Contact address for this instance, shown in the support line
Show documentation, source and attribution links	Turn off to present the instance under its own name only
Extra footer links	Up to eight additional label/URL pairs, appended after the built-in links

Leaving a link field blank hides that link. Blanking the support email removes the address from the footer entirely.

Changes save with the form's Save button and apply to every page.

Presenting the instance under its own name

Turning off Show documentation, source and attribution links removes the attribution line, the documentation and source links, and the upstream issue tracker in a single setting.

The support email is deliberately independent of that toggle: an instance that hides upstream references still needs somewhere to send its own users. Set a support address before turning the toggle off, or the footer will offer no way to reach anyone.

How values are resolved

Branding resolves through three layers, lowest precedence first:

upstream defaults  ->  NUXT_PUBLIC_BRANDING_*  ->  administrator settings

• A field an administrator has never set leaves the layer below in place, so configuring a deployment default does not require also setting it in the UI.
• An empty value is a deliberate opt-out and does clear the link, rather than falling back.
• A malformed value falls back to the layer below rather than rendering. The API rejects malformed values on save as well, so this only matters for values already stored.

Accepted values

Field	Accepted
URLs	http:// or https:// addresses, or site-relative paths beginning with /
Support email	A standard name@example.com address
Extra footer links	Each needs a non-empty label and an acceptable URL; at most eight

Other URL schemes are rejected. javascript: and data: URLs are refused by both the form and the API, because branding values are rendered into links on every page: a stored javascript: URL would run for every visitor.

Extra footer links whose target is off-site open in a new tab.

Configuring branding by environment variable

Deployments that would rather set branding alongside the rest of their configuration can use these variables. They are read at container startup, so one built image can be re-branded without a rebuild.

Variable	Description
NUXT_PUBLIC_BRANDING_PRODUCT_NAME	Name in the footer attribution
NUXT_PUBLIC_BRANDING_DOCS_URL	Documentation link target
NUXT_PUBLIC_BRANDING_SOURCE_URL	Source repository link target
NUXT_PUBLIC_BRANDING_ISSUES_URL	Issue tracker link target
NUXT_PUBLIC_BRANDING_SUPPORT_EMAIL	Support contact address
NUXT_PUBLIC_BRANDING_SHOW_UPSTREAM_LINKS	false hides all upstream references
NUXT_PUBLIC_BRANDING_CUSTOM_FOOTER_LINKS	JSON array, e.g. [{"label":"Handbook","url":"/handbook"}]
NUXT_PUBLIC_BRANDING_LOCKED	true pins branding to these variables

note

In a Compose deployment, an unset variable and one assigned an empty value are not the same thing. The Compose files pass each branding variable through only when it is set, so leaving it out of your env file keeps the built-in default. Writing NUXT_PUBLIC_BRANDING_DOCS_URL= with no value is a deliberate opt-out and hides the documentation link.

Branding pass-through requires a frontend image and Compose files from the release that added it. On an older release, configure branding through the admin UI instead.

Pinning branding to deployment configuration

NUXT_PUBLIC_BRANDING_LOCKED=true reverses the last two layers: the environment variables win over anything stored by an administrator, and the Branding tab renders read-only with an explanation.

Use it when branding is managed declaratively — in a Helm chart, a Compose overlay, or a hosting provider's project settings — and must not drift from what is checked in. Without it, an administrator's change in the UI would silently override the deployment's configuration.

Defaults

Field	Default
Product name	Multiforum
Documentation URL	https://docs.multiforum.net/
Source code URL	https://github.com/gennit-project/multiforum-nuxt
Issue tracker URL	https://github.com/gennit-project/multiforum-nuxt/issues
Support email	None — the footer omits the address until one is set
Show upstream links	On
Extra footer links	None

The support address has no default on purpose. An instance that never sets one omits it, rather than directing its users to the upstream maintainers' inbox.