# ADR-008: White-Label Branding via Config and Tenant Profile

| Field | Value |
| --- | --- |
| Status | Accepted |
| Date | 2025-01-01 |
| Deciders | Product + Platform Architecture |
| Supersedes | — |
| Superseded by | — |

## Context

The platform must serve many tenant brands without hardcoding colors, logos, or names in source.

## Decision

Platform brand defaults come from environment / `theme.config.json`. Tenant brand fields live on `tenants` (`primary_color`, `secondary_color`, `logo_url`, `favicon_url`, …). Frontend applies CSS variables. Public tenant-site APIs resolve theme by host for subdomain/custom-domain experiences.

## Consequences

### Positive

- Brand changes without rebuild
- Tenant onboarding captures brand early

### Negative

- Runtime theme loading must stay cacheable and tenant-safe

## Alternatives Considered

1. Hardcoded themes per tenant in frontend builds
2. Separate theme microservice from day one

## Related Documents

- [Multi-Tenant Architecture](../multi-tenant-architecture.md)
- [Deployment Architecture](../deployment-architecture.md)
- [Next Steps](../../next-steps.md)