Environment Variable Inventory Checker

Introduction:

Configuration drift is often invisible until a service boots with the wrong assumptions. The code may expect DATABASE_URL, the container image may define a default, the deployment manifest may reference a Secret, and a temporary shell may still carry yesterday's value. An environment variable inventory turns that scattered configuration into a reviewable contract: these names are required, this snapshot appears to provide them, and these entries still need correction before the release depends on them.

Environment variables are small name-value pairs supplied by a shell, operating system, container runtime, build system, or orchestrator. They are commonly used for service endpoints, credentials, runtime modes, feature flags, public build settings, and per-deploy hostnames. Their appeal is portability: the same application code can run in development, staging, and production while the surrounding environment changes. The tradeoff is that the environment becomes a moving target unless teams keep a clear list of expected names and compare it with the source being deployed.

A useful inventory review separates name coverage from value correctness. A required name can be present but blank, repeated, filled with placeholder text, or populated by a reference to another system. Those states are different. Missing and blank entries usually block a deployment, placeholders suggest copied template text, references need follow-up in the secret or config store, and duplicates need runtime-specific precedence checks.

Inventories are most valuable before risky changes: a database migration, a new container image, a secret rotation, a disaster-recovery exercise, or a move from one deployment system to another. These are the moments when a name can be renamed in one place, left blank in another, or overridden by a higher-precedence source. The review does not replace a live smoke test, but it gives the team a compact map of configuration work that should happen before the smoke test becomes the first warning.

Values also need care even when they are not displayed. Variable names can reveal architecture, and raw pasted text may contain credentials. A good inventory habit is to redact or summarize values in shared evidence, keep raw snapshots private, and verify references in the system that owns the actual secret or configuration key.

How to Use This Tool:

Start with one required-variable list and one environment snapshot. The result is meant to support a release review, so keep the label and pasted source narrow enough that teammates know exactly which service and environment were checked.

1. Enter an Environment label such as worker-api production, billing staging, or a deployment ticket reference. The label appears in generated audit evidence and the remediation stub.
2. Paste the expected names into Required variables. Plain names, KEY= rows, KEY: value rows, export KEY=value, and declare -x KEY=value are accepted for requirement parsing.
3. Paste the observed snapshot into Current inventory, choose a supported text, JSON, YAML, or environment file with Browse file, or drop a file onto the textarea.
   Selected files must be under 1 MiB. The file contents are loaded into the textarea before analysis, so remove secrets from the raw source before sharing your screen or browser history.
4. Leave Blank required values set to Block blanks for deployment checks. Switch to Allow blanks only when the application deliberately treats an empty string as a valid value.
5. Open Advanced when the inventory came from mixed documentation, includes intentional public prefixes, or needs stricter placeholder and sensitive-name rules. Use exact matching for real runtime checks unless you have a specific reason to compare names case-insensitively.
6. Use Load template, Passing sample, and Review sample to inspect the accepted shapes. Use Normalize after parsing looks correct if you want a sorted KEY=value snapshot from the last parsed value for each name.
   If a Requirement syntax or Inventory syntax warning appears, fix the named line before trusting the coverage percentage.
7. Read the summary and blocker alert first. Then check Requirement Audit for each required name, Variable Inventory for extras and flags, Risk Briefing for next actions, and Coverage Breakdown for the set/reference/placeholder/empty/missing count.

Interpreting Results:

The primary status reports blockers when required names are missing or blank under the current blank-value setting. When no blocker exists, the status reports coverage for required names that are either set or populated by a reference. Placeholder, empty, and missing required names do not count as ready coverage.

• Missing means no parsed current entry matched the required name.
• Empty means the name exists but the final parsed value is an empty string.
• Placeholder means the value matches built-in or configured placeholder patterns such as changeme, todo, example, ${TOKEN}, or <SECRET>.
• Reference means the inventory points to another config or secret source. It counts as coverage, but the referenced value still needs its own check.
• Extra means the name is outside the required list and does not begin with an allowed extra prefix.
• Secret-like means the variable name contains a configured sensitive token such as SECRET, TOKEN, KEY, PASSWORD, PRIVATE, DSN, DATABASE_URL, or REDIS_URL.

A 100% coverage result is not proof that the live service is safe. It only means every required name in the pasted requirement list is either set or referenced in the observed snapshot. Confirm that the snapshot came from the target environment, that referenced Secrets or ConfigMaps contain the intended keys, and that duplicates resolve the same way in the actual runtime.

