White-Label Your Chiptuning Portal in 5 Minutes: Logo, Colour, Domain, Email, Certificate

A chiptuning customer who finds you online, lands on your website, clicks “Submit a File”, and gets bounced to a portal that says “Powered by [Some Other Brand]” with a logo they don’t recognise — that customer’s confidence just dropped 40%. White-label branding isn’t a vanity feature. It’s the difference between “this workshop runs a real platform” and “this workshop uses some third-party tool”.

The good news: white-labelling a self-hosted portal is mostly a 5-minute exercise, once you know the five surfaces that need to change. The bad news: if you miss even one of them — sender email address, the certificate PDF logo, the login page background — the leak is the first thing your customer notices.

This guide walks through the five surfaces that need branding, the four “leak points” that catch out workshops, and how to verify your portal is fully white-labelled before you put it in front of a paying customer.

The five surfaces (in priority order)

Surface 1 — Browser tab + logo

Every visit to your portal starts with a tab and a logo. Both must say your brand, in your colour palette, on your domain.

What needs configuring:

• App name (the text shown in the browser title bar, e.g. “PerformanceWorks Portal”)
• Logo (PNG or SVG, ideally 200-400px wide, transparent background)
• Favicon (32×32 PNG or SVG, used in the browser tab)
• Primary colour (CTA buttons, links, accent borders — your brand accent)

The portal’s settings hub should have all four in one panel — five minutes of upload-and-save.

Surface 2 — The login page

A customer who’s been linked to your portal first sees the login page. If the login page is white with the platform’s stock photo and the platform’s “Why choose us” marketing copy, the customer thinks they’re on the wrong site.

What to control on the login page:

• Background image or animation — your workshop, your cars, your dyno. Not the platform’s stock imagery.
• The marketing chips row (“24/7 support · 138 ECU families · 10,000+ engines”) — should reflect your workshop’s capabilities, not the platform’s.
• The “Why choose us” / “How it works” / “Live capabilities” sections — these should either be on (and reflecting your messaging) or off (clean login with just the form). Toggle each from the Branding tab.
• Animation style for the background — Ken Burns / Zoom / Pan / Pulse — match your brand mood (high-energy performance shop = Zoom; clinical engineering shop = Pulse).

Surface 3 — Email sender address

Every transactional email (account confirmation, file delivery, completion notification, password reset) goes out with a “From” address. If that address is noreply@some-other-brand.com, the customer’s spam filter will catch it half the time — and the half that gets through reads as third-party.

What to configure:

• SMTP server (the mail provider you control — Brevo, Mailgun, SendGrid, or your own postfix)
• From address (hello@your-workshop.com)
• From name (“PerformanceWorks Engineering”)
• Reply-to (where actual replies should go — usually support@your-workshop.com or the personal address of your lead engineer)

SPF + DKIM + DMARC records on your domain are mandatory. Without them, your transactional mail lands in Promotions or Spam for half your customers.

Surface 4 — The branded certificate PDF

If you’re issuing tuning certificates (and you should be — see the branded certificate guide), the certificate is the most public-facing branded artefact you produce. Customers screenshot it, share it, post it in Facebook groups.

What needs to be branded on the certificate:

• Logo (centred top, your workshop logo)
• Display colour for the title accent (“CERTIFICATE” in your brand orange / red / green)
• Watermark logo stamps (18 low-opacity copies tiled in the background — same logo file as the top-of-page)
• Light or dark theme — picked once in the Branding tab, independent of the portal’s main theme

Surface 5 — Domain

The single biggest leak: your portal at tunersuite.someplatform.com is not your portal — it’s a sub-folder on someone else’s platform from the customer’s perspective.

Two domain models, both viable:

Model A — Subdomain on your existing site. portal.your-workshop.com or files.your-workshop.com. Easiest setup: CNAME the subdomain to your portal’s IP / host. The customer browses your-workshop.com for marketing, clicks “File Service”, lands on files.your-workshop.com. Same brand, no leak.

Model B — Standalone domain for the portal. your-workshop-portal.com or tune.your-workshop.com. Slightly more SEO work (two domains to rank) but lets you separate the marketing site (heavy CMS) from the portal itself cleanly.

Either way: no shared subdomain on the platform vendor’s primary domain. Customers notice.

The four leak points (catch these before customers do)

Leak 1 — File revision history strings

Old portals (and older versions of new portals) sometimes auto-write platform-vendor branded strings into the file revision history. The customer opens their request, scrolls down, sees a string referencing a brand that isn’t yours.

Defence: a database-level trigger that scrubs any incoming string containing the platform vendor’s name into your brand. If your portal supports this (TunerSuite ships such triggers as a migration on every install), enable it. Then look at your historical revisions — if any rows already carry the wrong phrasing, run a one-off UPDATE migration to clean them up.

Audit your revision table after every release with a simple LIKE query against the platform vendor’s product name. Zero rows = clean. Any rows = scrub them.

Leak 2 — Notification body text

In-app notifications, email notifications, Telegram messages — each has a title and a body. Old portals occasionally hardcode “Welcome to [Platform]” in the welcome email, “Your [Platform] file is ready” in the completion notification. The customer’s inbox now contains the wrong brand.

Defence: every notification template should read its brand from a Setting::get('app_name', 'Portal') lookup, not from a hardcoded literal. Open your notification templates folder and grep for the platform’s literal name — anything found is a leak. Replace with the dynamic brand pull.

Leak 3 — Source code comments + HTML comments

The platform’s source code (the .php files, the compiled views, the JS bundles) typically contains comments like <!-- [Platform] Premium Theme --> or // [Platform] Auth Layer. A customer who right-clicks → View Source sees these.

