Environment Variable Inventory Checker
{{ result.primary }}
{{ result.summaryLine }}
{{ badge.label }}
Use a label that will make exported audit rows clear to teammates.
Accepts KEY, KEY=, export KEY=value, and commented .env.example lines.
{{ requirementHint }}
Paste the environment snapshot you want to compare against the required list.
{{ fileStatus || 'Drop .env, JSON, YAML, or TXT onto the textarea.' }}
{{ fileError }}
Recommended for deployment checks because an empty string often behaves like a missing variable.
Keep exact matching unless your source inventory is known to mix cases inconsistently.
Use this for public build-time prefixes such as NEXT_PUBLIC_ or VITE_.
Sensitive values stay redacted; this only adjusts risk flags and briefing rows.
One token per line. The default set catches common example, change-me, and local-only placeholders.
Flags naming drift without blocking the missing-variable inventory result.
Variable Status Value state Source Detail Copy
No required variables parsed yet.
{{ row.key }} {{ row.status }} {{ row.valueState }} {{ row.source }} {{ row.detail }}
Variable Required Value state Source lines Flags Copy
No environment variables parsed yet.
{{ row.key }} {{ row.required }} {{ row.valueState }} {{ row.sourceLines }} {{ row.flags }}
Severity Check Evidence Next action Copy
{{ row.severity }} {{ row.check }} {{ row.evidence }} {{ row.nextAction }} 
{{ result.remediationStub }}

        

      

    

  

                

                

                    

                        

                            Tags: Devops, Devtools, Shell
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


                    
        

        

        

            

            
        

        


                                                                                                                                                                                                                                                        
        

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
        

    

    

        

  

    

    
Environment variable inventory review compares the variables an application expects with the variables that are actually present in a deployment snapshot. It is useful before a release, migration, incident fix, or secrets rotation because a single missing database URL, blank token, duplicate flag, or example value can make a service start with the wrong settings or fail only after traffic reaches it.


    
Environment variables are a common way to keep deploy-specific configuration separate from application code. They often carry resource handles, feature flags, service endpoints, and credentials. That flexibility also makes drift easy to miss when one list lives in a template, another lives in a container configuration, and another lives in a Kubernetes manifest or secret store.


    

      Environment variable inventory flow from required keys and current inventory through parsing, redaction, audit findings, and remediation output
      
