# Fix missing Doppler environment keys before you deploy

> Open one console to see every secret name across your Doppler environments, copy missing keys into place, and freeze production before you ship.

- Workflow type: app
- Services: Doppler, GitHub
- Categories: Engineering, Operations
- Published: 2026-08-21

## What it does

- See every secret name in a single grid, with your environments across the top and a clear present or missing mark in each cell, so gaps are obvious at a glance
- Catch keys your code needs that no environment has, by scanning your repositories for environment variable references and comparing them against what is actually configured
- Fix problems without leaving the page: copy a missing key into an environment, freeze production, spin up a preview environment, or create a scoped deploy credential
- Press Pre-flight this release and a background agent writes a go or no-go verdict naming exactly which keys to add before shipping

## What you'll need

- A Doppler account with access to the project you want to check
- A GitHub login with read access to the repositories your code lives in
- The names of the environments you compare before a release, such as staging and production

## Prompt

Build me a console I open before every release to check that a Doppler project's environments line up, and to repair the gaps in place. The failure I keep hitting is a deploy breaking on a key that exists in staging and on everyone's laptop but was never added to production, and I only find out during rollout.

Main screen. A project picker at the top, filled from Doppler List Projects. Once I pick a project, load its configs with Doppler List Configs and, for each config, pull its keys with Doppler List Secret Names. Render a parity grid: secret names down the left side, configs across the top, and each cell showing present or missing so gaps are obvious at a glance. Hard rule for the whole app: never display a secret value anywhere, only names and presence.

Above the grid put a summary strip with the number of keys, the number of mismatched rows, and the number of keys the code requires that no config has. Controls: a filter to show only mismatched rows, a search box for key names, and a toggle for whether keys marked environment specific are shown. Show each config's lock state as a badge on its column heading.

Code reference check. In settings let me list the GitHub organization or repositories to scan. A Scan code references action runs GitHub Search Code across those repositories for environment variable references, covering the common shapes such as process.env.NAME, os.environ, ENV lookups and import.meta.env, and extracts the key names. Diff that list against the union of keys across all configs. Keys referenced in code but present in no config get their own flagged section pinned above the grid, each showing the repository and file path where it was found and linking out to GitHub. This is the part that catches the missing-key deploy break before it happens rather than during rollout. Cache the scan result with a timestamp so it does not rerun on every page load, and give me a manual refresh.

Recent changes. Read Doppler List Config Logs for each config and show a recent activity panel with who changed what and when, newest first, with production called out so I can see who touched it last. Clicking a config heading opens that config's full change history.

Fix-it actions from the grid. Clicking a missing cell opens an Add to this config dialog with two ways to fill the key: type a value into a masked input, or copy the value from another config in the same project. The copy path must run entirely inside the server handler, reading from the source config and writing with Doppler Update Secrets, so the value never reaches the browser and is never logged. A config heading menu offers Doppler Lock Config to freeze that environment once it looks right and Doppler Unlock Config to release it afterwards. A Create branch config action uses Doppler Clone Config to spin up a preview environment from an existing config, asking for the new name and the source. A Mint deploy credential action uses Doppler Create Service Token scoped to that config, asking for a name and access level; show the resulting token once in the dialog with a copy button and never store it or display it again.

Intentional differences. Let me mark any row as intentionally environment specific with an optional note. Persist that per project and key inside the app. Marked keys stop being reported as drift forever: they drop out of the mismatched filter, out of the summary counts, and out of the readiness verdict. Give them a separate Ignored keys view listing each mark with its note so I can review or undo them.

Pre-flight this release. Add a button that kicks off a background agent for the selected project. The agent pulls the configs and their secret names, runs the GitHub code reference search, reads the recent config logs, applies my environment specific exclusions, and writes a go or no-go readiness verdict back into the app. The verdict has to list the exact keys to add and which config each one is missing from, call out recent production changes worth a second look, and state the reason for any no-go. Land it in a Readiness panel that keeps a run history so I can compare this release against the last one, and show a pending state in the panel while the agent is working.

Persist across sessions: the environment specific marks and their notes, the repositories to scan, the last code scan with its timestamp and results, and the history of pre-flight verdicts.

## How to customize

- Choose which repositories get scanned for environment variable references
- Mark keys that are meant to differ between environments so they stop being reported as gaps
- Decide which environment counts as production for the freeze and readiness checks

## FAQ

### Does this show my secret values?

No. The grid shows secret names and whether each one is present or missing in each environment, and nothing else. Values are never displayed anywhere in the app. When you copy a key from one environment into another, that happens behind the scenes and the value never appears on screen.

### How does it know which keys my code actually needs?

It searches the repositories you point it at for the places your code reads an environment variable, collects those names, and compares them against what each environment provides. Anything your code references but no environment has is flagged at the top of the grid, with a link to the file where it was found.

### Some keys are supposed to be different in each environment. Will they always show as problems?

Only until you mark them. Any row can be marked as intentionally environment specific with a short note, and from then on it stops counting as a gap and drops out of the mismatch filter and the readiness verdict. Marked keys live in their own list so you can review or undo them later.

### Can I fix things from the app, or do I have to go back to Doppler?

You can fix them here. From the grid you can copy a missing key into an environment, freeze production while you ship and unfreeze it afterwards, create a preview environment from an existing one, and generate a deploy credential scoped to a single environment.

### What does the Pre-flight button actually do?

It starts a background check that compares your environments, looks at what your code needs, reads the recent change history, and writes a short go or no-go verdict into the app listing the exact keys to add before you ship. Past verdicts are kept so you can compare this release against the last one.

### Can I see who changed production last?

Yes. The app reads the recent change history for each environment and shows who made each change and when, with production called out. Click any environment heading to see its full history.

Use this prompt in General Input: https://www.generalinput.com/prompts/fix-missing-doppler-environment-keys-before-you-deploy