A Founder's Guide to Environment Variables, Secrets, and Least Privilege

A Founder's Guide to Environment Variables, Secrets, and Least Privilege

If you are running a SaaS, you have secrets: API keys, database passwords, JWT tokens. How you store and manage these secrets is the difference between a secure app and a breach waiting to happen. This guide explains environment variables, secrets, and least privilege in plain language, for founders who are not security experts but need to get this right.

The direct answer is that environment variables are configuration values stored outside your code, secrets are a type of environment variable that must be protected, and least privilege is the principle of giving each component only the permissions it needs. Together, these three concepts form the foundation of SaaS security. Get them wrong, and a single compromised key can destroy your business. Get them right, and you significantly reduce your risk. For more on security, see our article on a practical security checklist for early-stage SaaS.

What Are Environment Variables?

Environment variables are configuration values that your app reads from the operating system at runtime, rather than from the code. For example, instead of writing const databaseUrl = 'postgresql://user:pass@host:5432/db' in your code, you write const databaseUrl = process.env.DATABASE_URL and set the DATABASE_URL environment variable in your hosting platform's dashboard.

Why environment variables matter

Environment variables matter for three reasons. First, they separate configuration from code, which means the same code can run in different environments (development, staging, production) with different configuration. Second, they keep secrets out of the code, which means secrets are not committed to version control (where they are publicly accessible). Third, they allow configuration to change without code changes, which means you can rotate a secret or change a database URL without redeploying the app.

How to set environment variables

In Deployxa, environment variables are set in the dashboard under "Environment Variables." In development, they are set in a .env file (which is gitignored and never committed). For more on environment variable setup, see our article on the vibe coder's guide to environment variables.

What Are Secrets?

Secrets are environment variables that contain sensitive information: API keys, database passwords, JWT secrets, OAuth client secrets. If a secret is exposed, an attacker can use it to access your data, impersonate your app, or charge your customers.

The golden rule of secrets

The golden rule is: never put a secret in code. If a secret appears in your source code, it is committed to version control, which means it is publicly accessible (if your repository is public) or accessible to anyone with repository access (if it is private). Either way, it is a security incident.

Common secrets in a SaaS

• DATABASE_URL — your database connection string (contains the password)
• STRIPE_SECRET_KEY — your Stripe secret key (can charge customers)
• JWT_SECRET — the secret used to sign JWT tokens (can forge tokens)
• OAUTH_CLIENT_SECRET — your OAuth client secret (can impersonate your app)
• SENDGRID_API_KEY — your email service API key (can send emails as you)

How to manage secrets

1. Store secrets as environment variables in the Deployxa dashboard (for production) and in a .env file (for development).
2. Never commit `.env` to Git. Add .env to .gitignore.
3. Create a `.env.example` file that lists the required variables with placeholder values, and commit this file. This documents what variables are needed.
4. Rotate secrets regularly (every 90 days) to limit the impact of a compromised secret.
5. Use a secrets manager (e.g., Doppler, AWS Secrets Manager) for teams with many secrets.

For more on secrets management, see our article on the secrets management gap.

What Is Least Privilege?

Least privilege is the principle of giving each component (user, service, API key) only the permissions it needs to do its job — and no more. For example, your database user should be able to read and write to your app's tables, but it should not be able to drop databases or create superusers. Your Stripe API key should be able to create charges and retrieve customers, but it should not be able to delete your Stripe account.

Why least privilege matters

Least privilege matters because it limits the blast radius of a compromise. If your database user has superuser privileges and an attacker compromises it, they can drop your entire database. If your database user has only read-write access to your app's tables, the attacker can only affect those tables. The difference is catastrophic.

How to implement least privilege

• Database: Create a dedicated database user for your app (not the superuser). Grant it SELECT, INSERT, UPDATE, and DELETE on your app's tables, but not DROP or CREATE. For more on database security, see our article on fixing DATABASE_URL not set.

• API keys: Use scoped API keys (not global keys). For example, Stripe allows you to create restricted keys that can only perform specific actions (e.g., create charges, but not issue refunds). Use the most restrictive scope that still allows your app to function.

• Cloud IAM: If you use AWS, GCP, or Azure, use IAM roles with minimal permissions. Do not use the root account for anything. For more on access control, see our article on building an AI agent that manages your team's access control.

• MCP server: If you use the Deployxa MCP server, use OAuth 2.1 PKCE with scoped tokens. Destructive actions (delete, rollback, modify env vars) should require confirmation. For more on MCP security, see our article on securing agentic cloud deployments.

The Founder's Security Mindset

As a SaaS founder, your security mindset should be:

1. Assume secrets will be exposed. Design your system so that a single exposed secret does not compromise everything. Use least privilege, rotate secrets, and monitor for unauthorized access.

1. Make the secure path the easy path. If using environment variables is harder than hardcoding secrets, your team will hardcode secrets. Make environment variables the default (via .env.example and platform configuration).

1. Audit regularly. Review who has access to your secrets, what permissions they have, and whether any secrets need to be rotated. For more on auditing, see our article on the audit log system.

1. Prepare for the worst. Have a plan for what to do if a secret is exposed: rotate the secret, update all services that use it, and notify affected customers. For more on incident response, see our article on how to handle your first SaaS deployment incident.

Common Pitfalls and Troubleshooting

The first pitfall is committing .env to Git. This is the most common security incident for early-stage SaaS. The fix is to add .env to .gitignore immediately, remove it from history, and rotate all exposed secrets. The second pitfall is using NEXT_PUBLIC_ for secrets. Variables prefixed with NEXT_PUBLIC_ are inlined into client-side JavaScript, which means anyone can see them. Never use NEXT_PUBLIC_ for secrets. The third pitfall is not rotating secrets. Secrets that are not rotated are vulnerable to compromise, because a stolen secret is valid forever. The fix is to rotate secrets every 90 days. The fourth pitfall is using superuser database credentials. If your app connects to the database as a superuser, a SQL injection attack can drop the entire database. The fix is to create a dedicated database user with minimal permissions. The fifth pitfall is not using scoped API keys. Global API keys (e.g., Stripe's global secret key) give the holder full access to your account. The fix is to use restricted keys with the minimum scope needed.

Conclusion: Security Starts with the Basics

Environment variables, secrets, and least privilege are the foundation of SaaS security. By storing secrets in environment variables (not code), rotating them regularly, and granting only the permissions each component needs, you significantly reduce your risk and build trust with your customers. Security is not a one-time task — it is an ongoing practice that starts with the basics.

Ready to secure your secrets? Review your environment variables, rotate your secrets, and implement least privilege today. For more, see the secrets management gap and the practical security checklist for early-stage SaaS. Explore our free developer tools to speed up your workflow.