Environment Management Overview
Why every non-trivial application needs to behave differently depending on where it's running, and the mental model that both a .NET backend and a React frontend share before their implementations diverge.
What Is an "Environment"?
An environment is a named deployment target that an application runs in — each with its own infrastructure, data, and settings. The same source code runs unmodified in all of them; what changes is configuration: which database to connect to, which API host to call, which third-party keys are valid, how verbose logging should be.
Most BizFirst applications recognize a small, familiar set of environments:
Local / Development
Runs on a developer's own machine. Talks to local or shared-dev databases, uses relaxed security settings, hot-reloads on change.
QA
A shared environment used by testers to validate builds before they progress further. Configuration mirrors production as closely as practical.
Staging
A near-identical mirror of production used as a final gate before release — same topology, often smaller scale.
Production
The live environment real users depend on. Strictest security, real credentials, real traffic, real consequences.
Why Per-Environment Configuration Matters
If an application hardcoded a single database connection string or a single API URL, it could only ever run against one target. Every environment needs its own values for things like:
- Where to send requests — database connection strings, API base URLs, message queue endpoints.
- Who to trust — OAuth client IDs, CORS-allowed origins, signing keys.
- How to behave — logging verbosity, feature flags, timeouts, retry counts.
The engineering problem every stack has to solve is the same: given a running instance of this application, how does it know which environment it's in, and how does it load the right values for that environment? The rest of this chapter is about the two very different answers a .NET server and a React browser bundle give to that question.
The Shared Mental Model
Strip away the implementation details and both a .NET backend (like Flow) and a React
frontend (like FlowStudio) do the same two conceptual steps:
- Name the environment. Somewhere, something decides "this instance is
Production" (orDevelopment, orQA). - Load configuration for that name. The app reads a set of key/value settings that correspond to the named environment — a connection string, an API URL, a client ID — and uses those values while it runs.
environment"] --> B["Load config
for that name"] --> C["App runs with
environment-specific values"]
The shared two-step model — every stack does this, they just differ in when and how.
The two steps above look identical on paper, but a .NET process and a React browser bundle perform them at completely different times, using completely different mechanisms. That divergence is the subject of the next page — it is the source of nearly every "why isn't my env var taking effect" question in this system.