Secrets in Plain Sight: How One Line of Code Can Sink a Project

Why "It Is Fine" Is the Most Expensive Phrase in Engineering

"It is a private repo." "I will comment it out before I push." Famous last words. Three traps catch teams again and again:

1. Git has a perfect memory. Commit a database password or a payment key by accident, and deleting the file in your next commit fixes nothing — the secret lives in history forever. An attacker (or a bored intern with git log) just has to scroll back.
2. The copy-paste trap. Hardcoded config turns every promotion from dev to staging to prod into a minefield. You are swapping keys by hand on each deploy, and one fat-fingered value means your test server is suddenly billing the production account real money.
3. Death by screenshot and log. Hardcoded values leak into error logs, stack traces, and the projector during a pairing session. Environment variables never show up in the code — they live at the server level, out of sight.

The PolyCode Playbook for Secrets

Our process is simple and non-negotiable. No pricey enterprise vault required — just discipline you actually stick to.

• A .env file exists; it is never committed. Every repo ships a .env.example — a template listing every variable you need (DB_HOST=, STRIPE_API_KEY=) with the values left blank. You copy it to .env, fill in your own keys, and .env itself stays in .gitignore forever. No exceptions.
• The code does not know where it lives. It just asks the platform: "give me the database token." Locally that comes from your .env; in production from the host environment settings (Coolify, your orchestrator, plain Linux env — whatever you run).
• Secrets ride the pipeline, not the repo. CI/CD injects them from a secure store (GitHub Secrets, your vault) straight into the build. Config never travels in a zip file or a Slack DM.

What This Looks Like in Code

Here is the anti-pattern almost everyone writes first:

The footgun

// ❌ How NOT to do it (a straight path to grey hair)
export const dbConfig = {
  host: "192.168.1.100",
  user: "admin",
  password: "SuperSecretPassword123" // Hello, public repository!
};

The obvious fix is swapping the string for process.env.PASSWORD — but that is only half the job. Reading env vars is easy; trusting them blindly is the new bug. The other half is validating them at startup and failing fast. If the database URL is missing, the app should refuse to boot — a loud crash at deploy time beats a quiet one throwing 500s at real users. This zod pattern is our standard:

The standard: validate, then trust

// ✅ Gold standard: validate the environment
import { z } from 'zod';

// 1. Declare the variables we truly need
const envSchema = z.object({
  DATABASE_URL: z.string().url(),
  API_SECRET_KEY: z.string().min(10),
  NODE_ENV: z.enum(['development', 'test', 'production']).default('development'),
});

// 2. Validate whatever the system gave us
const env = envSchema.safeParse(process.env);

if (!env.success) {
  console.error('❌ Critical error: missing environment variables', env.error.format());
  process.exit(1); // Hard-stop the application
}

// 3. Export a typed config for the whole project
export const config = env.data;

Why This Just Works

Over to You

How does your team hand secrets from devs to ops — a vault, encrypted env, a shared password manager, or vibes? Ever shipped a key straight to prod? Drop your best (or worst) story in the comments.