DEV Community: Tony

The Boring Setup That Prevents Disaster

Tony — Sat, 09 May 2026 07:33:31 +0000

I sat down to scaffold a new project this week. It was supposed to be simple: wire up a Cloudflare Workers AI pipeline, set a few environment variables, and start publishing. This time, I wanted to get the security setup right from day one — not scramble to patch it after the fact.

A couple of weeks ago the Vercel breach forced me to rotate credentials across an existing project. Scrambling through files, checking what was exposed, hoping nothing slipped — that's not how you want to spend an afternoon. It pushed me to write a proper piece on secret management: a system for keeping secrets safe when AI agents are reading your code. That post was the theory. This one is what it looks like applied to a greenfield project for the first time.

Before that incident, I'd been winging it. Most of my projects relied on .gitignore and hope. I knew agents like Claude and Cursor could index the entire repo. I just hadn't thought seriously about what happened if they opened the wrong file.

This session wasn't about shipping a feature. It was about building a foundation boring enough that most people skip it. Here's what I actually set up.

First: Agents Can Read Your Repo (So Limit What They See)

AI coding tools are powerful because they have context. They see your file tree, your imports, your config files. That context becomes a liability when it includes real secrets.

I was initializing the content-creator repo to call Cloudflare Workers AI, which meant I needed an API key and account ID stored somewhere local. The obvious place was .env.local. The less obvious question was how to make sure no agent ever read it.

Git ignore isn't enough. Git keeps files out of commits, but it doesn't stop an AI assistant from opening a file that's sitting right there in your working directory. I needed agent-level blocks, not just version control.

The Three Files That Actually Matter

I ended up creating three specific guardrails.

First, .claude/settings.json with a denyList. This blocks Claude Code from running Read or Bash(cat) on .env.local. I had to be careful here, because I wanted agents to still read .env.example for variable names. The denyList specifically excludes .env.example while blocking .env.local and .env.*.local.

{
  "permissions": {
    "deny": [
      "Read(.env.local)",
      "Read(.env.*.local)",
      "Bash(cat .env*)",
      "Bash(echo $CONTENT_API*)",
      "Bash(printenv CONTENT_API*)"
    ]
  }
}

That's one file doing three jobs: blocks direct reads, blocks shell echoing, and blocks printenv for the specific variables that hold live credentials.

Second, every AI tool has its own approach to ignoring files. Cursor, for instance, doesn't use .gitignore for its indexer, so it needs a .cursorignore file. If you're using a different tool, look up how it handles context exclusions. The pattern is the same everywhere: tell the agent what not to read, by name.

Third, AGENTS.md. I added an explicit rule telling agents they must never output values from .env* files, and pointing them to .env.example as the safe source for variable names.

One thing none of these files can protect against: pasting your actual secrets inside the IDE where the agent is already running. Create .env.local in a separate terminal, outside the IDE entirely. Type the values there, save, close. The agent never sees the keystrokes.

That's the access layer handled.

The Leak You Won't Find in `.gitignore`

The hidden problem was in my own script. cc-publish calls Cloudflare's API using curl with a Bearer token header. The original version passed the key directly in the command:

curl -H "Authorization: Bearer $CONTENT_API_KEY"

Anyone running ps aux on the machine could see that token in plain text while the request was in flight.

The fix was writing the header to a temporary file, locking it down with chmod 600, and passing it to curl via --config. The temp file gets deleted whether the call succeeds or fails. The key never touches the process list.

The broader point is worth pausing on: do a thorough back-and-forth with your agent, walk through every moving part that touches credentials, and make sure nothing slips through. The boring parts are the ones that bite you.

The rule: if you wouldn't type a password into a public terminal, don't paste it into a shell argument either.

The Gist

Environment variables aren't glamorous. Neither is spending an afternoon on scaffolding while your actual build waits. But this is the work that keeps your API keys out of AI context windows and your deployment credentials out of the process list.

Three layers in practice: .claude/settings.json and your tool's equivalent ignore file keep agents from reading credentials. AGENTS.md sets explicit rules so agents know what to avoid even when they could technically access it. And curl --config with a temp file keeps tokens out of the process list entirely. None of it is exciting. All of it is necessary.

