Config visibility matrix

A config visibility matrix is a small table showing where each required setting is defined, loaded, masked, and verified across environments.

Many deploy bugs look like code bugs until configuration is checked. A value may exist in local `.env`, but not in preview. It may exist in the hosting settings, but not in the worker process. It may be present at build time but missing at runtime. It may be masked in logs, renamed during migration, or scoped to the wrong project. A matrix makes those differences visible.

A practical matrix has columns for config name, purpose, local source, CI source, preview source, production source, build-time visibility, runtime visibility, and last verified date. For secrets, the matrix should not store the value. It should store proof that the application can read it, such as a health check, a startup validation message, or a redacted diagnostics line.

The matrix is especially useful when an integration fails only after deploy. Payment keys, webhook secrets, object storage buckets, public site URLs, OAuth callbacks, and feature flags often differ by environment.

The goal is not documentation for its own sake. The goal is to answer one question quickly: is the app running with the setting it thinks it has?

Config visibility matrix deploy debugging 2026 06 25

// COMMENTS

ON THIS PAGE

Config visibility matrix deploy debugging 2026 06 25

// COMMENTS ↓ Newest First

ON THIS PAGE

// COMMENTS