Use the Risk Briefing as the fix list. Blockers should be fixed before deployment, warnings should be reviewed before evidence is shared, and review items should be either removed, allowed, or documented. The JSON view is useful only after the visible tables match the source you meant to audit.

Technical Details:

Environment variable names in shell-oriented workflows usually use letters, digits, and underscores, with a letter or underscore as the first character. That conservative pattern keeps names portable across common command-line and deployment tooling, but it is stricter than every possible platform-specific key format. A name that falls outside that pattern is treated as malformed for this review rather than silently becoming part of the required set.

The comparison has three separate jobs: parse names from the required list, parse current entries from the observed inventory, and classify each required name by the last parsed current value under the selected matching mode. Exact matching is the default because environment names are normally case-sensitive. Case-insensitive review is available for messy documentation or hand-written lists, but it should not be used to excuse casing drift in an actual runtime source.

Transformation Core

The input transformation is intentionally small enough to audit. It recognizes common environment-file, shell, JSON, YAML, and Kubernetes-style shapes, then reduces them to variable names, source-line evidence, value states, and review flags.

Rule Core

Severity depends on what the value state implies for a deployment review. The same parsed row can also carry flags for duplicates, lowercase names, extra variables, allowed extra prefixes, or secret-like names.

Formula Core

Coverage measures required-name readiness only. It ignores extra variables, sensitive-name review items, syntax warnings, chart rows, and export availability.

If six required names are listed, four are set, one is a reference, and one is missing, coverage is (4 + 1) / 6 x 100, or 83.3% before the summary rounds it for display. The missing name still appears as a blocker even if every extra or secret-like review item has already been addressed.

The remediation stub is built from missing, empty, and placeholder required names, sorted alphabetically. It is a starter edit list for the next configuration change. It does not know the correct values, and it does not include duplicate, extra, lowercase, or secret-like review items unless those names are also missing, blank, or placeholder-like required variables.

Advanced Tips:

• Keep Variable matching on exact names for runtime evidence. Use case-insensitive review only to reconcile rough documentation before fixing the casing in the real source.
• Add allowed extra prefixes for intentional client-visible build variables such as NEXT_PUBLIC_ and VITE_, but avoid using broad prefixes that hide unrelated deployment drift.
• Tune Placeholder tokens for local conventions such as local-only or ask-devops when those values should never pass a release review.
• Use the Sensitive name pattern to flag names that imply credentials in your environment. It flags names only; it does not inspect or reveal the secret value.
• Run Normalize after syntax warnings are fixed. The normalized text uses the last parsed value per name, so it should not be treated as proof of runtime precedence.

Limitations and Privacy Notes:

The review runs against the pasted or loaded text in the browser. It does not query a running process, inspect a cluster, fetch a Secret, read a ConfigMap, or confirm which source the application reads during startup.

• Set values are redacted in result rows and generated evidence, but the original textarea still contains the raw text you supplied.
• Environment labels, variable names, source lines, and reference names can reveal architecture even when values are hidden.
• Do not share raw snapshots, normalized inventory text, page addresses, screenshots, or exported evidence without checking whether names and labels are sensitive.
• Secret and ConfigMap references require a separate check in the target environment before they can be treated as release-ready.

Worked Examples:

These examples use the checker behavior that matters most in release reviews: missing names, placeholder values, references, and parser warnings.

FAQ:

Glossary:

Required name

A variable name that the application, release checklist, or template expects to exist.

Observed inventory

The pasted or loaded environment snapshot being compared with the required names.

Value state

The redacted classification of a parsed value, such as set, empty, placeholder, missing, or reference.

Placeholder

A value that looks like example text, change-me text, or a token marker rather than a deployment-specific value.

Reference

An entry showing that the variable is populated from another config or secret source.

Allowed extra prefix

A configured prefix that marks non-required variables as intentional extras.

Secret-like name

A variable name whose tokens suggest credentials, keys, tokens, database URLs, DSNs, or other sensitive configuration.

Remediation stub

A starter environment list for required names that were missing, blank, or placeholder-like.

References:

• III. Config, The Twelve-Factor App, last updated 2017.
• Environment variables in Compose, Docker Docs.
• Environment variables precedence in Docker Compose, Docker Docs.
• Define Environment Variables for a Container, Kubernetes Documentation.
• Secrets Management Cheat Sheet, OWASP Cheat Sheet Series.
• How to set environment variables in Linux command line, simplified.guide.
• How to use an env file with Docker Compose, simplified.guide.