Environment separation and configuration management for production applications. Use when: setting up dev/staging/production environments, managing environment variables, configuring secrets, adding feature flags, or deploying across environments.
From cksnpx claudepluginhub cardinalconseils/claude-starter --plugin cksThis skill is limited to using the following tools:
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Builds scheduled AI agents to scrape public websites/APIs, enrich data with Gemini Flash LLM, store in Notion/Sheets/Supabase, and run free on GitHub Actions.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Environment separation prevents development mistakes from reaching real users. Every change should pass through at least two environments before production. Configuration that varies between environments belongs in environment variables, never hardcoded.
| Environment | Purpose | Data | Deploys |
|---|---|---|---|
| Development | Local coding and debugging | Seed/mock data | On save (hot reload) |
| Staging | Pre-production validation | Anonymized production snapshot | On PR merge |
| Production | Real users, real data | Live data | Manual trigger or release tag |
Minimum viable: dev + production. Ideal: dev + staging + production.
All configuration that varies by environment goes in env vars:
.env.example — Checked into repo with placeholder values. Documents every required variable..env.local / .env — Gitignored. Contains real values for local development..env with real secrets. Ever.Verify .gitignore includes: .env, .env.local, .env.*.local
| Approach | When to Use |
|---|---|
| Environment variables | Minimum viable — all platforms support them |
| Platform secrets (Vercel env, Railway secrets) | Managed hosting — encrypted at rest |
| Secrets manager (AWS SSM, HashiCorp Vault) | Enterprise — rotation, audit trails, access control |
Never store secrets in: code, git history, CI logs, client-side bundles, or Slack messages.
Development: Verbose logging, debug mode on, local database, mock external services, hot reload.
Staging: Production-like config, test/anonymized data, real external services (sandbox mode), CI/CD deployed.
Production: Minimal logging (info+error), debug off, real database, HTTPS enforced, error tracking active.
Use for staged rollout and safe deployment.
Simple (small projects): Boolean env var (FEATURE_NEW_CHECKOUT=true). Toggle per environment.
Advanced (larger projects): Feature flag service (LaunchDarkly, Unleash, Flipt). Percentage rollout, user targeting, kill switch.
Never share a database between environments. One wrong query in dev wipes production data.
Dev deploys on push (automatic). Staging deploys on PR merge (automatic). Production deploys on release tag or manual approval (deliberate).
| Rationalization | Reality |
|---|---|
| "One environment is fine for now" | Deploying untested changes to production is gambling with user data. |
| "I'll just use the production database for testing" | One wrong DELETE statement and you have lost real user data. |
| "Env vars are overkill" | Hardcoded config means redeploying to change a value. Env vars change without code changes. |
| "We'll add staging later" | Without staging, every deploy is a production experiment on real users. |
| "Secrets in code are fine, it's a private repo" | Private repos get forked, cloned, and shared. Secrets in code are secrets in every copy. |
.env file committed to git with real secrets.env.example documenting required variables.env.example exists with all required variables documented.env / .env.local is in .gitignore