01

Keystrok: I designed the API-key security tool I couldn't find, then built and shipped it

Self-hosted, open-source API key management that developers actually want to use

MIT
Open source, no paywall
1 cmd
Self-host with docker compose
0
Secrets stored in plaintext
~2 yrs
Research, design, and build
Keystrok home: what needs attention, ranked by urgency
EXECUTIVE SUMMARY

From a real pain to a shipped product

I kept running into the same problem managing API keys, researched whether other developers did too (they did), and designed and built a tool to fix it, end to end. Not a mockup: a working, self-hosted, open-source product with discovery, a tracked key ledger, guided rotation, and multi-user teams. This is how I work as a designer, spot a real problem, make opinionated calls, and actually ship it.

02 — THE PROBLEM

Nobody had made key management pleasant to do

The gap

  • Leaked and stale credentials are one of the most common ways systems get breached
  • Secrets platforms (Vault, Infisical) are heavyweight, and they store your keys
  • Scanners (gitleaks, trufflehog) find secrets, then stop, no triage, no rotation
  • Nobody owns the messy middle: what leaked, is it still live, and when do I rotate it

Asked for the hardest part of rotating a key, one developer answered simply: "knowing where it's used." Another described being forced to write a lambda that renewed a Grafana key every 30 days, because nothing else was tracking it. The incidents, when they happened, were the kind that "stop the world." The tooling existed; the honest, low-friction way to stay on top of it did not.

This wasn't a tooling problem.
It was a design problem.

03 — RESEARCH & DISCOVERY

Understanding Developer Pain

The API Key Rotation Practices survey I ran on Google Forms

A short survey on API key rotation practices, shared with dev friends and r/grafana

What the research surfaced

A small, honest study: a short survey plus conversations with a few developer friends and some folks on r/grafana. Tiny sample, but the answers pointed at the same thing again and again, and straight at the design problem.

No system
Nobody I asked had a systematic way to track where their keys were used
"Where?"
The hardest part of rotation, in their words: knowing where a key is actually used
Every one
Of the developers I heard from had hit an outage or incident tied to a rotation
Months
How long keys routinely sit before anyone gets around to rotating them

Who I designed for

From those conversations, I built for three kinds of user:

Solo Developers

Need simple, free solutions without complexity overhead

Small Teams

Want collaboration features without enterprise complexity

Security-Conscious Startups

Require audit trails but can't afford enterprise tools

04 — DESIGN STRATEGY

Security Through Simplicity

1

10-Second Overview

Critical information visible instantly. No drilling down through menus to understand system health.

2

Progressive Disclosure

Complexity available when needed, but never forced. Simple tasks stay simple.

3

Proactive Security

Guide users toward best practices through smart defaults and gentle nudges.

4

Developer Aesthetics

Dark mode first, information dense, terminal-inspired design that feels familiar.

Key Design Decisions

Visual Hierarchy Through Color

Colour is reserved for security state, so the one thing that needs attention reads in a glance, before you parse a single word.

Overdue (act now) Rotation due soon Healthy

Advisory, never automated

Keystrok ranks and walks you through each rotation, but it never rotates or revokes a key on its own. The irreversible actions stay in your hands, behind a confirm. No surprise revokes.

It never holds your secrets

Scans are read-only, findings are stored hashed and masked, and the optional AI assistant reasons over key metadata, never the values. A security tool earns trust by handling less, not more.

Honest about what it can't know

It never guesses a key's real age. Every rotation deadline is counted from when a key was discovered, not a made-up creation date. Better an honest "found 6 days ago" than a confident lie.

One clear next action per row

Every key surfaces its most likely next step instead of a menu, so the common path is one move, not a hunt.

05 — SOLUTION DESIGN

The Interface

"I didn't want another dashboard to babysit. I wanted a tool that surfaces the one key that needs attention, walks me through fixing it, and otherwise gets out of the way."
— The design thesis behind Keystrok
06 — WHAT SHIPPED

Not a prototype. A working product.

Keystrok runs today: open source, self-hostable, and doing the full job end to end. I designed it and built it, this is the real feature set, not a roadmap.

Scan a GitHub repo (via a GitHub App) or a local folder for exposed secrets, stored hashed and masked Discovery
Promote real findings to a tracked inventory, each with a rotation deadline from its severity Ledger
Step-by-step, operator-gated walkthroughs; the revoke step is irreversible by confirm Rotation
Connect Datadog, Grafana, Stripe, or GitHub to check whether a leaked key is still live Liveness
Invite members, gate the irreversible actions to admins, keep a shared attributed workspace Teams

Built to be trusted

  • MIT-licensed, mirrored on Codeberg. No paywall, no open-core split.
  • One command to self-host (app + Postgres + a local mail catcher). Nothing phones home.
  • Secrets encrypted at rest (AES-256-GCM); outbound calls are SSRF-guarded.
  • Next.js 15 + TypeScript + Postgres, shipped as a multi-arch image (amd64 + arm64).
07 — DIRECTION

Roadmap & Direction

SHIPPED
Open source and self-hostable
MIT-licensed. Discovery, a tracked key ledger, guided rotation, platform liveness checks, and multi-user teams, all running today. One command to self-host, nothing phones home.
NEXT
Community-driven depth
More detectors and platform integrations, scheduled scans, and whatever the people actually self-hosting it ask for. Built in the open.
MAYBE, SOMEDAY
A commercial path, if it earns one
I first imagined Keystrok as a company and drifted to open source because it felt right. Managed hosting or paid support isn't off the table if the opportunity arises, but it's not planned. Either way the core stays MIT: what you self-host today stays open, forever.
08 — OUTCOME

Why This Matters

Keystrok is proof of how I work: I don't stop at the mockup. I research a real problem, make opinionated design decisions, and ship a working product, learning whatever engineering it takes to get there. That's what I bring to a senior product design role.

Key Learnings

About Technical Product Design:

  • Developers value focus over features - Do one thing exceptionally well
  • Visual design matters in DevTools - Good aesthetics improve adoption
  • Open source builds trust - Transparency is crucial for security tools

About Building While Designing:

  • Implementation constraints improve design
  • Real data exposes edge cases mockups miss
  • Community feedback is gold

I taught myself the TypeScript, Next.js, and security engineering to build this for real, not just design it. Research to a shipped, self-hosted product, it's the most end-to-end thing I've made.

The clearest lesson: I had commercial demand in hand and chose to make Keystrok open source anyway. For a security tool, trust and transparency matter more than capture, and that was a deliberate product decision, not a default.