--- title: "10 Core Environment Variables for Simple SaaS Apps (Minimal Setup Guide)" description: "The essential env vars for shipping SaaS on a budget—auth, database, storage, payments, AI, and mail. Plus how to keep setup cheap and secure." type: article seo: keywords: saas setup, environment variables, env vars, saas deployment, node env, database url, stripe env, redis, smtp, ai api pubDate: "2026-02-02 12:00:00" authors: - dubem --- 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:pass@smtp.example.com: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 | # | Env var | Purpose | |---|--------|--------| | 1 | `NODE_ENV` | Environment mode (dev/test/prod) | | 2 | `AUTH_PASSWORD` / `AUTH_HASH` | Admin/internal auth | | 3 | `DATABASE_URL` | Primary database (use internal URL + IP limit when possible) | | 4 | `STORAGE_CREDS` | Object storage (e.g. base64 JSON) | | 5 | `CACHE_URL` / `REDIS_URL` | Redis/cache (same hardening as DB) | | 6 | `PAYMENT_CRED` | Payment provider key + webhook secret (base64 or delimited) | | 7 | `AI_API_GATEWAY` | Single gateway URL for AI providers | | 8 | `MAIL_CRED` / `SMTP_URL` | Transactional email | | 9 | `APP_URL` / `BASE_URL` | Canonical app URL (CORS, OAuth, webhooks, links) | | 10 | `SESSION_SECRET` / `ENCRYPTION_KEY` | Signing/encryption for sessions and cookies | --- ## 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.