White-labeling

An OEM can present the engine as its own product. Every user-facing surface — filed tickets, HTML reports, transactional email, API metadata — is rebranded from a handful of env vars, no code changes.

Configure

Env var	Rebrands	Default
UPLIFTR_PRODUCT_NAME	ticket titles/footers/labels, HTML report, all email, API title, /health service name	Upliftr
UPLIFTR_DOCS_URL	help links shown in root-cause hints	https://docs.upliftr.io
UPLIFTR_SUITE_EXT	the suite-file extension tag	upliftr.yaml
UPLIFTR_EMAIL_FROM	the From address on transactional email	(product name + sending domain)

# docker-compose .env
UPLIFTR_PRODUCT_NAME=Acme QA
UPLIFTR_DOCS_URL=https://docs.acme.com
UPLIFTR_EMAIL_FROM=Acme QA <qa@acme.com>

With that set, a filed issue reads [Acme QA] Checkout — pay with card, labelled acme-qa, footed "Filed automatically by Acme QA…"; reports and emails say Acme QA; the API identifies as Acme QA API.

What's intentionally not rebranded

The hidden de-duplication marker inside a filed issue body (<!-- upliftr-fingerprint: … -->) stays fixed. It's an invisible HTML comment used to recognise a re-filed failure and comment on the existing ticket instead of opening a duplicate — rebranding it would break de-duplication across re-runs. It's never shown to a user; the visible label carries your brand.

Where it fits

Combine white-labeling with a per-customer API token and self-hosting the engine on your own infra, and you have a fully OEM'd capability: your brand, your infrastructure, your customers' data never leaving your environment. See Embedding Upliftr for the whole picture.

Licensing note. Upliftr is distributed under a non-commercial license. OEM / white-label / reselling as part of a paid service requires a commercial license — see COMMERCIAL.md in the repo before shipping an embedded deployment.