Per-Tenant Configuration Overrides

In multi-tenant deployments, each tenant often needs to override a small subset of global configuration — their brand name, their preferred currency, their Stripe key. Per-tenant overrides keep these surgical changes isolated without forking the entire config.

Tenant configuration page showing a table of global settings with the tenant's current effective value, the source (global or overridden), and an inline override button per row

How It Works

The runtime config lookup checks: (1) tenant override, (2) global value, (3) field default. The first non-null value wins. This cascade applies to every instance-configuration field that has “tenants can override” ticked.

Setting an Override

Open Architect Panel → Tenants, click the tenant.
Go to the Configuration tab. Every overridable field is listed with its current effective value.
Click the value to override; the row turns into an editable input.
Enter the new value and save. Effective from the next request.

Common Overrides

Branding: Logo URL, brand name, support email, footer copy.
Currency / locale: Default currency, decimal separator, date format.
Integrations: Per-tenant Stripe / SendGrid / Twilio credentials.
Feature flags: Pilot tenant gets new feature true, others stay false.

Worked Examples

SaaS pricing: Tenant A on a custom plan has price_per_user overridden to $12; others use the global $15.
Tenant A pilots new dashboard: Override enable_new_dashboard to true for them. Bug found? Revert by clearing override. Promoted globally? Set the global value.
Localised SaaS: US tenant overrides date format to MM/DD/YYYY, UK keeps DD/MM/YYYY.
Per-tenant Stripe accounts: Each customer charges through their own Stripe account; tenant config holds their public + secret keys.

Tip: Build a “configuration audit” page for support to see at a glance what a tenant has overridden vs inherited. Faster than digging through individual rows during a support call.