Secrets & Environment Management
Pathrule2 Rules • 2 Memories • 1 Skill
A pattern bundle for handling API keys, tokens, and credentials safely across local development, CI, and production. It enforces .env hygiene, pushes teams toward a managed secret store with runtime injection and OIDC, and ships a review checklist so no credential ever lands in source control or a build log.
Suggested path map
Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.
/ workspace root
Never commit plaintext secrets
Secret storage tiers: local, CI, production
Rotation and least-privilege defaults
secrets-env-management-review
src/
Keep server secrets out of the client bundle
Rules
2Never commit plaintext secrets/roothighstrictReal credentials never enter the repo; only encrypted or example files are tracked.
| 1 | No file containing a live secret may be committed, and `.gitignore` must block every plaintext env file before the first commit. |
| 2 | |
| 3 | - Add `.env`, `.env.*`, and `.env.local` to `.gitignore`; track only `.env.example` with placeholder values. |
| 4 | - Commit secrets only when encrypted at rest, for example a `dotenvx`-encrypted `.env` or a `sops`-encrypted file where the decryption key lives outside the repo. |
| 5 | - Run `gitleaks` as a pre-commit hook and in CI so a staged secret is blocked before it reaches the remote. |
| 6 | - If a secret is ever pushed, treat it as compromised: rotate it immediately, then scrub history. Removing the commit is not enough. |
Keep server secrets out of the client bundle/srchighadvisoryOnly explicitly public-prefixed vars cross into client code; read secrets server-side only.
| 1 | Anything bundled for the browser is public, so server secrets must never be referenced from client-reachable modules. |
| 2 | |
| 3 | - Read secrets only in server code (route handlers, server actions, API layers, background jobs), never in components that ship to the client. |
| 4 | - Expose values to the client only through an intentional public prefix such as `NEXT_PUBLIC_`, `VITE_`, or `PUBLIC_`, and assume anything prefixed that way is world-readable. |
| 5 | - Validate the full env at startup with a typed schema (for example `zod`) so a missing or misnamed secret fails fast instead of surfacing as a runtime `undefined`. |
| 6 | - Never log a secret value or echo it into an error message, response body, or analytics event. |
Memories
2Secret storage tiers: local, CI, production/rootWhere secrets live and how they reach the app at each stage.
| 1 | Secrets flow through three tiers, and each has a distinct source of truth so no plaintext credential is shared by hand. |
| 2 | |
| 3 | - Local: developers keep an uncommitted `.env.local`, or pull from the team store with a CLI such as `doppler run`, `infisical run`, or `vault`. Share new keys via the store, never over chat. |
| 4 | - CI: the pipeline authenticates with GitHub OIDC to mint a short-lived cloud role instead of holding static keys. Vercel and similar platforms issue OIDC tokens with roughly a 60-minute TTL, so the long-lived key never exists in the environment. |
| 5 | - Production: a managed store (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, or the platform env UI) injects values at runtime. Prefer Vault dynamic secrets, which mint per-request credentials with a built-in TTL and auto-revoke, so there is nothing to rotate. |
| 6 | |
| 7 | See /.github/workflows for the OIDC pipeline wiring and /src for the runtime read and validation rules. |
Rotation and least-privilege defaults/rootLifetime, scoping, and revocation expectations for every credential.
| 1 | Every credential is scoped narrowly and has a known expiry, so a leak has a small blast radius and a short window. |
| 2 | |
| 3 | - Issue a distinct key per service or consumer; never share one key across apps, which makes revocation surgical instead of a fleet-wide outage. |
| 4 | - Grant least privilege: scope each key to the exact resources and actions it needs, read-only where possible. |
| 5 | - Set a rotation policy. Prefer dynamic or OIDC short-lived credentials so rotation is automatic; for unavoidable static keys, schedule rotation (for example AWS Secrets Manager rotation for RDS) and alert before expiry. |
| 6 | - Keep audit logging on at the store so every access (who, when, what) is traceable, and revoke immediately on offboarding or suspected exposure. |
Skills
1secrets-env-management-review/rootPre-merge checklist to confirm no secret leaks and env handling is sound.
| 1 | --- |
| 2 | name: secrets-env-management-review |
| 3 | description: Review checklist for any change that touches secrets, env vars, CI credentials, or config. Run before merging to confirm no credential leaks into git, logs, or the client bundle. |
| 4 | --- |
| 5 | |
| 6 | # Secrets & environment management review |
| 7 | |
| 8 | - [ ] No plaintext secret is added to a tracked file; `.env`, `.env.*`, and `.env.local` are in `.gitignore`. |
| 9 | - [ ] Only `.env.example` (placeholder values) or an encrypted env file (`dotenvx`/`sops`, key stored outside the repo) is committed. |
| 10 | - [ ] `gitleaks` runs as a pre-commit hook and in CI, and the diff passes a secret scan. |
| 11 | - [ ] Secrets are read server-side only; nothing sensitive is exposed via a public prefix (`NEXT_PUBLIC_`, `VITE_`, `PUBLIC_`). |
| 12 | - [ ] Env is validated at startup with a typed schema so missing or misnamed vars fail fast. |
| 13 | - [ ] No secret value is logged, returned in a response, or sent to analytics. |
| 14 | - [ ] CI authenticates via OIDC for short-lived cloud roles instead of storing long-lived static keys. |
| 15 | - [ ] Production reads secrets from a managed store with runtime injection, not a baked-in build artifact. |
| 16 | - [ ] Each new credential is least-privilege, distinct per consumer, and has a rotation policy or short TTL. |
| 17 | - [ ] Any previously exposed secret has been rotated, not just deleted from history. |
Why this pattern
Secrets keep leaking into commits, build logs, and client bundles because there is no enforced convention for where credentials live or how they reach runtime.
Built for Backend and platform teams shipping services with API keys, database credentials, and CI/CD pipelines..
Keeps your assistant from:
- Committing a real .env file or hardcoded API key to git history
- Leaking server-side secrets into a client bundle via the wrong env prefix
- Long-lived static cloud keys sitting in CI with no rotation or expiry
- License
- Apache-2.0
- Version
- 1.0.0
- Updated
- 2026-06-09