Config

Try the interactive example ↓

A read-only window into the static configuration the snug API server itself runs on: values fetched from Doppler for a project and environment pair and cached in Redis. Two operations - read the cached config, and force a refresh. Both require a platform admin token.

When to reach for it: operational debugging - confirming which configuration values the server is actually using for a project and environment, checking whether a Doppler change has landed, and pushing a change through immediately instead of waiting out the cache.

When not to: dynamic feature flags with environments, inheritance, and targeting rules belong to Remote Config; arbitrary application key-value data belongs to KV Store.

Concepts

• Project and environment name a Doppler config, and every request carries both in the path - for example snug-api / dev.
• The server is the Doppler client - it authenticates upstream with its own DOPPLER_TOKEN; callers never supply Doppler credentials, and nothing here writes back to Doppler.
• Responses are cached in Redis per project/environment pair for CONFIG_CACHE_TTL seconds (default 300). get serves the cached copy; a cache miss fetches from Doppler and caches the result.
• Refresh is delete-then-fetch - refresh drops the cache entry, refetches from Doppler, and returns the fresh config in the same shape as get.
• Admin only - both endpoints sit behind the platform admin gate; any other authenticated user gets 403 FORBIDDEN.

Read and refresh

snug config get -p snug-api -e dev
snug config refresh -p snug-api -e dev

Both flags are required for both commands. In --output json mode get prints the bare ConfigResponse - trimmed here, because the remaining entries are the deployment's real secrets:

{
  "values": {
    "DOPPLER_CONFIG": "dev",
    "DOPPLER_ENVIRONMENT": "dev",
    "DOPPLER_PROJECT": "snug-api",
    ...
  },
  "cached_at": 1787893018,
  "ttl_seconds": 300,
  "source": "doppler"
}

Every value is a string, cached_at is Unix epoch seconds, and source is "doppler". Treat the output like the credentials it contains.

refresh on the CLI prints a confirmation message (Configuration for snug-api/dev refreshed successfully) rather than the payload; over HTTP it returns the fresh ConfigResponse with cached_at advanced.

Over HTTP the same operations are GET /api/v1/config/{project}/{environment} and POST /api/v1/config/{project}/{environment}/refresh, both answering with the enveloped ConfigResponse:

curl -s -H "Authorization: Bearer $SNUG_API_TOKEN" \
  http://localhost:4000/api/v1/config/snug-api/dev

{
  "status": 200,
  "msg": "OK",
  "data": {
    "values": { ... },
    "cached_at": 1787893026,
    "ttl_seconds": 300,
    "source": "doppler"
  }
}

Without a platform admin token the gate answers before the service does:

{
  "status": 403,
  "msg": "Admin access required. Current platform role: user",
  "error": "FORBIDDEN"
}

Behaviors and gotchas

• Every failure past the admin gate is a generic 500. A missing DOPPLER_TOKEN on the server, an unknown project or environment, or a Doppler outage all surface as 500 INTERNAL_SERVER_ERROR with no detail in the envelope - the specifics land in the server log.
• Names are Doppler's names - --project is the Doppler project and --environment is the Doppler config name (dev, stg, prd), not a free-form label. The API defines no 404 for an unrecognized pair; it is one of the 500s above.

Limits and configuration

Two server-side environment variables govern it: DOPPLER_TOKEN (required - without it every request past the admin gate fails with a 500) and CONFIG_CACHE_TTL (cache lifetime in seconds, default 300).

Reference

• Config API - both endpoints, callable
• Related: Remote Config for dynamic flags with targeting rules, KV Store for arbitrary key-value data