Environment Configuration
Keep settings out of your code so the same build runs cleanly across sandbox and production.
What you'll learn
- Separate configuration from application code
- Vary settings safely across environments
- Avoid hard-coding endpoints and credentials
- Validate configuration at startup
- Make the active environment unmistakable
6 min
Config is not code
Anything that changes between environments — base URLs, credentials, timeouts, feature toggles — is configuration, not code. Mixing the two forces you to edit and rebuild the application just to point it at a different environment, which is error-prone and slow.
The healthier model is one immutable build that reads its settings from outside: environment variables, a config file, or a configuration service. The same artefact you tested in sandbox is the one you run in production, differing only in the values it is given. This separation is what lets you promote a build with confidence rather than rebuilding and hoping it still behaves.
Varying by environment
Each environment supplies its own values for the same set of keys. Sandbox points at the sandbox endpoint with sandbox credentials; production points at the live endpoint with live credentials. The code does not know or care which — it just reads the keys.
API_BASE_URL=https://api.merion.com.au
API_TIMEOUT_SECONDS=10
ENVIRONMENT=productionKeep the set of keys identical across environments so nothing is silently missing when you promote. A value that exists in sandbox but not production is a failure waiting to happen on deploy. Document the full set of expected keys so a new environment can be stood up correctly.
Validate early
Read and validate configuration at startup, before the application accepts any traffic. A missing or malformed setting should stop the process immediately with a clear message, not surface as a confusing failure during the first request hours later.
- Check presence — every required key must be set.
- Check shape — URLs parse, numbers are numbers, enums are valid.
- Fail loudly — refuse to start rather than run half-configured.
This fail-fast approach turns a whole class of subtle runtime bugs into an obvious, immediate startup error that is trivial to diagnose and fix.
Make the environment obvious
A surprising number of incidents come from code running against the wrong environment. Guard against it by making the active environment explicit everywhere — in startup logs, in health checks, and in any operator-facing surface.
An explicit environment marker lets safety checks refuse dangerous combinations, such as test data flowing to a live endpoint. It also helps anyone reading logs immediately know which world they are looking at. Never infer the environment from a hostname or a guess; set it deliberately and surface it loudly. The few seconds it takes to print ENVIRONMENT=production at boot can save hours of confusion later. See secrets management for handling the sensitive values.
Key takeaways
- Treat anything that varies by environment as configuration, not code
- Run one immutable build that reads settings from outside
- Keep the set of config keys identical across environments
- Validate configuration at startup and fail fast on problems
- Make the active environment explicit in logs and health checks
FAQ
Why not just hard-code the endpoint?
Because then a single build cannot run in more than one environment, and switching means editing and rebuilding. External configuration lets the same tested artefact run anywhere by supplying different values.
Where should configuration live?
Outside the build — in environment variables, a config file, or a configuration service. The key principle is that the application reads its settings at runtime rather than baking them into the code.
How do I prevent running against the wrong environment?
Set an explicit environment marker, print it at startup, and add safety checks that refuse dangerous combinations. Never infer the environment from a hostname or assume a default.
Ready to build?
Read the API reference, grab the OpenAPI spec, and ship a resilient integration.