What Not to Publish — Privacy Review for Self-Hosting Posts

Self-hosting build series, Part 10. Locking down the server matters; so does locking down the story you write about it.

← Previous: Part 9 — Invisible Bridge: Cloudflare Tunnel
→ Next: Part 11 — Free WordPress Defense (Wordfence)

TL;DR

• A self-hosting post inherently publishes the shape of your server — a tightrope between tutorial value and reconnaissance data.
• What I actually leaked: the Linux account name, the mini-PC internal IP, and a personal email (passwords and tokens, luckily, did not leak).
• Five things to redact: secrets · personal info · internal network · file paths · frontmatter.
• A leaked secret can only be rotated, never un-leaked — search engines have already cached it.
• One line of grep before publishing lets the machine sweep for you.

1. What I actually leaked

After happily writing nine parts, I looked again — and found these scattered through the text.

• /home/my-account/... — the Linux account name, sitting right in the path. A target for SSH brute-force attempts.
• http://192.168.x.x:3001 — the mini-PC internal IP, effectively a sketch of my home network.
• A personal Gmail address that slipped into a line about the domain.

Passwords and tokens I had, luckily, written as example values like ${VAR} or <openssl rand -hex 24>, so they were safe. But the three above were real.

The problem is that a public blog is permanent. Search engines index it; caches keep it. Deleting does not undo it. So if a secret has leaked, you don’t delete it — you rotate it immediately.

2. The five things to redact

⑤ is the surprising one. In Markdown, the top of a file has metadata fenced by --- (frontmatter: author, date, filename, and so on). If the publishing conversion slips just once, this gets dumped into the body as a code block. One of my own posts was doing exactly that — exposing its entire frontmatter.

3. Don’t delete — “generalize”

The key is substitution, not deletion. Keep the tutorial value; hide only the parts that are really mine.

Spelling it out as <openssl rand -hex 24> — “generate your own value here” — actually helps the reader follow along. Generalizing turns out to be the friendlier tutorial.

4. An automatic pre-publish check (one line of grep)

Catch it by eye every time and it will eventually slip. Before publishing, let the machine sweep.

grep -rEn '/home/[a-z]+|[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+|@(gmail|naver)\.com|_TOKEN=|_KEY=|PASSWORD=' my-posts-folder/

This catches account paths, IPs, personal email, and secret traces in one pass. The result must be zero lines before you publish. If only placeholders like ${VAR} or <...> remain, you pass.

After publishing, look at the actual public page once more — a cache may still be serving the old version.

curl -s https://your-domain/post-slug/ | grep -E '/home/|192\.168\.|@gmail'

5. The bigger question — should this be public at all?

Even after redacting every detail, one problem remains: the post itself is a map of my infrastructure.

I run private operational tools that I never write about. No matter how well I hide keys and IPs, the mere fact that “a management tool with this shape lives here” is reconnaissance.

So order matters. Decide “should this series be public?” first, and run the redaction above only on what you’ve chosen to publish. What can be hidden, and what should never be written at all, are two different layers of the problem.

One-line takeaway

If there’s a P0 for locking down the server, there’s a P0 for locking down the writing too. Generalize the five — account name, internal IP, personal email, secrets, frontmatter — into placeholders, and check with one line of grep before publishing. A leaked secret can only be rotated, so the cheapest move is never to write it down.