A useful inventory check keeps required names, parsed source rows, redacted value states, and remediation work separate before deployment review.

    


    
A useful inventory does not need to expose actual secret values to answer the first release question. The important first pass is whether each required name exists, whether it has a usable value or a referenced secret source, and whether the current inventory contains suspicious extras or duplicate definitions. Values may still matter to the application, but the audit can usually start with names, line evidence, and redacted value state.


    
An inventory check is not a live deployment test. It cannot prove that the running service reads the same source, that a secret store contains the intended value, or that a framework's loader chooses the same duplicate value a human expects. Treat the result as a preflight review that tells you what to fix or verify before the release path depends on those variables.

  






  

    
Technical Details:


    
Environment variables are name-value entries supplied by the operating system, shell, container runtime, or orchestrator. Names are usually treated as exact identifiers. This checker uses a conservative shell-style name rule: a variable starts with a letter or underscore and then uses letters, digits, or underscores. That means names such as APP_ENV and DATABASE_URL parse cleanly, while names beginning with a digit are rejected as invalid inventory or requirement rows.


    
The review has two inputs. The required list represents the contract the application or release expects. The current inventory represents one observed deployment source. Required lines can be plain names, assignment-style names, exported names, or commented template-style rows. Inventory text can come from assignment lines, shell export output, simple YAML key-value rows, Kubernetes-style name and value entries, reference entries, or JSON objects and arrays with recognizable variable names.


    
Values are used only to classify state. Set values become redacted character counts in audit rows. Empty strings become Empty, placeholders become Placeholder, and Kubernetes-style references become Reference. When the same name appears more than once, the row stays visible as a duplicate because different loaders and humans may disagree about which definition is effective.


    
Rule Core

    
The checker builds a requirement audit from parsed required names and a variable inventory from parsed current names. Matching is exact by default, with a case-insensitive review mode for messy documentation sources that mixed name casing.


    

      

        
        
          

            Signal
            Trigger
            Review Meaning
          

        
        
          

            Missing required variable
            A required name is absent from the current inventory.
            Deployment should stop until the key is supplied or the requirement list is corrected.
          

          

            Blank required value
            The name exists with an empty value and blank values are treated as blockers.
            An empty string often behaves differently from a missing setting, so confirm whether it is intentional.
          

          

            Placeholder value
            The value resembles changeme, example, your_value_here, ${TOKEN}, or another configured placeholder token.
            Replace template values with environment-specific values before relying on the inventory.
          

          

            Duplicate definition
            The same parsed name appears more than once under the selected matching mode.
            Remove the duplicate or document which source wins in the actual loader.
          

          

            Extra variable
            A parsed current variable is not in the required list and does not match an allowed extra prefix.
            Confirm whether it belongs to another service, a removed feature, or an intentional runtime setting.
          

          

            Secret-like name
            The name contains a configured sensitive token such as SECRET, TOKEN, KEY, PASSWORD, DSN, or a database/cache URL token.
            Verify that the value comes from the approved secret path and is not logged, committed, or copied into a casual handoff.
          

          

            Lowercase name
            Lowercase characters appear while lowercase warnings are enabled.
            Review naming drift unless the runtime or framework intentionally requires that exact lowercase name.
          

        
      

    


    
Coverage Core

    
Coverage counts required variables that are either set or populated by a reference. Missing, blank, and placeholder required values do not count as ready.


    

      
        
          Coverage
          =
          
            
              Set required variables
              +
              Referenced required variables
            
            Total required variables
          
          ×
          100
        
      
    


    

      

        
        
          

            Value State
            Coverage Treatment
            Typical Follow-up
          

        
        
          

            Set
            Counts as ready.
            Confirm the source is the intended deployment source when the name is sensitive.
          

          

            Reference
            Counts as ready.
            Check the referenced ConfigMap, Secret, or secret provider outside the inventory text.
          

          

            Missing
            Does not count as ready.
            Add the key to the target environment or remove it from the requirement list if it is obsolete.
          

          

            Empty
            Does not count as ready when the blank-value blocker is enabled.
            Set a non-empty value or intentionally allow blanks only when the application accepts them.
          

          

            Placeholder
            Does not count as ready.
            Replace the template value with a deployment-specific value.
          

        
      

    


    
Parsing is deterministic and local to the browser page. The checker does not run a shell, query a deployment target, fetch a secret, or inspect repository history. It reviews the text or selected file you provide, redacts values in exported result rows, and produces tables, chart data, a remediation stub, and JSON from that supplied snapshot.

  






  

    
Everyday Use & Decision Guide:


    
Start by giving Environment label a value that would make sense in a release note, such as worker-api production or billing staging. The label does not change matching, but it keeps copied rows, downloaded files, and JSON tied to the environment being reviewed.


    
Paste the expected names into Required variables. A template with one name per line is ideal, and assignment-style rows are fine because matching ignores values in the required list. Then paste the observed source into Current inventory, browse for a small text file, or drop a supported text, JSON, YAML, or environment file onto the textarea.


    
    
      
  • Leave Treat blank required values as blockers on for deployment review unless the application deliberately uses empty strings.
    • 
      
  • Keep Variable matching set to exact names for real runtime checks. Use case-insensitive review only when reconciling rough notes from mixed documentation sources.
    • 
      
  • Use Allowed extra prefixes for public build-time names such as NEXT_PUBLIC_ or VITE_ so intentional extras do not crowd the cleanup list.
    • 
      
  • Adjust Sensitive name pattern when your organization uses different secret naming conventions.
    • 
      
  • Add organization-specific example tokens under Placeholder tokens when templates use names beyond the default change-me and sample set.
    • 
    


    
