# How to Manage Environment Variables in Production in 2026 > Fix production environment variable issues in 2026. Learn secure storage, environment separation, startup validation, access control, rotation, and recovery. - **Author**: vamsi-mullapudi - **Published**: 2026-06-08 - **Modified**: 2026-09-18 - **Category**: Deployment Guides - **URL**: https://kuberns.com/blogs/environment-variables-in-production/ --- The best way to manage environment variables in production is to keep values separate for development, staging and production, document every required key, store sensitive values in protected platform settings or a secret manager, restrict who can change them and validate the configuration before the application starts. Environment variables are only a delivery mechanism. A variable is not automatically secret, encrypted or safe from exposure. Production management also requires correct environment scope, build-time versus runtime handling, access controls, auditing and a response plan for leaked credentials. ## What Are Environment Variables in Production? Environment variables are key-value settings supplied to an application process. They let the same code run with different database addresses, service URLs, feature flags and credentials without hardcoding environment-specific values in the repository. Examples include: ```text APP_ENV=production LOG_LEVEL=info DATABASE_URL=postgresql://... PAYMENTS_API_KEY=... PUBLIC_APP_URL=https://example.com ``` The operating system, container platform, CI/CD pipeline, application host or secrets system can provide these values. The application then reads them during the build, at startup or while handling requests, depending on the framework and deployment model. ## Configuration, Secrets and Public Variables Are Different ![Production secrets management done right](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/production-secrets-management.png) Treating every variable as a secret creates confusion. Treating every variable as ordinary configuration creates exposure risk. | Variable type | Examples | Production handling | |---|---|---| | Public configuration | Public site URL, analytics ID, public feature setting | Can be exposed intentionally, but still needs correct environment scope | | Server-only configuration | Internal service URL, log level, worker concurrency | Keep in the runtime and out of browser bundles | | Secret | Database password, private API key, signing key | Mask, restrict access, audit, revoke and rotate | | Client-exposed variable | `NEXT_PUBLIC_*`, `VITE_*` | Treat as public because the value can be included in browser JavaScript | A secret should never be placed behind a client-exposed prefix. If browser code needs to call a service that requires a private credential, call that service from a protected backend instead. OWASP recommends centralized storage, fine-grained access, auditing and a defined creation, rotation, revocation and expiration lifecycle for secrets. Review the [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) when designing a team-wide process. ## How to Manage Variables Across Development, Staging and Production ![Managing environment variables across environments](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/env-vars-across-environments.png) Use the same variable names across environments whenever possible, but give each environment its own values and access controls. | Environment | Recommended source | Key rule | |---|---|---| | Local development | Ignored `.env` or developer secret tooling | Use development credentials only | | Preview or test | Deployment-platform environment scope | Never connect temporary previews to production data by accident | | Staging | Protected staging variables and staging services | Mirror production structure without reusing production secrets | | Production | Protected platform settings or a secret manager | Limit access, audit changes and define rollback behavior | Do not use one database credential, signing key or third-party API secret across every environment. Separation reduces the blast radius when a development machine, preview or staging environment is compromised. For tools that support custom environments, verify that each variable is assigned to the correct target rather than assuming a production value is inherited automatically. Vercel's official guide, for example, treats development, preview, production and custom environments as distinct scopes. [Vercel environment management documentation](https://vercel.com/docs/environment-variables/manage-across-environments) ## How to Use .env, .env.example and .env.production Safely ### Local .env files A local `.env` file is a convenient way to provide development values. Add real environment files to `.gitignore` before inserting credentials. ```gitignore .env .env.local .env.*.local ``` Framework-specific rules differ, so confirm which files are loaded and in what order. Do not assume every dotenv parser handles quotes, expansion, multiline values and backslashes identically. ### The .env.example contract Commit `.env.example` with variable names and safe placeholders. It documents what the application requires without exposing real credentials. ```text APP_ENV=development DATABASE_URL= PAYMENTS_API_KEY= SESSION_SECRET= PUBLIC_APP_URL=http://localhost:3000 ``` Keep this file synchronized with application validation. If the code starts requiring a new key, update the example and deployment configuration in the same change. ### Production environment files Some frameworks support `.env.production`. Next.js, for example, documents production-specific environment files but recommends keeping `.env*` files out of version control. [Next.js environment-variable documentation](https://nextjs.org/docs/pages/guides/environment-variables) If a self-managed deployment uses a production file, protect it with strict filesystem permissions and keep it outside public directories, repository history, build output and backups that lack equivalent access controls. On a managed platform, protected environment settings or a secret manager are generally easier to scope and audit. ## Build-Time and Runtime Variables Many production problems happen because a value exists at the wrong stage. ### Build-time variables Frontend frameworks may read variables while generating browser assets. Those values become part of the build and will not change until the application is rebuilt. In Next.js, variables prefixed with `NEXT_PUBLIC_` can be embedded into the client bundle and frozen at build time. They must never contain private credentials. Changing the dashboard value after the build does not rewrite an existing bundle. [Next.js environment-variable documentation](https://nextjs.org/docs/pages/guides/environment-variables) ### Runtime variables Server applications usually read variables when the process starts or when code accesses the process environment. A runtime change commonly requires a restart or redeployment before the application sees the new value. Before debugging the code, ask: 1. Is the variable needed during the build or by the running service? 2. Is it scoped to development, preview, staging or production? 3. Is it server-only or intentionally client-exposed? 4. Was the application rebuilt or restarted after it changed? ## Validate Required Variables at Startup Fail early with the missing key name instead of allowing the application to crash later with an unrelated database or authentication error. ```js const required = ['DATABASE_URL', 'SESSION_SECRET', 'PAYMENTS_API_KEY']; for (const key of required) { if (!process.env[key]) { throw new Error(`Missing required environment variable: ${key}`); } } ``` Do not include the secret value in the error. For larger applications, use a typed configuration schema that validates required keys, allowed formats, URLs, numbers and boolean conversion in one place. Environment variables arrive as strings unless the framework applies its own parsing. Convert values explicitly and reject invalid values rather than relying on JavaScript truthiness or implicit coercion. ## How to Inspect Production Variables Without Exposing Secrets ![How to fix common environment variable problems](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/env-vars-common-fixes.png) Do not add `console.log(process.env)` or create a diagnostic route that returns the environment. Logs and browser responses are common places for secrets to escape. Use this safer process: 1. Open the platform's environment-variable or secret settings. 2. Confirm that the required key exists in the production scope. 3. Check whether the value is masked or classified as sensitive. 4. Review change history to see when and by whom it was updated. 5. Confirm whether the deployment was rebuilt or restarted afterward. 6. Use startup validation to report missing key names without values. 7. If comparison is necessary, use a secret version identifier supplied by the provider rather than copying the secret into logs. For multi-service applications, verify the variable on the exact service that needs it. Adding a key to the frontend service does not automatically make it available to a worker or backend service. ## Access Controls and Approval Workflows Production variables should not be editable by everyone with repository access. - Grant the least privilege required for each role. - Separate permission to deploy code from permission to view or change secrets where possible. - Require review or approval for sensitive production changes. - Keep an audit history of additions, updates and deletions. - Document the owner, purpose, consumers and rotation method for every secret. - Use different credentials for different services and environments. - Define how to roll back when a variable change breaks production. For larger teams or many applications, use a centralized secrets system rather than copying values between dashboards. Prefer short-lived or dynamically issued credentials when the service supports them. ## How to Rotate Production Secrets Safely Rotation frequency depends on the secret, provider, threat model and applicable compliance policy. A fixed 90-day schedule is not appropriate for every credential. Rotate immediately when: - A secret is exposed or may have been exposed. - A person or system with access should no longer have it. - The provider reports compromise or requires rotation. - A credential has excessive permissions or is shared too broadly. - Your security or compliance policy requires a change. Where possible, use overlapping rotation: 1. Create a new credential. 2. Add it to the required environment. 3. Deploy or restart consumers. 4. Verify that the new credential works. 5. Revoke the old credential. Some signing and encryption keys need a more careful transition because old sessions or stored data may still depend on them. ## What to Do If .env.production Is Exposed Treat every secret in the file as compromised, even if the repository was private or the file was removed quickly. 1. Revoke or rotate the exposed credentials first. 2. Check provider audit logs for unauthorized use. 3. Remove the file from the current repository and deployment artifacts. 4. Review caches, logs, container images and backups for additional copies. 5. Remove the secret from Git history if necessary, understanding that existing clones may retain it. 6. Add secret scanning and a pre-commit or CI check to prevent recurrence. Rewriting Git history does not make the old credential safe. Rotation is the action that invalidates it. ## Common Production Environment Variable Problems ### Variable is undefined in production Confirm that the key exists in the correct environment and on the correct service. Compare names with `.env.example`, including case and spelling, then rebuild or restart as required. ### Updated variable still has the old value Determine whether the value was embedded during the build or read by a running process. Rebuild client assets for build-time variables and restart or redeploy services that read values at startup. ### Value works locally but fails in production Check quoting and parsing rules, line breaks, trailing whitespace and platform-specific formatting. Also verify that the production value points to a production-accessible service rather than `localhost`. ### A public variable exposed a secret Remove the secret from client-exposed configuration, rotate it and move the protected operation to a backend. A browser-visible bundle cannot safely contain a private credential. ### Staging is using production services Audit the environment scope and replace production credentials with staging-specific values. Do not rely only on `NODE_ENV` to identify custom stages. Frameworks may reserve that variable for fixed runtime modes. For additional symptoms beyond configuration, use the guide to [why an app works locally but fails in production](https://kuberns.com/blogs/app-works-locally-fails-in-production/). ## How Kuberns Handles Deployment Configuration ![Manage application environment variables with Kuberns](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/environment-variable-kuberns.png) Kuberns is an Agentic AI platform for deployment. Its agentic AI analyzes the connected repository and prepares the application deployment configuration. The developer provides the secure environment variables required by the application through the deployment workflow. This removes the need to place production credentials in the repository or manually copy an environment file to a server. Developers still need to classify values correctly, use environment-specific credentials and rotate anything that is exposed. The explanation of [what one-click deployment handles](https://kuberns.com/blogs/what-does-one-click-deployment-do/) shows how environment configuration fits into the wider deployment process. ## Production Environment Variable Checklist Before releasing an application: - Every required key is documented in `.env.example` or a configuration schema. - Development, staging and production use separate values. - Secrets are not present in Git history, browser bundles or logs. - Client-exposed prefixes contain public values only. - Build-time variables are available during the production build. - Runtime variables are scoped to the correct service. - Required variables are validated without printing values. - Production access follows least privilege. - Changes are auditable and have a rollback process. - Exposed credentials can be revoked and rotated quickly. ## Conclusion Reliable environment-variable management is a lifecycle, not a one-time dashboard task. Separate values by environment, distinguish public configuration from secrets, understand build-time and runtime behavior, validate required keys and control who can change production values. Kuberns gives developers a simpler production workflow by using agentic AI to prepare the deployment configuration while the developer supplies the required secure environment variables. This keeps sensitive values out of the repository and reduces the manual infrastructure work around deployment. [Deploy your application with Kuberns](https://dashboard.kuberns.com) Deploy your application with Kuberns ## Frequently Asked Questions ### What is the best way to manage environment variables in production? Keep values separate for development, staging and production. Document required keys in `.env.example`, provide production values through protected platform settings or a secret manager, restrict access, validate required variables at startup and redeploy or restart when runtime values change. ### Should I use a .env.production file? Some frameworks support `.env.production`, but a file containing real production secrets must not be committed, served publicly or included in a client bundle. On managed hosting, protected environment settings or a secret manager are usually safer and easier to audit. ### What is the difference between environment variables and secrets? Environment variables are a way to supply configuration to a process. Some contain ordinary settings, while secrets contain sensitive credentials such as private API keys, database passwords and signing keys. Secrets need restricted access, masking, auditing, revocation and rotation. ### How do I manage variables across development, staging and production? Use the same variable names with separate values for each environment. Keep local values in ignored development files when appropriate, store hosted values in the correct environment scope and use `.env.example` or a configuration schema to document every required key. ### How can I inspect production environment variables safely? Use the hosting platform's masked variable list, environment scope and audit history. Validate whether required keys are present without printing their values. Never send secret values to application logs, error messages, browser responses or diagnostic endpoints. ### Why does an environment variable work locally but not in production? The production value may be missing, scoped to the wrong environment, unavailable during the build, frozen into a client bundle, named incorrectly or not loaded until the service restarts. Check the variable's scope and lifecycle before changing application code. ### When should production secrets be rotated? Rotate a secret immediately after confirmed or suspected exposure, when access changes require it, when the provider requires it or according to an applicable risk and compliance policy. Prefer automated rotation and test how applications handle overlapping old and new values. ### What should I do if .env.production was exposed? Treat every secret in the file as compromised. Revoke or rotate the credentials first, then remove the file from the repository, deployment artifacts, caches and logs. Rewriting Git history does not make an exposed credential safe to keep using. --- - [More Deployment Guides articles](https://kuberns.com/blogs/category/deployment-guides/1/) - [All articles](https://kuberns.com/blogs/)