Two tiny deployment drift bugs: env vars added, templates forgotten

A small deployment failure pattern I keep seeing:

1. A config file starts using a new environment variable or secret.


2. The repo's .env.example or .env.dist is not updated.


3. The mismatch is discovered later, usually during a deploy job, local preview, worker boot, or production config check.

The bug is rarely dramatic in code review. It can be as small as one extra variable in CI/CD or Docker config.

Example 1: GitHub Actions secret drift

A workflow starts using a new secret:

env:

  DATABASE_URL: ${{ secrets.DATABASE_URL }}

  STRIPE_SECRET_KEY: ${{ secrets.STRIPE_SECRET_KEY }}

But the env template only documents this:

NEXT_PUBLIC_APP_URL=https://example.com

DATABASE_URL=

Now STRIPE_SECRET_KEY has become an undocumented deployment requirement.

Run the demo fixture with Secret Coverage:

pnpm dlx @leviro-ai/secret-coverage scan --path examples/demos/github-actions-missing-secret --ci

In the repo itself, the equivalent dev command is:

pnpm scan -- --path examples/demos/github-actions-missing-secret --ci

Expected output:

# Secret Coverage Report



Readiness score: **73/100**



Critical: 1 · Warning: 0 · Info: 1



## Critical



- **STRIPE_SECRET_KEY** — STRIPE_SECRET_KEY is used in .github/workflows/deploy.yml but missing from an env template.

  - Context: `.github/workflows/deploy.yml` · `missing-from-template`

  - Fix: Add STRIPE_SECRET_KEY= to an env template and configure the value in your deployment environment.

Example 2: Docker Compose runtime drift

The same thing can happen outside CI. A Compose file starts expecting Redis:

services:

  web:

    environment:

      APP_ENV: ${APP_ENV}

      DATABASE_URL: ${DATABASE_URL}

      REDIS_URL: ${REDIS_URL}



  worker:

    environment:

      REDIS_URL: ${REDIS_URL}

But .env.example only documents:

APP_ENV=production

DATABASE_URL=

Now both the web service and worker depend on REDIS_URL, but the repository contract does not say so.

Run the demo fixture:

pnpm dlx @leviro-ai/secret-coverage scan --path examples/demos/docker-compose-missing-redis-url --ci

Expected output:

# Secret Coverage Report



Readiness score: **71/100**



Critical: 1 · Warning: 0 · Info: 2



## Critical



- **REDIS_URL** — REDIS_URL is used in docker-compose.yml but missing from an env template.

  - Context: `docker-compose.yml` · `missing-from-template`

  - Fix: Add REDIS_URL= to an env template and configure the value in your deployment environment.

That is deployment drift: deployment/runtime config expects something the repository's declared env contract does not describe.

The point is not to read or expose secret values. The check only compares metadata:

• variables documented by env templates;


• variables referenced by CI/CD, Docker, and config files;


• mismatches that should be fixed before deployment.

A minimal fix is to update the env template:

# GitHub Actions example

NEXT_PUBLIC_APP_URL=https://example.com

DATABASE_URL=

STRIPE_SECRET_KEY=



# Docker Compose example

APP_ENV=production

DATABASE_URL=

REDIS_URL=

Then configure the real values in GitHub Actions secrets, Docker/Compose runtime environment, or the deployment platform.

This is especially useful when AI-assisted PRs update application code and config quickly, because env contracts are easy to forget during review.

Secret Coverage is local-first and deterministic. It is not a vault and it does not need a cloud account for this check.

Links:

• npm: https://www.npmjs.com/package/@leviro-ai/secret-coverage
  


• GitHub: https://github.com/leviro-ai/secret-coverage
  


• GitHub Actions demo: https://github.com/leviro-ai/secret-coverage/tree/main/examples/demos/github-actions-missing-secret
  


• Docker Compose demo: https://github.com/leviro-ai/secret-coverage/tree/main/examples/demos/docker-compose-missing-redis-url