Env config viewer

Outcome

A platform admin can confirm the env vars in effect on the running admin-service instance, with a hard-redaction policy on secret-shaped keys — without shell access.

Prerequisites

• PLATFORM_ADMIN or PLATFORM_SUPPORT (gated by requirePlatformAuth()).

Surface

Element	Where
Page	/env-config on the platform console (admin.<env>.medsuiteone.ai)
Endpoint	GET /platform/env-config returns { generatedAt, nodeEnv, nodeVersion, processUptimeSec, entries } where each entry is { key, group, description, isSecret, isSet, isDefault, value, defaultValue }.
Catalog source	apps/admin-service/src/gateway/routes/env-config-catalog.ts — this service's own allowlist, of the env vars apps/admin-service/src/config.ts consumes. There are two catalogs in the repo and the console reads admin-service's; rcm-core keeps its file but no longer serves an env-config route at all.

Redaction policy

The redactEnvValue helper in packages/platform-identity/src/routes/env-config-report.ts is the single point of truth:

Entry kind	value on the wire
Secret (isSecret=true)	Always null, regardless of whether the var is set or falls back to default. Even baked-in dev defaults (e.g. JWT_SECRET fallback) are masked.
Non-secret	Raw string from process.env[key] when set, otherwise the catalog default.
defaultValue	Always passed through (catalog defaults are repo-public).

The integration test tests/integration-pg/src/ui28-platform-env-config.int.test.ts asserts that the seeded plaintext secret never appears anywhere in the response — keep this assertion in place if the catalog surface evolves.

When to use

Scenario	What you do
Confirming a deploy	"Did the new DASHBOARD_EMAIL_INTERVAL_MS actually land?" — the page shows source = env vs default. An unset override surfaces as default.
Outage triage	Quick check that KEY_VAULT_MODE, AZURE_SERVICE_BUS_CONNECTION_STRING, or INGESTION_JOBS_ENABLED are configured the way the runbook expects, without container shell access.
Onboarding	Operators without direct K8s/ACA access can still sanity-check what's wired up.

Adding a new env var

1. Add a row to ENV_CONFIG_CATALOG with the right group, defaultValue, description, and an honest isSecret flag.

2. Run the catalog test:

   npx vitest run packages/platform-identity/src/routes/env-config-report.test.ts
   npx vitest run apps/admin-service/src/gateway/routes/env-config-catalog.drift.test.mjs

   The first guards redaction; the second keeps the catalog in step with the service config — duplicate keys and naively non-redacted "secret-shaped" names both fail.

3. Restart the running admin-service process. The viewer reflects the process.env snapshot at request time, so changes take effect on the next refresh.

What's out of scope

• Runtime-editable feature flags. The viewer is read-only by design. A flag-service item would be a separate scoped roadmap row.
• Other processes' env visibility. This page reports the running admin-service process only — not rcm-core, not edi-gateway. Confirm those via their own /health endpoints or container env inspection.
• Diff vs previous deploy. Would require persisting a startup snapshot — out of scope.

Validation

Check	Expected
Secret entries on the wire	value: null regardless of isSet
Non-secret entry under fallback default	value reflects catalog default
Catalog test	Green
Adding a new env var without catalog row	Visible in process.env but not in the page (intentional gating)

Cross-references

• Distributed tracing & alert response for log/trace IDs.
• Deployability + DR drill for how Bicep binds env values from Key Vault.
• PHI encryption at rest — uses several of the cataloged env vars.

Next

End of the runbook — return to the Operations overview.