I built this while scaffolding the content-creator pipeline, but the approach applies to any project where AI tools have access to your working directory.

Building something with AI tools? I'd love to hear what you're working on. I write about vibe coding, building in public, and the workflows that actually stick. Find me on Threads – @tony_crusoe

Secret Management for Vibe Coders: The System I Wish I Had a Year Ago

Tony — Mon, 20 Apr 2026 21:31:40 +0000

Yesterday Vercel announced a security incident. This morning I sat down with my project and realized I didn't have a clear system for what to do next.

I knew I was supposed to "rotate my keys." I'd done it before — because an AI told me to. But I'd never really understood why, in what order, or whether I'd been storing secrets properly this whole time.

I've been building with AI tools for just over a year. No CS degree, no coding books, no deep knowledge of any single language. Everything I know came from prompting Claude, Gemini, Cursor, and building through practice. I've shipped real things. But secret management was always something I followed by instinct rather than actual understanding.

Today I fixed that. Here's the full picture — plain English, no fluff — so you can skip straight to the good system.

First: Not Everything in Your .env File Is a Secret

Worth getting clear on this because most tutorials treat the whole .env file as one scary blob. There are actually three distinct types of values:

Real secrets — if someone gets these, they can impersonate your app, rack up your API bills, or read your users' data:

Database passwords
API keys (your AI provider, payment processor, etc.)
The key your app uses to sign user sessions
Anything called a "signing key" or "encryption key"

Config values — totally safe to share, they just control how your app behaves:

A model name like GEMINI_MODEL=gemini-3.0-flash
Feature flags, version numbers, non-sensitive settings

Public values — stuff you intentionally expose to the browser. In Next.js these start with NEXT_PUBLIC_. Don't put anything sensitive here — it ends up in your frontend JavaScript where anyone can read it.

Only the first category needs serious handling. The rest is just configuration.

The Three-Layer Stack

Here's the mental model that makes everything else make sense:

One source of truth at the top — everything else is just a copy of it.

Layer 1 — Your password manager is the boss. Every secret lives here with notes on what it is and when you last rotated it. I use Bitwarden (free, open source), but 1Password and Dashlane are equally solid. One folder per project.

Layer 2 — Your hosting platform's env vars (Vercel, Railway, Render, Fly.io — they all have this). This is what your live app actually reads. Your code never touches these directly — it just calls process.env.YOUR_VARIABLE_NAME and the platform fills it in automatically at runtime.

Layer 3 — .env.local on your laptop. A local copy for development only. It's gitignored — git completely ignores it, it never gets committed. You sync it from your hosting platform using their CLI.

The rule: update the password manager first, then update the copies. That way there's always one place to go if something goes wrong.

The One File That Prevents Most Mistakes: `.env.example`

This is the habit that pays off on every project.

.env.example is your .env.local with all real values removed — just the variable names and a comment about what each one is. You commit this to git. You share it with collaborators. You paste it into AI sessions.

# .env.example
# Copy this to .env.local and fill in real values from your password manager.
# NEVER commit .env.local. NEVER paste real values into AI sessions.

DATABASE_URL=          # Your database connection string
AUTH_SECRET=           # Run: openssl rand -base64 32
GEMINI_API_KEY=        # From Google AI Studio
STRIPE_SECRET_KEY=     # From your Stripe dashboard

Variable names, no values, helpful comments. Safe to share anywhere.

Start every new project by creating this file before you write a single line of code.

Keeping Secrets Out of AI Sessions

Here's something I didn't think about carefully enough until today — and I suspect most AI builders haven't either.

AI coding tools like Cursor and Claude Code index your codebase as context. If .env.local is open in a tab, those real values can end up in the AI's context window. That's not how you want your database password or Stripe key traveling around.

Here's the before/after on what I changed:

The AI only needs variable names to write correct code — it never needs the actual values.

Three rules that make this a non-issue:

Never open .env.local during an AI session. You don't need to. Manage values in your hosting dashboard, sync locally via CLI.
Add .env.local to your AI's ignore file. Create a .cursorignore (and/or .claudeignore for Claude Code) in your project root:
```
.env.local
```
The AI indexer will never touch that file even if you accidentally open it.
Start sessions by pasting .env.example. Just drop it in with a note: "here are my variable names, use process.env.VARIABLE_NAME in any code you write." The AI produces perfectly correct code and never needs to know a single real value.

