← DeployCloud

Secrets Management Guide

Every app accumulates secrets — database URLs, Stripe keys, webhook signing secrets, LLM API keys — and the most common breach is still the dumbest one: a .env file committed to a public repo.

The rule that prevents it: secrets live in a platform store and reach code as runtime environment variables, and humans see production values as rarely as possible.

Use the platform's store

Every deploy target has a native vault: wrangler secret put encrypts values for Cloudflare Workers (never put secrets in wrangler.toml), Vercel and Netlify scope env vars per environment, AWS offers Secrets Manager with managed rotation alongside the simpler SSM Parameter Store, GCP has Secret Manager and Azure has Key Vault. Grant runtime identities read access to exactly the secrets they need — and never bake values into container images or client bundles.

💬 Chat with our AI →

Local development and team sync

Keep .env gitignored and commit a .env.example listing names without values. For teams, a sync service — Doppler, Infisical, or 1Password with op run — injects values at process start, so laptops stop accumulating stale keys and offboarding actually revokes access. Use separate credentials per environment; a dev key that can reach production data is a breach waiting for a typo.

💬 Chat with our AI →

CI/CD without long-lived keys

Store pipeline secrets in your CI's encrypted store — GitHub Actions secrets are masked in logs — but prefer eliminating them: OIDC federation lets GitHub Actions mint short-lived credentials directly from AWS, GCP or Azure on every run, so there is no permanent deploy key to steal. Scope deploy tokens to a single project, and rotate anything a departing teammate could have seen.

💬 Chat with our AI →

Leaks and rotation

Turn on GitHub push protection and run gitleaks or trufflehog in pre-commit and CI. When a secret leaks, rotate it immediately and audit its recent usage — rewriting git history is cleanup, not remediation, because clones already exist. Prefer short-lived credentials wherever a provider offers them, and put calendar rotation on the high-value keys that cannot be short-lived.

💬 Chat with our AI →

Frequently asked questions

Is committing .env.example safe?

Yes — it lists variable names and dummy placeholders only. It documents configuration without exposing values, and pairs with a gitignored .env.

Are NEXT_PUBLIC_ or VITE_ variables secret?

No. Anything prefixed for the client ships in the JavaScript bundle and is readable by every visitor. Only server-side variables stay secret.

What do I do the moment a key leaks?

Rotate it first, then audit provider logs for misuse, then scrub the repo. Treat every leaked value as copied, even if it was public only briefly.

Secrets Manager or Parameter Store on AWS?

Parameter Store covers most app configuration simply; Secrets Manager adds managed rotation and cross-account access for databases and high-value credentials.

💬 Chat with our AI →

💬 Chat with our AI →

Generate a blueprint free →

Explore the full desk on the home page →