Where Settings Come From
Configuration comes from two places: the application configuration file, and the settings held in the database.
Where to find it
Architect Panel → Configuration:
- Site Settings — the option groups, grouped by subject
Architect Panel → Configuration:
- Instance Configuration Fields — per-tenant values, a third source
The file
Holds values that need to exist before the database is reachable, values that should not be changeable from a web interface, and defaults. It is edited by somebody with access to the server, and a change requires a deployment.
The database
Holds the settings shown in Site Settings, editable by an administrator, taking effect immediately. Each setting mirrors a name the application reads.
Why some values stay in the file
Deliberately, and it is worth understanding rather than working around:
- Bootstrapping — database credentials cannot be held in the database.
- Security — some values should require server access to change, not merely an administrator account.
- Deployment discipline — a change that ought to go through review rather than a text box.
A setting marked not editable is a decision
Not an oversight. If a value appears in the file and is not offered in Site Settings, somebody decided it should not be changed casually.
Per-tenant values are a third source
Instance configuration holds values per tenant — credentials, endpoints, limits. So "where does this value come from" can have three answers, and it is worth knowing which applies before changing anything.
Know which source you are editing
The commonest confusion in this area is changing one and expecting the other to follow. A value edited in the file while the database holds its own copy produces a change that appears to do nothing.
Check both when diagnosing
When a setting is not behaving as configured, look at both sources before anything else. It is a thirty-second check that resolves a surprising proportion of configuration problems.
Keep the file under version control
Or at least backed up, with a record of changes. It is configuration that only exists on a server, and a server can be replaced.
Never put secrets in the file if you have somewhere better
Credentials belong in instance configuration, where they are encrypted and restricted. A key in a configuration file is a key in every backup and every copy of the codebase.
Worked example
An organisation keeps bootstrapping values and deployment settings in the file under version control, feature settings in Site Settings, and every credential in instance configuration. A setting that "would not change" turned out to be one where the file value was authoritative — found by checking both sources first.
Recommendations
- Know which source holds the value before editing.
- Check both when a setting misbehaves.
- Version-control the file.
- Credentials in instance configuration, not in the file.