What "Rotating Keys" Actually Means

Rotating means: generate a new secret at the provider, update it everywhere, revoke the old one. That's it.

You do it when:

A provider announces a security incident (hi, Vercel)
Someone who had access leaves your team
You want a regular security sweep (once a year is fine for small projects)

The same five steps work for every secret:

Generate a new value at the provider's dashboard
Update your password manager first
Update your hosting platform's env vars
Redeploy
Run vercel env pull .env.local (or your platform's equivalent) to sync locally

Rotate in this order — highest damage potential first:

Database password (full data access if leaked)
Session/auth secrets (user account hijacking)
Encryption keys ← read the warning below before touching these
OAuth app secrets (account impersonation)
Everything else (API keys, billing abuse)

Encryption key warning

If you're encrypting data in your database, you can't just swap the key — existing encrypted records become unreadable. The right move: version your keys (ENCRYPTION_KEY_V1, ENCRYPTION_KEY_V2), keep the old one available for decryption, and write a migration script to re-encrypt all records with the new key before retiring the old one. If you haven't encrypted any production data yet, rotate freely — no migration needed.

How OAuth Actually Works

This is the part I'd been fuzzy on: "Google handles security for me, right?"

Not quite. Here's the actual picture:

Your app has its own permanent identity with Google — a Client ID and Client Secret that live in your env vars just like any other API key. They prove to Google that requests are coming from your app.

Then, when a user connects their account ("Sign in with Google"), Google issues two tokens that you store in your database:

A short-lived access token (expires in hours)
A long-lived refresh token (valid until the user revokes it)

Google stores nothing on your behalf. You're responsible for those tokens in your database, which means your database security matters a lot for OAuth too.

Setting Up a New Project the Right Way

Four steps, five minutes, done:

And every time you add a new secret going forward:

Create the credential at the provider
Add it to your password manager first
Add it to your hosting platform's env vars
Sync locally with the CLI
Add the variable name (no value) to .env.example

Two minutes per secret. Scales cleanly as your project grows.

Optional Nerd Check: Did Any Secrets Ever Leak Into Git?

If you've accidentally committed an .env file, you'd probably remember — it tends to be a memorable moment. But if you want to be certain, run these in your project root:

# Was any .env file ever committed?
git log --all --full-history -- ".env*"

# Search history for anything that looks like a real secret value
git log --all -p | grep -E "(API_KEY|SECRET|PASSWORD)\s*=\s*['\"]?[a-zA-Z0-9]"

Nothing returned — you're clean.

If something does come back: rotate the exposed secret first (that's what actually protects you), then clean up the history with git filter-repo and force push. Rotating is the urgent action. The cleanup is secondary hygiene.

The Gist

Every secret your app uses is a credential that proves your app's identity to another service. Treat it like a password: store it in a password manager, keep it out of your codebase, rotate it after incidents, and don't hand it to an AI assistant.

The system is four things: password manager (source of truth) → hosting platform (production copy) → .env.local (local copy) → .env.example (the safe version you share everywhere). Get these four right and you're doing secret management properly — the same way any experienced developer does it.

No degree required. Just a bit of intentional setup at the start of each project. Now go create that .env.example.

Building something with AI tools? I'd love to hear what you're working on — drop it in the comments. I write about vibe coding, building in public, and the AI-first dev workflow.

DEV Community: Tony

The Boring Setup That Prevents Disaster

First: Agents Can Read Your Repo (So Limit What They See)

The Three Files That Actually Matter

The Leak You Won't Find in .gitignore

The Gist

Secret Management for Vibe Coders: The System I Wish I Had a Year Ago

First: Not Everything in Your .env File Is a Secret

The Three-Layer Stack

The One File That Prevents Most Mistakes: .env.example

Keeping Secrets Out of AI Sessions

What "Rotating Keys" Actually Means

How OAuth Actually Works

Setting Up a New Project the Right Way

Optional Nerd Check: Did Any Secrets Ever Leak Into Git?

The Gist

The Leak You Won't Find in `.gitignore`

The One File That Prevents Most Mistakes: `.env.example`