10 Core Environment Variables for Simple SaaS Apps (Minimal Setup Guide)

If you deploy a lot of SaaS tools—for learning or side projects—you want a minimal, repeatable env setup that keeps cost down and still covers the basics. Here are the 10 core environment variables I use for simple SaaS apps, plus how to use them so you stay lean and secure.

Why standardize your SaaS env setup?

Using a small, consistent set of env vars across projects makes it easier to:

• Spin up new apps without rethinking config every time
• Answer “what env do I need?” for yourself and for docs
• Reduce cost by avoiding unnecessary or duplicate services
• Stay secure by treating secrets the same way everywhere

These 10 cover auth, data, storage, cache, payments, AI, mail, app URL, and signing—enough for most simple SaaS products.

1. NODE_ENV

What it does: Tells your app whether it’s running in development, test, or production.

Why it matters: Drives logging level, error details, caching, and which config branch runs. Essential for environments and testing—e.g. no sending real emails or charging cards in test.

Typical values: development | test | production

2. AUTH_PASSWORD / AUTH_HASH

What it does: Secret used to verify admin or internal actions (e.g. cron, webhooks, or simple password gates). Can be a shared password or a hash (e.g. bcrypt) depending on your auth design.

Why it matters: Protects anything that isn’t user-login based: health checks, internal APIs, webhook verification. One env var keeps it simple.

Tip: Prefer a hash in production; for learning/side projects a long random password in env is often enough.

3. DATABASE_URL

What it does: Single connection string for your primary database (e.g. Postgres, MySQL).

Why it matters: One URL per environment keeps DB config simple. You can harden it by:

• Using an internal DB URL when app and DB are in the same hosting network (e.g. same VPC or region)
• IP allowlisting at the DB or firewall so only your app (and maybe your IP for debugging) can connect

Tip: For cheap setups, use a small managed DB (e.g. Neon, Supabase, Railway) and avoid exposing the URL outside your app.

4. STORAGE_CREDS

What it does: Credentials for object storage (e.g. S3-compatible: AWS, Cloudflare R2, MinIO).

Why it matters: File uploads, exports, and assets need somewhere to live. A single env var keeps you from managing many separate keys in the UI.

Format: Base64-encoded JSON is convenient: one env var with accessKeyId, secretAccessKey, endpoint, bucket, etc. Decode at startup and use in your storage client.

5. CACHE_URL / REDIS_URL

What it does: Connection URL for a cache (typically Redis).

Why it matters: Sessions, rate limiting, job queues, and simple caching all benefit from Redis. Same idea as DATABASE_URL: one URL, optional internal URL and IP limiting when app and Redis share a network.

Tip: For minimal cost, use a small Redis instance (e.g. Upstash serverless Redis) and only enable it when you need cache or queues.

6. PAYMENT_CRED

What it does: Everything your app needs to talk to the payment provider (e.g. Stripe): often secret key and webhook secret.

Why it matters: Charging and verifying webhooks are core to SaaS. One env var keeps config simple.

Format: Base64 JSON or a delimited string (e.g. secret|webhook_secret). Parse once at startup and use for SDK init and webhook signature verification.

7. AI_API_GATEWAY

What it does: URL (and optionally key) for a single gateway that talks to one or more AI providers (e.g. OpenAI, Anthropic).

Why it matters: In the AI era you almost always need models for features or tooling. A gateway (e.g. Vercel AI SDK / proxy, or a small BFF) lets you:

• Use one API key in the app
• Switch or add providers without changing app env
• Centralize rate limits and logging

Tip: Vercel’s AI gateway is a solid option; you can also host a tiny proxy yourself and put its URL in this env.

8. MAIL_CRED / SMTP_URL

What it does: SMTP credentials or a full SMTP URL for sending email (signup, password reset, notifications).

Why it matters: Most SaaS needs transactional email. One URL (e.g. smtp://user:[email protected]:587) or a single MAIL_CRED (e.g. base64 JSON) keeps it simple.

Tip: Use a transactional provider (Resend, SendGrid, Postmark, etc.) and put their SMTP URL or API key in this var.

9. APP_URL / BASE_URL

What it does: The canonical public URL of your app (e.g. https://app.example.com).

Why it matters: Needed for:

• CORS and redirect allowlists
• OAuth / social login callback URLs
• Email links (e.g. “Confirm your email”)
• Webhooks that need to call back into your app
• Sitemaps and canonical tags for SEO

Without a single source of truth, you end up with wrong links in staging or broken callbacks. One env var per environment fixes that.

10. SESSION_SECRET / ENCRYPTION_KEY

What it does: A secret used to sign or encrypt data (sessions, CSRF tokens, signed cookies, or encrypted payloads).

Why it matters: Frameworks use this to sign cookies and protect against tampering. If you store anything sensitive in cookies or tokens, a dedicated key keeps it consistent and rotatable. Often overlooked until something breaks or gets exploited.

Tip: Generate a long random string per environment and never reuse it across apps or envs.

Quick reference: 10 core env vars for simple SaaS

How to keep SaaS env setup cheap

• Use a single DB and Redis per environment; avoid duplicates.
• Prefer internal URLs when app and data services run in the same provider/region.
• One AI gateway instead of multiple provider keys and clients.
• Base64 or delimited strings for multi-value creds so you only add one env var per service.
• Standardize names across projects (DATABASE_URL, REDIS_URL, etc.) so docs and scripts stay reusable.

You don’t need more than these 10 for most simple SaaS apps. Add more only when you add a distinct capability (e.g. a dedicated search or analytics service). Keeping env minimal keeps deployment and cost under control—and makes it easier to ship and iterate.