Environments

Q: How many environments should most teams start with?

Most teams should start with staging and production. That is enough to test safely without creating unnecessary environment sprawl.

An environment stores a set of config entries for a particular runtime stage.

Typical examples:

development
staging
production

This lets the same key exist with different values per environment.

That matters for:

safe testing
staged rollout preparation
migration mapping from Firebase conditions into Nona environments

Why environments matter

Environments let one application keep different runtime behavior without changing key names.

For example:

Features:Checkout can be false in staging
Features:Checkout can be true in production

That same pattern also works for non-boolean config:

text copy
numeric thresholds
JSON settings

How to create environments

The first automated setup path is nona init, which creates or reuses the environment you pass with --env and defaults to production:

nona init --yes --base-url https://nona.example.com --email admin@example.com --password <password> --project storefront --env production

In admin:

open Projects
open the project
click Add Environment
create staging
click Add Environment again
create production

Those environments then appear as selectable tabs on the project page.

Use init for bootstrap automation and the admin project screen for day-to-day environment management.

Releases and active config

Each environment has one editable working configuration and zero or more immutable releases.

Public config reads use releases:

no version query parameter reads the environment’s active release
version=1.1.0 reads that exact release
version=1.1.x reads the highest patch in the 1.1 line

To publish a release, edit the working configuration, open the environment’s Releases panel, enter a version such as 1.1.0, and publish it.

To patch an older line, create a working draft from an existing release, make the fix, and publish a new patch version such as 1.1.1.

Non-active releases can be permanently deleted from the release list. Clear or replace the active release before deleting it. Deleting a release does not change the editable working configuration.

Common environment models

Most teams start with:

staging
production

Some teams also use:

development
preview

The right answer depends on your release flow, but the structure should stay simple until you actually need more.

What to store in each environment

Typical examples:

Features:Checkout = false in staging, true in production
App:BannerText with different copy in each environment
Limits:MaxItems with safer test values outside production

This is one of the main reasons environments exist: the key names stay stable while the values change by stage.

Good environment habits

keep environment names predictable
avoid creating environments that do not map to real operational stages
test risky flags and parameters outside production first
scope API keys to the environment they actually need when possible

Practical environment check

After creating environments:

switch between the environment tabs
create one parameter in staging
create or edit the same key in production
verify the values differ as expected

Firebase migration note

In the Firebase migration flow, Firebase conditions can be mapped into Nona environments during import.

That does not mean Nona should be documented as using Firebase-style live condition targeting. The migration is a bridge from one model into another.

FAQ

How many environments should most teams start with?

Most teams should start with staging and production.

That is enough to test safely without creating an unnecessary environment sprawl.

Should environment names match real operational stages?

Yes.

Environment names should map to real runtime stages that your team actually uses.

Can the same key exist in multiple environments?