The first useful read is the summary box and any blocker alert. Then open Requirement Audit to see required names, status, value state, source line, and detail. Variable Inventory is better for cleanup because it shows extras, lowercase names, duplicate entries, secret-like names, and source lines across the parsed inventory.


    
Risk Briefing is the handoff view for release review. It separates blockers from warnings and review items, with evidence and a next action for each finding. Coverage Breakdown is a quick chart of set, reference, placeholder, empty, and missing required variables. Remediation Stub gives a starter list of missing, blank, and placeholder required keys so the next edit does not start from memory.


    
Do not read a fully covered result as proof that the application will start correctly. It means the pasted inventory matched the required names under the current settings. Before deployment, check any referenced secret source, confirm duplicate handling in the real loader, and keep redacted audit exports with the release record rather than copying raw values into chat or tickets.

  






  

    
Step-by-Step Guide:

    
Use one expected list and one observed inventory per run so the summary, tables, chart, stub, and JSON describe the same environment.

    
    
      
  1. Enter a recognizable Environment label. Confirm the same label appears in the JSON profile before using the result as release evidence.
    2. 
      
  2. Paste required names into Required variables, or click Load template to see the expected one-name-per-line shape. Use Sort names when you want the requirement list easier to scan.
    3. 
      
  3. Paste the observed environment text into Current inventory, click Browse file, drop a supported file onto the textarea, or load the passing or review sample to inspect the output model.
    4. 
      
  4. Click Normalize only after the parsed rows look right. It rewrites the current inventory into sorted KEY=value lines from the parsed entries.
    5. 
      
  5. Set Treat blank required values as blockers before judging the result. When it is enabled, blank required values appear as blocker findings.
    6. 
      
  6. Open Advanced if you need case-insensitive review, allowed extra prefixes, a custom sensitive-name pattern, custom placeholder tokens, or lowercase-name warnings.
    7. 
      
  7. If a file error or syntax warning appears, fix the malformed line before relying on the summary. Invalid requirement names and unrecognized assignment rows can hide the review you meant to run.
    8. 
      
  8. Read Requirement Audit for required-name readiness, then open Risk Briefing for blocker, warning, and review rows.
    9. 
      
  9. Use Remediation Stub for the next configuration edit and JSON for structured handoff only after the table rows match the source snapshot you intended to check.
    10. 
    

    
Finish by clearing missing, blank, and placeholder required variables first. Then review duplicate definitions, secret-like names, and extra variables before attaching any redacted evidence to the release record.

  






  

    
Interpreting Results:


    
The headline number reports either blocker count or coverage percentage. Blockers mean required variables are missing or blank under the current blank-value setting. Coverage reports how many required variables are set or referenced, but it does not inspect whether the value itself is correct.


    
    
      
  • Missing and blocker-level Empty rows should be fixed before deployment because the required name is not usable in the supplied snapshot.
    • 
      
  • Placeholder rows mean the key exists but still looks like template data. Replace them before treating coverage as ready.
    • 
      
  • Reference rows count as ready only for inventory coverage. They still need a separate check of the referenced secret or config source.
    • 
      
  • Extra rows do not always mean danger. They may be public build-time variables, old flags, or settings for a neighboring service.
    • 
      
  • Secret-like rows are review prompts. They tell you to check handling and storage, not to expose the value.
    • 
    


    
