Jordan: Eight clients. Thirty-one API keys. Fourteen OAuth tokens. Nine LLM provider secrets. Two Make orgs, one n8n instance, a handful of custom integrations — and every single credential stored in a different place.
That was my setup eleven months ago. I had keys in Make connections. Keys in n8n's encrypted credential store. Keys in a dot-env file on a VPS. Keys in a 1Password personal vault that I shared with... nobody, because I'm solo. And a few — and this is the part I'm not proud of — a few pasted into Notion pages with a lock emoji next to them. As if the lock emoji was doing security work.
I didn't think about it until a client asked me a question I couldn't answer. "Can you show me who accessed our Stripe API key in the last ninety days?" Ninety days. That's not an unreasonable ask. That's the rotation window AWS Config defaults to. It's the interval NIST calls a pragmatic baseline for service tokens. And I had... nothing. No log. No audit trail. No way to prove that their key hadn't been touched by anything except the three Make scenarios I built for them.
I told the client I'd get back to them. Then I spent that weekend rebuilding my entire secrets posture from scratch. One vault. Per-client scoping. Rotation reminders. Centralized logs. The whole thing took about four hours — and it's the single highest-leverage security investment I've made in this business.
Today I'm giving you that system. And the decision that makes it all work starts with one question — 1Password vs Doppler. Or more precisely, password manager versus developer-first secrets manager. Which lane fits a solo automation practice, and why it matters more than you think.
The security gap in most solo practices is not encryption. Make encrypts your connections. n8n encrypts its credential store. The gap is visibility — you cannot see who touched what, when, or whether a key that should have been rotated three months ago is still live in production. One vault fixes that. I'm Jordan, this is Headcount Zero, and today I'm making the case that the single best hour you can spend this week is choosing between a password manager and a secrets manager, wiring it into your automation stack, and never storing a credential outside it again.
So let me frame the problem in terms that hit your wallet. If you're running six to twelve clients on Make and n8n — which is the sweet spot for most of you listening — you've probably got somewhere between twenty and sixty active secrets. API keys, OAuth tokens, webhook signing secrets, LLM provider keys. And right now, most of those secrets live inside the platforms themselves. Make stores them as connections tied to a team. n8n encrypts them with a key generated at first launch. And that feels fine... until you realize what you're missing.
You're missing three things. First — isolation. In Make, connections belong to a team. Every user in that team can use every connection. If you're running all your clients in one team, which a lot of solos do, a compromised scenario for Client A can theoretically access Client B's Stripe key. That's not a hypothetical. The Cloud Security Alliance published a research note in March — this year, 2026 — documenting active exploitation paths in n8n where a remote code execution vulnerability could extract the encryption key and decrypt every stored credential on the instance. Every credential. Every client. One breach.
Second — auditability. That client who asked me about Stripe access? They weren't being paranoid. They were doing due diligence. And increasingly, even small clients are asking these questions because their insurance carriers or their own customers are asking them. If you can't produce an access log, you can't answer the question. And "I'm the only one with access" is not an audit trail — it's a trust statement.
Third — rotation. OWASP's Secrets Management Cheat Sheet has been saying this for years: automate rotation of static secrets. AWS Config defaults to flagging any secret older than ninety days. NIST's latest guidance — SP 800-57, revision six, still in draft as of this year — takes a risk-based approach rather than prescribing a universal interval. But the practical consensus across AWS, Azure, and every major cloud provider is clear: if you're not rotating at least every ninety days, you're accumulating risk that compounds with every client you add.
Okay. So you need a vault. The question is which kind. And this is where the 1Password vs Doppler decision actually matters — because they represent two fundamentally different approaches, and picking the wrong lane creates friction you'll feel every week.
Lane one is the password manager with organization features. 1Password Business and Bitwarden Teams. These tools were built for storing credentials behind a master password, with sharing, vaults, and access controls layered on top. Lane two is the developer-first secrets manager. Doppler and Infisical. These were built for injecting secrets into applications and CI/CD pipelines, with environment scoping, rotation automation, and API-first access as core features.
Here's how the pricing breaks down for a solo. Bitwarden Teams — four dollars per user per month. That's the cheapest entry point with audit logs and export. 1Password Business — seven ninety-nine per user per month. Worth noting that 1Password raised consumer plan prices in March 2026, but as of right now, business pricing hasn't changed. On the developer-first side, Doppler's Developer plan is free for up to three users with three days of activity logs. Their Team plan jumps to twenty-one dollars per user per month but gives you ninety-day logs and automatic secret rotation. Infisical Pro is eighteen dollars per identity per month — rotation, RBAC, IP allowlisting, and ninety-day audit log retention included.
So which lane? Here's my decision framework, and it's simpler than you'd expect. If most of your secrets are passwords, OAuth tokens, and API keys that you paste into Make and n8n connection dialogs — and you don't have a CI/CD pipeline or custom deployment scripts — go password manager. Bitwarden Teams at four dollars a month is hard to beat. You get per-client vaults, exportable event logs with indefinite retention — over fifty event types — and it integrates with the workflow you already have: copy from vault, paste into platform.
But if you're running custom API integrations, deploying n8n on your own infrastructure, or routing LLM calls through proxy endpoints — and we'll get to why you should be doing that in a minute — Doppler or Infisical will save you time every single week. The Developer plan on Doppler is free. You create a project per client, scope service tokens to specific environments, and your code pulls secrets at runtime instead of you pasting them. The trade-off is that three-day log retention on the free tier is basically useless for auditing. You'd need the Team plan for ninety days.
For most solos listening to this — and I mean most — Bitwarden Teams is the right starting point. Four dollars a month. Per-client collections. Exportable logs. Done. You can always migrate to Doppler or Infisical later if your practice shifts toward more custom code. But pick one today. Not tomorrow. Today.
Once you've got your vault, the next move is scoping. And this is where the automation platforms actually help you — if you use them correctly.
In Make, the scoping unit is the team. Create one team per client. Build scenarios only inside that team. Name every connection with a prefix — something like the client name, a dash, then the service. "Acme-Stripe-svc." "Acme-OpenAI." This way, if you're ever looking at a connection list, you know instantly what belongs where. And critically — connections in one team are invisible to scenarios in another team. That's your blast radius control. If a scenario in the Acme team gets compromised, it cannot reach the Baker team's Stripe key.
I learned this the hard way, by the way. Early on I had all my clients in one Make team because it was easier to manage. One org, one billing relationship, fewer tabs. Then I had a webhook misconfiguration that exposed a connection ID in a URL parameter — not the key itself, just the connection ID — and I realized that if someone had been inside that team, they could have used that connection for any scenario. The blast radius was my entire client base. I restructured that weekend.
In n8n, the equivalent is projects. Enable projects, create one per client, and bind credentials to that project's scope. n8n's RBAC lets you restrict credential sharing to project members only. And here's the feature that makes n8n particularly interesting for this — External Secrets. You can connect an n8n project directly to a namespace in your vault. Doppler project, Infisical environment, whatever you're using. The credentials never live in n8n's database at all. They're pulled at runtime from the vault. Which means rotating a key is one change in Doppler or Infisical — not twelve changes across twelve n8n credential entries.
Now — rotation. And I want to be precise here because this is where people either over-engineer or ignore it entirely.
Two tiers. That's it. High-risk secrets get rotated monthly — thirty days. These are your LLM provider keys, admin API keys, OAuth client secrets, anything that touches payment processing or has write access to a production system. Everything else — standard service tokens, read-only API keys, webhook signing secrets — gets a ninety-day baseline. This aligns with AWS Config's default evaluation window and gives you a defensible, auditable cadence without creating so much rotation overhead that you start skipping it.
And you will skip it if it's manual. I know because I skipped it. For months. The fix is a two-scenario setup in Make or n8n that takes roughly fifteen minutes to build. One scenario fires monthly on the first of the month — posts a Slack message to your security ops channel listing which high-risk tokens are due. The other fires every ninety days for the baseline tier. Both pull from a simple secrets register — a spreadsheet or database with columns for client, secret name, risk tier, last rotated date, and next due date. The Slack message tells you exactly what to rotate and for which client. You do the rotation, update the register, move on.
On the logging side — this is where your vault choice pays off. Bitwarden's event logs capture over fifty event types and retain them indefinitely. You can export via CSV or API. Make Enterprise exposes audit logs through their API — twelve months of retention, covering connection authorizations, webhook events, team and user actions. n8n enterprise supports log streaming to external systems. And Doppler and Infisical both offer activity logs with retention that scales by plan.
The play is to land all of these exports into one table. I use a simple Postgres table I call "runs" — timestamp, source, client, actor, action, resource type, and a metadata column for the raw vendor payload. A weekly Make scenario pulls exports from each source and upserts into that table. Takes about twenty minutes to set up. And now when a client asks "who accessed our key in the last ninety days," I run one query and send them the answer in under a minute.
Okay. I hear the objection. And it's a fair one. "Jordan, I'm one person. Make encrypts my connections. n8n encrypts its credential store. I'm the only one with access. Why do I need a separate vault, rotation reminders, and a centralized log table? Isn't this enterprise theater for a team of one?"
And honestly... six months ago I might have agreed with you. NIST's own guidance says key lifetimes should be risk-based, not arbitrary. If your threat model is low and your client base is small, the operational risk of a botched rotation — breaking a live workflow because you swapped a key and forgot to update one connection — might genuinely outweigh the security benefit of rotating on a fixed schedule.
But here's what changed. Two things. First — the attack surface grew. If you added LLM endpoints this year, you added secrets. Every OpenAI key, every Anthropic key, every Mistral or Groq or Replicate token is a new credential with real financial exposure. A leaked LLM key doesn't just expose data — it runs up a bill. I've seen community posts from solos who woke up to four-figure OpenAI invoices because a key leaked through a public repo or a misconfigured webhook.
Second — the CSA research I mentioned earlier. That n8n vulnerability wasn't theoretical. It was a documented exploitation path where remote code execution could extract the encryption key and decrypt stored credentials. If you're self-hosting n8n — and a lot of you are — that's your entire credential store exposed through a single vulnerability. External vaults and the proxy pattern exist specifically to limit that blast radius.
The proxy pattern is simple. You store your real LLM provider key in your vault. You expose a tiny proxy endpoint — could be a Cloudflare Worker, a small Express app, whatever you're comfortable deploying — that accepts a short-lived token from your Make or n8n workflow, validates it, and forwards the request to OpenAI or Anthropic using the real key server-side. Your automation platforms never see the real key. Rotation means changing one value in the vault. Not touching twelve Make connections.
So is it overkill? For the version of your practice that had four clients and no LLM integrations — maybe. For the version you're building now, with eight or ten clients and a growing API surface area — no. It's the minimum viable security posture. And the whole setup — vault, scoping, rotation reminders, log table — takes about four hours the first time. After that, it's fifteen minutes a month to process the rotation reminders and a weekly glance at the runs table.
Remember that client who asked about Stripe access? I sent them a CSV export from my runs table the next morning. Filtered by their client name, scoped to the last ninety days, every access event timestamped and attributed. Took me forty-five seconds to generate. They didn't say much — just "thanks, this is exactly what we needed." But I could hear the shift. That's the moment you go from "the automation person" to "the automation person we trust with our infrastructure." And trust is what keeps retainers renewing.
So here's your one move this week. Go to Bitwarden's business pricing page — or Doppler's, if you're in the developer-first lane — and sign up. Create your first per-client vault or project. Move one client's secrets into it. Just one. That's the hardest part — the decision and the first migration. Everything after that is pattern repetition. The Solo Secrets SOP is on the Resources page — it's a one-page checklist with the Make and n8n Slack reminder snippets so you can wire up rotation reminders the same afternoon.
I'm Jordan. This is Headcount Zero. Go vault something.