Database, Environment, Config: How Our Settings Resolve

Software settings can come from several places. Some are saved by an administrator in a settings screen and stored in the database. Some are set on the server as environment values. Some are defaults written in configuration files that ship with the code. When the same setting exists in more than one place, the application needs a clear rule for which one wins.

Our platform uses one consistent order: the database first, then the environment, then the configuration default. Here is why that order works and how we keep it reliable.

Database first: what the administrator chose

Settings saved through an admin screen represent a deliberate choice by someone with authority to make it. They should take priority. If an administrator sets a price, a limit or a feature option in the admin area, that value is what the application uses.

This also means most changes do not require a deployment. Adjusting a price or a threshold in the admin area takes effect without anyone editing server files or shipping code.

Environment second: what the server specifies

Environment values are set on the server, outside the code. They are useful for settings that differ between environments, such as connection details for outside services, and for secrets that should never be stored in the code repository.

When no administrator has saved a value, the environment value applies.

Configuration last: the sensible default

Configuration files ship with the code and provide defaults. They make sure the application has a reasonable value for every setting even when nothing has been saved and nothing is set on the server.

Defaults are written carefully, because they apply whenever nobody has made a choice. A default that turns a sensitive feature on, for example, would be risky. Our defaults lean toward safe.

Never hard-code what should be a setting

A value written directly into code, such as a markup percentage, a spending limit or a feature toggle, cannot be changed without a release and is easy to forget. We avoid hard-coding values that people might reasonably need to adjust. Pricing for usage-based features, for example, is set in an admin screen and resolved through this same order, never buried in code.

Settings belong to the right account

Many settings exist for each organization and each website, not just for the platform. The same order applies within that scope: a website's saved setting first, then the platform's value where relevant, then the default. Settings services always know which account and website they are reading for, following the same principles described in code that works on the marketing site and inside customer accounts.

Secrets stay protected

Some settings are secrets, such as keys for outside services. Those may be stored encrypted in the database so administrators can manage them, or kept in server environment values. Either way, they are never sent to the browser or written into logs, as described in keeping secrets out of code and logs.

Caches must be cleared when settings change

For speed, resolved settings are often cached. When a setting is saved, the cache for that setting is cleared so the new value takes effect. Forgetting that step produces a frustrating bug: the administrator saves a change and nothing happens. Settings services handle cache clearing themselves, so individual features cannot forget.

Changes are recorded

Settings that affect money, security or customer experience are changed through admin screens that record who changed them. That history matters when something behaves unexpectedly: the first question is often whether a setting changed recently, and a record answers it immediately.

Documented in one place

The resolution order is written into our engineering standards, so everyone, including AI assistants, reads settings the same way. Consistency here prevents a quiet category of bugs where one feature reads the database while another reads only the environment, and the two disagree.

Frequently asked questions

Which setting wins if it is in the database and the environment?

In our platform, the value saved in the database through an admin screen takes priority, followed by the environment value, then the configuration default.

Why not keep all settings in configuration files?

Configuration files require a release to change. Admin-managed settings can be adjusted by authorized people without deploying code.

Where should secrets be stored?

In protected server environment values or encrypted settings, never in the code repository, logs or anything sent to the browser.