Duplicates deserve extra care. The checker keeps duplicate definitions visible and uses the parsed entry evidence for the result, but the effective runtime value depends on the loader, orchestrator, shell, or file merge that finally supplies the environment. Remove duplicates when possible so the release record and runtime behavior agree.


    
A clean result can still be wrong if the wrong environment snapshot was pasted, if the application reads another source at runtime, or if a secret reference points to an empty value outside the text being reviewed. When a result looks unexpectedly good, inspect the inventory table, source lines, and JSON counts before copying the audit into a ticket.

  






  

    
Worked Examples:


    
Review sample before a production deploy

    
The review sample expects APP_ENV, DATABASE_URL, REDIS_URL, SENTRY_DSN, FEATURE_PAYMENTS, and PUBLIC_APP_ORIGIN. Its inventory leaves REDIS_URL blank, keeps SENTRY_DSN=changeme, repeats FEATURE_PAYMENTS, includes EXTRA_DEBUG, and has a lowercase local name. With blank required values treated as blockers, the summary reports blockers, Requirement Audit shows PUBLIC_APP_ORIGIN as missing and REDIS_URL as empty, and Risk Briefing separates the missing, blank, placeholder, duplicate, extra, secret-like, and lowercase findings.


    
Passing inventory that still has secret handling to verify

    
The passing sample provides all six required names with non-empty values, so Coverage Breakdown can reach full required-variable coverage. The result can still include a Secret-like names present review row for names such as DATABASE_URL, REDIS_URL, and SENTRY_DSN. That is the correct outcome for a release note: the names are present, and the next check is whether those values come from the approved secret path.


    
Kubernetes reference instead of visible value

    
A manifest snippet with - name: DATABASE_URL followed by valueFrom: is parsed as a reference. In Requirement Audit, the value state becomes Reference and counts toward coverage because the variable is intentionally populated from another source. The follow-up is outside the inventory text: confirm that the referenced Secret or ConfigMap key exists in the target namespace and contains the intended value.


    
Troubleshooting a malformed requirement line

    
A required list line such as 1BAD_NAME=value does not start with a valid variable name, so it becomes a requirement syntax warning rather than a required row. The summary may look better than expected because the malformed name was not counted as required. Rewrite it as a valid name, rerun the review, and confirm the required count badge matches the number of keys the release expects.

  






  

    
FAQ:


    

      Which source formats can I paste?
      
You can paste plain KEY=value rows, shell export or declare output, simple YAML key-value rows, Kubernetes-style environment entries, or JSON objects and arrays with recognizable variable names.

    


    

      Are actual values shown in the result tables?
      
No. Set values are redacted in result rows and exports, while empty, placeholder, and reference states are reported. Variable names, source lines, and the source text on your workstation can still be sensitive.

    


    

      Why is a blank value treated as a blocker?
      
Many deployment checks treat an empty string as unusable because the application may require a real endpoint, token, or flag value. You can turn off the blocker when an empty string is intentionally valid for that variable.

    


    

      Why did a duplicate variable appear when the last value is probably used?
      
Duplicate definitions are risky because the effective value depends on the shell, file merge, container runtime, or orchestrator path. The checker keeps duplicates visible so you can remove the ambiguity or document the actual winning source.

    


    

      Why are public build variables listed as extras?
      
A current variable that is not required is marked extra unless its name starts with an allowed extra prefix. Add prefixes such as NEXT_PUBLIC_ or VITE_ when those names are intentional for your frontend build.

    


    

      Does full coverage mean the deployment is safe?
      
No. Full coverage means every required name was set or referenced in the supplied snapshot. You still need runtime testing, referenced secret checks, and application-specific validation before depending on the deployment.

    

  






  

    
Glossary:


    

      
Required variable

      
A variable name the application or release checklist expects to exist in the target environment.

      
Current inventory

      
The pasted or loaded snapshot of names and values being compared with the required list.

      
Value state

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

      
Placeholder

      
A value that looks like template data, example text, or a change-me token instead of a deployment-specific value.

      
Reference

      
An entry showing that the variable is populated from another configuration or secret source rather than an inline value.

      
Allowed extra

      
A current variable outside the required list that matches a configured prefix and should not be treated as cleanup noise.

      
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 containing required keys that were missing, blank, or placeholders in the current review.

    

  






  

    
References: