redactkit

Redact secrets out of a log and keep the log readable.

A command-line tool. It reads a pipe or a pile of files, writes a version you can paste anywhere, and — this is the part that matters — lets you turn the replies back into the real thing on your own machine. No network calls, no telemetry, no dependencies.

The problem with every other way of doing this

A secret scanner tells you there is a secret at line 42. That is a different job: it finds the leak, and then hands the log back to you exactly as it was. You still cannot share it.

sed 's/ghp_[A-Za-z0-9]*/REDACTED/g' hands you back a log, but every secret becomes the same word. A trace with three different tokens in it collapses into noise, and you can no longer tell which request was which — which is usually the exact thing you were trying to show someone.

09:14:02 api INFO  auth ok token=REDACTED
09:14:03 api ERROR upstream 500 url=https://svc:hunter2@db.internal/app
09:14:09 api INFO  retry with token=REDACTED
09:14:11 api WARN  aws AKIAIOSFODNN7EXAMPLE denied

09:14:02 api INFO  auth ok token=[GITHUB_TOKEN_1]
09:14:03 api ERROR upstream 500 url=https://svc:[PASSWORD_1]@db.internal/app
09:14:09 api INFO  retry with token=[GITHUB_TOKEN_1]
09:14:11 api WARN  aws [AWS_KEY_1] denied

The tags in the figures above stay stable across every file in a run, so a token in api.log and the same token in worker.log are still recognisably one token. And the timestamps came through untouched, which sounds like a low bar and is not: a redactor that mangles 09:14:02 destroys the only thing that makes a log a log. That case is one of the regression tests.

The round trip

Turning the replies back into real values is the feature the browser tool cannot have, and the reason redactkit exists as a separate thing. It works because the run leaves a key map behind on your disk, and the tool is loud about what that file is.

$ redactkit app.log -m keys.json -o safe.log
redactkit: wrote keys.json (mode 600) -- it holds the real secrets, keep it local
redactkit: 4 replacements, 3 distinct values
  GITHUB_TOKEN x2, AWS_KEY x1, PASSWORD x1

$ stat -c %A keys.json
-rw-------

keys.json holds the original secrets in the clear. redactkit writes it mode 0600 and says so on stderr every single time. It never leaves your machine, because redactkit makes no network calls at all — there is nowhere for it to go.

So you can hand safe.log to your colleague, your vendor, your issue tracker or your language model, let them answer in terms of the tags, and still be the only person who can turn a tag back into a credential.

Free or paid

The browser tool stays free forever, and it is not a crippled demo: it is the same detectors, and it always will be, because they are generated from the same source. What you pay for is everything you cannot do by pasting into a text box.

This used to be a paid product. It is free now.

For most of this project's life there was a price on this page — $29 for one developer, $99 for a team — sitting above an order form that asked you to email me so I could quote you a wallet transfer by hand. Not one person ever did. That is a measurement, not a complaint: an offer you cannot complete in a minute, from a seller you have never heard of, is not an offer. Leaving it up once two real checkouts existed elsewhere on this site was the part that was actually wrong, so it is gone.

redactkit is free now, MIT licensed, and whole — the same build the figures above were captured from, not a trimmed demo. Take it and never come back.

No licence server, no activation, no phone-home — there never was one, and now there is nothing for one to check. You may read every line, change anything, vendor it into your own repo, and keep using it if this project stops existing, which it might.

If you want the engine as a dependency rather than a command, npm install logscrub is the same detectors, generated from the same source file.

Your log is not always UTF-8

The browser tool takes what you paste, and a clipboard only ever holds text something else already decoded. A command-line tool reads files, which is a harder job: a log PowerShell wrote with > is UTF-16, a log from an older Windows or Japanese system is in a legacy encoding, and a dump someone handed you may not be text at all. Read every one of those as UTF-8 and the result looks like success in the worst way — either nothing matches and the file reports clean, or the credentials are found correctly while the log around them is quietly replaced with question marks.

So redactkit reads the bytes first and asks what they are, using the same sniffer the browser tool uses, generated from the same page.

$ xxd ps.log | head -1
00000000: fffe 3000 3900 3a00 3100 3400 3a00 3000  ..0.9.:.1.4.:.0.

What it does not do

Read this part before you rely on it. The tool is worth more to you if you know where it stops — so here is where it stops, shown rather than promised.

The same limits in words, because a figure is not searchable and a reader should be able to find them in the README too:

• It is pattern matching, not comprehension. A secret with no recognisable shape and no recognisable key name next to it — a bare twenty-character password alone on a line — goes straight through. Nothing matching does not mean the text is clean, and redactkit prints exactly that on every clean run.
• It does not touch internal names. Hostnames, ticket numbers, customer names and table names are not credentials and are left alone deliberately.
• A token broken across lines can be partly matched, which is worse than a miss, because the output looks redacted. Check long wrapped values yourself.
• An encoded secret is reported, not redacted. A credential inside a base64 or hex run is named by line and left in place, because the blob around it may be something you need whole.
• The map file is the weak point. Everything the tool protects sits in that one file in the clear. That is the honest trade for a reversible round trip, and if you do not need the round trip, do not write one.

When the secret is inside something else

Every rule above reads the text in front of it. So a credential that arrives base64 encoded — a Kubernetes secret echoed into a deploy log, a JWT payload, a config blob — matches nothing, and the tool used to print nothing was replaced over it and exit clean. In a pre-commit hook that is not a missed warning; it is the hook letting the commit through.

redactkit now decodes each encoded run it did not already redact, re-scans it with the same rules, and tells you by line what is inside. It never rewrites the blob.

Only decoded runs count by default. The other thing a redactor can tell you — the long random strings and UUIDs it decided not to touch — is behind --review-all, because nearly every real log has a build hash or a request id in it and gating a commit on those would make the hook useless. The precision a rule needs is set by what happens when it fires, not by how good the rule is.

The free tool publishes the same limits, and they are pinned by tests that fail on purpose if a code change quietly makes one of them stale. That is the actual reason to trust either of them: not that I say they are careful, but that the claims are checked by something that can go red.

What you get

• bin/redactkit.mjs and lib/ — the CLI and the engine, plain ES modules, no dependencies, Node 18 or newer.
• lib/detectors.mjs — generated from the free browser tool, with the source hash stamped in package.json so a stale copy is a test failure rather than a surprise.
• hooks/pre-commit — scans the staged diff's added lines, and never blocks a commit because the hook itself is misconfigured.
• README.md and LICENSE.txt — including the limits above, written down where you will actually find them.