Runtime configuration

Remote config for values that need to change after release.

Nona gives web, mobile, and backend apps one self-hosted place to read runtime values: feature-related toggles, copy, limits, JSON settings, and environment-specific behavior.

Read remote config docsCompare feature flags

When remote config earns its keep

Environment variables are still great for deployment wiring. Remote config matters when a value needs to move at runtime, after the artifact is already in the wild.

  • Mobile apps need new values without a store release.
  • Operators need to change thresholds or kill switches after deploy.
  • Backend services need typed settings without rebuilding containers.
  • Staging and production need isolated values behind the same code path.

The Nona model

Projects

Application or service boundaries

Environments

Production, staging, development, or any runtime stage

Parameters

Typed text, boolean, number, or JSON values

Scopes

Frontend-readable, server-only, or shared access

API keys

Environment-specific runtime access

Four content types, picked for the value at hand

Every entry has a key, a value, a content type, and a scope — the same building block behind both feature flags and broader remote config.

Type
Use it for
Example
boolean
Feature flags, kill switches, on/off rollout gates
checkout_v2 = true
text
Labels, copy, identifiers that aren't numbers or JSON
App:BannerText = "Free shipping this week"
number
Limits, thresholds, percentages, retry counts
Limits:MaxItems = 50
json
Grouped settings a client deserializes directly
App:Settings = {"retries":3,"timeoutMs":2000}

Poll cheaply: ETags, 304s, and prefix filters

Every read returns an ETag. Send it back as If-None-Match on your next poll and Nona responds 304 Not Modified with no body when nothing changed — so a mobile app can check for updates on every resume without paying for a full payload each time. Need only one group of settings? Filter the response by key prefix.

conditional GET + prefix filtering
# First request — capture the ETag
curl -i "https://nona.example.com/api/environments/production/parameters" \
  -H "X-Api-Key: your-api-key"
# ETag: "a1b2c3..."

# Poll again later — send it back as If-None-Match
curl -i "https://nona.example.com/api/environments/production/parameters" \
  -H "X-Api-Key: your-api-key" \
  -H 'If-None-Match: "a1b2c3..."'
# -> 304 Not Modified, no body, nothing changed

# Only need one group of settings? Filter by prefix.
curl "https://nona.example.com/api/environments/production/parameters?prefix=App:" \
  -H "X-Api-Key: your-api-key"

Remote config vs environment variables

These aren't competing systems — most teams use both. Environment variables fit deployment-time wiring: server-only, rarely changing, safe to redeploy for. Remote config fits values that need to change after deployment without a rebuild.

Environment variables

  • NONA_API_KEY (in the consuming app)
  • Database / infra connection strings
  • Deployment-specific hostnames
  • Secret material

Nona (remote config)

  • Features:Checkout
  • App:BannerText
  • Limits:MaxItems
  • App:Settings

First implementation step

Keep the application wiring in env vars, then move one runtime value into Nona from the CLI:

nona-cli
nona entries set \
  --project storefront \
  --environment production \
  --key App:BannerText \
  --value "Free shipping this week" \
  --scope client \
  --content-type text

Then read that value from the app over plain HTTP or an official client — see the HTTP client docs.

Frequently asked questions

Are environment variables and remote config competing systems?

No. Most teams use both — the question is which values belong in which layer.

What should stay in environment variables?

Deployment wiring, secret material, and infrastructure-specific settings that rarely change and can safely trigger a restart when they do.

What should move into remote config?

Values that need to change after deployment — feature flags, copy, thresholds, and runtime behavior settings.

How do clients avoid re-fetching config that hasn't changed?

Every read returns an ETag. Send it back as If-None-Match on the next request and Nona returns 304 Not Modified with no body when nothing changed.

Put one runtime value under control.

Add one setting that currently requires a redeploy, then switch your app to read it from Nona.

Get started