Instance configuration fields are the platform-wide settings unique to a particular deployment — things like the support email address, the company VAT number, default currency, or which experimental features are enabled. They differ from Site Settings in that you define the fields yourself rather than working from a fixed list.
When to Use Instance Configuration
- Values that change rarely but need to be reachable from many parts of the platform.
- Values administrators (not developers) should manage.
- Values that differ across environments (dev/staging/prod) and tenants.
- Feature flags for gradual rollouts.
Defining a Field
- Open Architect Panel → Instance Configuration Fields.
- Click Add Field.
- Give it a name (used in code:
support_email), a label, a type (text, number, boolean, JSON), and a default. - Tick whether tenants can override the global value.
- Save.
Reading Values
From code: $AM->config('support_email'). The lookup automatically returns the tenant override if one exists, falling back to the global default.
Worked Examples
- Multi-region SaaS: A
default_currencyfield defaults to GBP; UK tenant uses GBP, US tenant overrides to USD, EU tenant overrides to EUR. - Feature flag:
enable_new_dashboarddefaults false. Toggle true on dev, then for a pilot tenant, then everywhere. - Third-party keys:
stripe_public_key,stripe_secret_keystored as instance configuration so credentials live in the database (encrypted), not in source code. - White-label branding:
brand_name,support_phone— each tenant overrides for their own branded experience.
Note: Secrets (API keys, passwords) should be marked as encrypted-at-rest. The field type encrypted_text handles this automatically — values are encrypted before storage and decrypted on read.