Defence: in your portal vendor’s build pipeline, every comment that references the platform’s brand should be stripped before encoding. If you can’t audit the build pipeline yourself, run a pre-deploy grep on the shipped artefact (the .zip your portal ships in) for the platform’s literal name. The result should be zero.

This is the leak that’s hardest to defend against because it requires the platform vendor to do work you can’t directly control. The two practical defences: (1) pick a vendor whose build pipeline has documented strip-comments behaviour, and (2) periodically grep your live install for the platform’s name in compiled view files.

Leak 4 — Tradename in the footer or “About” copy

The portal’s default footer or About page may carry “Built with [Platform]” or “Software by [Platform]”. This is the most direct leak.

Defence: the portal’s footer should be 100% customisable from the Branding tab — your copyright line, your address, your support links, no platform attribution. If the platform forces a “Powered by” footer, that’s a deal-breaker. Switch vendors.

How to verify your portal is fully white-labelled

A 60-second audit catches almost every leak:

1. Open your portal’s homepage in an incognito window. Look at the browser tab, the favicon, the logo, the colour scheme. Any platform reference = leak.
2. Right-click → View Page Source. Search the HTML for the platform vendor’s name (e.g. “tunersuite”, “platform-x”). Zero matches = clean.
3. Submit a test file request. Watch the in-app notification, the email, the Telegram (if linked). Brand should be yours on every channel.
4. Mark the request complete and download the certificate. Logo, colours, watermarks, footer = yours.
5. View the request’s revision history. No platform-name strings anywhere.
6. Open the login page in incognito. Background, marketing chips, “Why choose us” — all yours or all off.
7. Inspect the email DKIM/SPF. Test with mail-tester.com — should score 9+/10.

Any failure on any step = leak. Fix it, re-test.

What this looks like in TunerSuite

TunerSuite v2.8.166+ ships a dedicated Branding tab inside the Settings Hub. Five-minute workflow:

1. Upload logo (transparent PNG / SVG, 200-400px wide).
2. Upload favicon (32×32 PNG / SVG).
3. Pick primary brand colour from a colour picker; preview live in the dashboard sidebar.
4. Set app name.
5. Configure SMTP profile (the platform ships profiles for Brevo, Mailgun, SendGrid, Resend, and a generic SMTP option).

The branding tab also has one-click toggles for every marketing section on the login page (the 3 chips row, “Why choose us”, “How it works”, “Live capabilities”, animated background). Each toggle preserves your selection across portal updates.

The certificate’s light/dark theme is picked here too, independently of the portal’s overall theme. A workshop running a dark-mode portal can still issue a light certificate for printability.

Belt-and-braces: TunerSuite installs ship MySQL triggers that auto-scrub any platform-internal strings written into customer-visible columns (revision history, notification titles), so even if a future code path accidentally writes the wrong string, the trigger catches it before the customer sees it. This was added after a 2026-05 audit of fleet installs caught two legacy code paths that wrote the platform’s brand into revisions — the triggers stop that class of bug at the database layer.

The full feature surface is bundled in the £699 TunerSuite one-time licence. There is no “white-label edition” charged separately — every install ships fully brandable from day one. See the white-label feature page for the complete capabilities list.

FAQ

Can I have a different brand on each of my portals?
Yes. If you run a master/sub-dealer network, each portal has its own independent Branding configuration — different logo, different colour, different domain, different email sender. The master and each sub-dealer can look like entirely different companies (because operationally, they are).

What about the URL bar — can I get rid of /admin/ or /portal/ in the path?
The portal’s internal routing structure can be customised through the route prefix setting. Customer-facing routes can be re-mapped — e.g. /admin/dashboard becomes /staff/dashboard. End-customer routes (/my-account, /file-requests) can be re-mapped as well. Most workshops keep the defaults because customers don’t notice path structure; only the domain matters.

Can I customise the layout of the dashboard or the file-request form?
Layout and section ordering can be controlled via Settings Hub toggles (which sections appear, in what order). Deep visual customisation — replacing the entire dashboard with your own React app, for instance — is possible but requires forking the theme. Two themes ship by default (neural-glass + spotify-dark); a workshop with strong design preferences can fork one of those.

What if my brand needs change later — say, a rebrand?
Every branding setting is editable at any time. A rebrand is a Settings Hub update, not a portal reinstall. The change propagates to the dashboard, login page, email templates, and certificate the moment you save. Customers who receive an email mid-rebrand will see one email in the old brand and the next in the new — clean cutover.

Does the platform vendor see my customer list / files / branding?
On a self-hosted install, no — your data lives on your server, the vendor has no access. Cloud/SaaS portals are a different model and the answer is usually yes (the vendor has database access for support purposes); whether that’s a concern depends on your relationship with the vendor. The self-hosted vs SaaS guide covers this trade-off in detail.

Next step

If you’re already on TunerSuite v2.8.166 or later, open Settings Hub → Branding and run through the five-step setup. The whole thing is genuinely 5-10 minutes for a workshop that already has a logo and a domain.

If you’re evaluating a portal and the vendor doesn’t have a dedicated branding tab — or worse, charges separately for white-labelling — that’s a signal the platform was built for one centralised brand and adapted afterwards. TunerSuite was built white-label-first; a single £699 one-time licence covers the full branding surface.

If you’re migrating from a SaaS portal that wouldn’t let you fully brand, the migration guide walks through the data export and the cutover.

For the operational side of running multiple branded portals as part of a network, read the sub-dealer network guide. For the customer-facing artefact your branding produces most visibly, see the branded certificate guide.