Skip to content

Content Tracker (Path C)

Goal: Convert Kay's homelab + engineering work into a sustained content engine that demonstrates skills, builds reputation in DevOps / SRE / Platform Engineering circles, and creates evergreen artifacts for career positioning.

Status: NEW path opened 2026-06-07 (Session 10 close-out). Triggered by Kay's recognition that the LinkedIn content plan + existing blog infrastructure (iamkay.eu + oak-techx.com) constitute a serious distribution channel — "it has become a serious path now."

Cross-references: - linkedin-content-plan.md — 30-post LinkedIn editorial calendar (the seed material) - learning-tracker.md — Path B; content writing reinforces learning (writing forces depth) - homelab-tracker.md — source of technical material - SESSION-LOG.md — forensic detail that becomes story material - CLAUDE.md §0 + Architecture decisions — guardrails for what's safe to publish

1. Mission

Build a body of public work over 6-12 months that:

  1. Demonstrates technical depth — not "hello world" tutorials, but real architecture decisions, gotchas, and patterns from production-like systems.
  2. Establishes credibility in 3-4 named niches: self-hosting, Proxmox/virtualization, network architecture, identity & secrets management.
  3. Is searchable + linkable — recruiters and peers find Kay through specific technical content, not just LinkedIn headlines.
  4. Feeds back into work — writing a post forces clarification of a decision; explaining a system to a public audience surfaces gaps in your own understanding.
  5. Compounds over time — each post is evergreen (works in 6 months too), can be repackaged (LinkedIn → blog → newsletter → talk → repo README).

Non-goals: - Vanity metrics (likes/followers in isolation). Saves > likes > comments > follows for skills-demonstrating content. - "Hot takes" content (e.g. "Kubernetes is dead"). The audience for that is different and the value decays fast. - Paid content / sponsorships in Phase 1. Build the body of work first; monetize (if ever) later.

2. Distribution channels

Channel Format Audience Owner Status
LinkedIn Short posts (1000-1300 chars), 1 image Tech peers, hiring managers, mid-senior engineers Kay's personal account Existing; cadence not yet started
iamkay.eu Long-form blog posts (1500-4000 words), code blocks, diagrams Tech peers searching by topic, Kay's professional brand Kay Blog component exists; not currently active
oak-techx.com Same long-form format; tilted slightly toward business / consulting framing Potential clients, business leaders, tech-adjacent Kay (Oak Techx brand) Blog component exists; not currently active
GitHub (kanu-kingsley / oak-techx) Repo READMEs + write-ups of public-safe projects Engineers reading source Kay Light usage; can grow
Newsletter (future, optional) Weekly digest of homelab + writing Subscribers who opt in TBD NOT STARTED
YouTube / talks (future, optional) Long-form walkthroughs / conference talks Engineers wanting deeper context TBD NOT STARTED

Channel cross-posting rule

Every long-form post lives in ONE canonical home (iamkay.eu OR oak-techx.com), and is then: 1. Excerpted to LinkedIn as a short post (700-1000 chars) with a "read full → " link to the canonical post. 2. Excerpted to GitHub as a repo README or wiki note if there's runnable code. 3. Referenced internally in homelab-tracker.md or wherever the work was done.

The canonical home pattern: - iamkay.eu: deep technical posts where Kay is the primary protagonist ("how I…"). First-person, personal voice. - oak-techx.com: same depth but framed as "Oak Techx" (the brand) doing the work. Third-person OR collective-first-person ("we"). Useful for client-facing positioning later.

Decision: Path C Phase 1 (first 30 LinkedIn posts) all link back to iamkay.eu as canonical. Oak Techx blog gets activated in Phase 2 when consulting-shaped content starts (e.g. "How we audit a small-team Kubernetes stack").

3. Editorial pipeline

                ┌─────────────────────────────────────────────────┐
                │  IDEA SOURCES                                   │
                │  - homelab work (homelab-tracker.md)            │
                │  - gotchas (SESSION-LOG.md, build.log files)    │
                │  - architecture decisions (ADRs in CLAUDE.md)   │
                │  - readers asking questions                     │
                └─────────────────────┬───────────────────────────┘
                                      │
                                      v
                        ┌─────────────────────────┐
                        │  IDEA BACKLOG           │ ← all ideas land here
                        │  (Section 5 below)      │
                        └─────────┬───────────────┘
                                  │ Friday: pick 1-2 for next week
                                  v
                        ┌─────────────────────────┐
                        │  DRAFTING               │
                        │  Markdown in D:\PVE\    │
                        │  drafts\YYYY-MM-DD-     │
                        │  <slug>.md              │
                        └─────────┬───────────────┘
                                  │ Drafts get reviewed by Claude
                                  │ for technical accuracy + structure
                                  v
                        ┌─────────────────────────┐
                        │  PUBLISH                │
                        │  - Long-form to blog    │
                        │  - Excerpt to LinkedIn  │
                        │  - Repo update if needed│
                        └─────────┬───────────────┘
                                  │
                                  v
                        ┌─────────────────────────┐
                        │  TRACK                  │
                        │  Section 6 below        │
                        │  + analytics later      │
                        └─────────────────────────┘

Drafting cadence (initial)

  • Friday evening: pick 1-2 ideas for next week. Outline.
  • Saturday morning (1-2 hours): write draft. Don't perfect; ship the first cut.
  • Sunday: read draft cold. Cut 30%. Add concrete example. Ship to canonical home.
  • Monday morning: post LinkedIn excerpt.
  • Mon-Wed: respond to comments. Add learnings back into the tracker.

If a week is too busy: skip the publish step but still capture the idea. Don't pause the backlog.

Quality bar per post

Each long-form post must include: 1. A specific real-world artifact (config snippet, diagram, before/after, command sequence). No abstract-only posts. 2. A clear "why I chose X over Y" somewhere in the post — even if it's a small subdecision. 3. A failure / gotcha section — what went wrong, what I tried, what worked. This is the highest-engagement element for technical posts. 4. **A "what I'd do differently" or "what I'm watching" forward-looking line.

Each LinkedIn excerpt must include: 1. A specific hook (number, contrarian framing, or named problem) 2. The takeaway in plain language 3. A read-more link to canonical 4. Hashtags (3-5 max)

4. Skills demonstrated (recruiter / portfolio mapping)

The content series, taken as a whole, demonstrates competency in:

Skill area Posts that demonstrate
Linux system administration 1, 2, 4, 8, 19, 25
Network engineering (VLANs, pfSense, BGP-future) 3, 4, 10, 28
Container orchestration (Docker, LXC, Compose) 11, 12, 13, 15, 21
Identity & access management 6, 7, 8, 9
TLS / PKI / DNS-01 / DNSSEC 10, 14, 22
Reverse proxy + edge architecture 8, 14, 22, 23
Observability (Prometheus, Grafana, Loki) 16, 20
Backup & disaster recovery 17, 18, 25
Storage (RAID, btrfs, ZFS-future) 5, 20, 25
Security engineering 6, 7, 8, 19
Documentation as code / SRE practices 26, 27, 28, 30
Legacy hardware integration 1, 19
Multi-cloud / hybrid (Cloudflare Tunnel, R2 future) 8, 22

When updating your CV or LinkedIn skills, point at the actual posts as evidence. The phrase "demonstrated by [post URL]" is more credible than "5 years experience with X."

5. Idea backlog

Status legend: 🟢 ready to draft / 🟡 needs more context / 🔵 future, blocked

From linkedin-content-plan.md (30 ideas seeded 2026-06-07)

The 30 posts in linkedin-content-plan.md are all 🟢 ready-to-draft.

Additional ideas (open backlog — append as you think of them)

🟢 "Why I run my homenas inside a Proxmox VM instead of bare-metal" — VM 189 architecture decision; trades performance for portability + PBS-backup-ability.

🟢 "Migrating from k8s-on-NFS to dedicated ZFS pool" — when ZFS lands, write up the migration. Pre-condition: future.

🟢 "How I think about $/GB for homelab storage decisions" — comparison of P410i SAS HDD vs new SSDs vs cloud cold storage. Practical math.

🟢 "The break-glass card pattern for homelab recovery" — paper printout with master passwords + recovery IPs. Why physical media beats digital for last-resort. (Once you actually print it — gated on Authelia which is done.)

🟡 "Pick your battles: when I deliberately don't use containers" — VM vs LXC vs Docker-in-LXC decision matrix. Write after the G5 cluster lands and you have a concrete contrast.

🟡 "My monitoring stack costs $0/month — and I get more than DataDog Free" — back-of-envelope cost comparison. Write after 2-3 months of production observability.

🟢 "How I tracked down a redirect loop with curl -v in 45 minutes" — detective story format, the cloudflared 502 issue.

🟢 "omv-rpc: a tool every OMV user should know about and most don't" — practical scripting tutorial. Includes the sentinel UUID gotcha.

🟢 "What pct and qm can do that the Proxmox web UI hides" — practical CLI cheat sheet.

🟢 "My backup retention policy explained: 3-7-4-12-2" — GFS deep dive with actual storage math.

🟢 "Diary of an iLO 3 SSH key rotation" — DSA key gotcha, oemhp_loadSSHKey method. Already in post #19; could split off as its own deep dive.

🟢 "Why I keep all secrets out of git (and how)" — Vaultwarden + per-LXC build scripts + the 11-credential-cleanup story.

🟡 "My session log: 6 months of homelab tinkering analyzed" — wait until you have 6 months of SESSION-LOG.md. Visualize: hours per phase, errors per session, what topics came back most.

🔵 "Building a 4-node Proxmox HA cluster: months 1-3" — wait until G5 cluster work starts. Series of 3-4 posts.

🔵 "ZFS on Linux: my first pool design" — wait until HBA + drives land.

🔵 "Self-hosting Jellyfin for a 5-person household" — wait until D.2 ships.

🔵 "Cloudflare R2 vs Backblaze B2 for homelab cold backup: my decision after 6 months" — wait until off-site backup runs for 6 months.

🟡 "What it means to actually own your data: 18 months of family-cloud usage" — wait, ~12-18 months of Nextcloud production.

6. Published log

Track each post as it ships. Add columns later if useful (impressions, saves, comments).

# Date Title Channel Canonical URL Status
(none yet)

7. Tools & infrastructure for content production

Phase 1 (current — minimal)

  • Drafting: VSCode + Markdown
  • Images / diagrams: draw.io (free, self-host), excalidraw, or screenshot-based
  • LinkedIn scheduling: LinkedIn native scheduler (free)
  • Blog publishing: existing iamkay.eu + oak-techx.com components (manual upload)
  • Analytics: LinkedIn's built-in + Google Analytics on blogs (if installed)
  • Code snippet rendering: blog's own syntax highlighting

Phase 2 (if cadence holds 3 months)

  • Buffer or Hootsuite: queue 30+ posts at once for hands-off scheduling
  • Plausible or Umami: privacy-friendly analytics, self-hostable in homelab (another Path C × Path A intersection — practice what you preach by self-hosting analytics)
  • Newsletter: Ghost (self-hosted) or Substack (free tier) for email subscribers
  • Diagram CDN: store diagrams in a versioned location (homenas SMB share?) so blog posts have stable images

Phase 3 (if content becomes a serious revenue/positioning lane)

  • Notion or Obsidian: better idea-capture across mobile + desktop than .md only
  • Studio for video: OBS + simple lighting if you ever do YouTube walkthroughs
  • Mic upgrade: for podcast or talk audio
  • Conference talk submissions: SREcon, KubeCon, FOSDEM — track CFP deadlines

8. Risk & guardrails

What NOT to publish

Hard rules:

  1. No credentials, tokens, keys, hashes, or anything from /root/*-build/ files, even if rotated. Even hashes can have side-channel exposure.
  2. No PII about Kay's family, family devices, or other family members. Use kay for personal examples; never use other names without explicit consent.
  3. No internal IPs for services that face the internet (the Cloudflare Tunnel route maps cloud.iamkay.eu to internal — don't publish "internal IP is 10.0.10.60"). Generic placeholders like 10.x.y.z are fine.
  4. No client / employer information beyond what's publicly disclosable. Default: don't mention current or past employers in homelab posts.
  5. No vendor security issues discovered during routine work — disclose to vendor first, follow responsible disclosure timeline, publish only after fix is widespread.

Soft rules:

  1. Architecture decisions Kay is mid-debating — publishing before locked = inviting unsolicited "you should…" comments that pollute the decision-making. Wait until decision is locked and shipped before writing.
  2. Half-finished projects — wait until you have a real result. "I'm trying X" posts age badly. "I shipped X, here's what I learned" ages well.
  3. Anything that contradicts CLAUDE.md §0 — if hard safety rule says NEVER, post doesn't either.

Editorial review

Before publishing each long-form post: - Read aloud once (catches awkward phrasing) - Run through Claude for fact-check: "Read this post and flag any technical inaccuracy or thing that someone with domain expertise would object to." - Check images for accidentally-screenshot'd secrets (terminal scrollback, browser tab titles, file names with passwords in them). - Spell-check.

9. Measurement

Tracking the right metrics matters more than tracking many metrics. After 30 days of posting, evaluate:

Vanity metrics (look at, don't optimize for)

  • Followers gained
  • Impressions per post
  • Likes per post

Signal metrics (what actually matters)

  • Saves per post — indicates "I want to reference this later" = highest-quality engagement for technical content
  • Comments asking questions — indicates content provoked thought. Quantity of substantive questions per post
  • Inbound DMs asking for clarification, follow-up, or work — indicates audience sees Kay as authority on the topic
  • Click-throughs to canonical blog — measures whether LinkedIn excerpt successfully drives readers to long-form
  • Repeat readers on canonical blog (returning visitors / direct traffic share over time)

Career-impact metrics (annual)

  • Recruiter DMs that reference specific posts — "I saw your post about [X]" beats "I saw your profile"
  • Conference talk invitations or CFP acceptances
  • Quote requests from journalists or podcast hosts
  • Job offers / contract opportunities where the content was a factor

After 3 months: if signal metrics are flat, audit content quality (probably too generic) before audit cadence (probably fine).

10. Long-form post format template

Use this template when drafting posts for iamkay.eu / oak-techx.com:

---
title: "Title that includes the specific thing (not the abstract topic)"
date: YYYY-MM-DD
canonical: https://iamkay.eu/blog/<slug>  # if cross-posting
tags: [proxmox, lxc, networking]
author: Kay
reading_time: 8 min
---

# Title (matches the title above)

## The problem

(2-4 short paragraphs. Set up the specific situation. Avoid "in this post we'll cover…" — get to the action.)

## What I tried (and what failed)

(Show the dead-end attempts. This is the most valuable section for readers and the highest signal for engagement. Honest failure beats successful tutorial.)

## The fix

(Show the working approach. Code blocks. Commands. Diagrams. Be specific.)

## Why this works

(2-3 paragraphs of mechanism. Why does the fix work? What's the underlying principle?)

## What I'm watching / what I'd do differently

(Forward-looking. What's the next failure mode? What scale breaks this? What would you do with infinite time?)

## Resources

- Link to the relevant homelab-tracker section (public version if there is one)
- Link to upstream docs
- Link to related posts

LinkedIn excerpt format:

[Hook — 1 short sentence with a number or contrarian framing]

[Body — 2-3 short paragraphs. The story arc: problem → attempt → fix. Lines of 1-2 sentences for scan-ability. Whitespace between paragraphs.]

[Takeaway — 1 line, the "so what?"]

Read the full write-up: [link]

#hashtag1 #hashtag2 #hashtag3

11. Cadence calendar (initial 6 months)

Phase Cadence Distribution focus Goal
Phase 1 (months 1-2) 1 LinkedIn post/week + 1 blog post every 2 weeks LinkedIn primary; blog secondary Build the muscle. Don't burn out.
Phase 2 (months 3-4) 2 LinkedIn posts/week + 1 blog post/week LinkedIn primary; iamkay.eu blog active Test what resonates. Adjust topic mix.
Phase 3 (months 5-6) Same + 1 oak-techx.com post/month Activate Oak Techx brand Position for consulting-shaped content

After 6 months: review. Cut what's not working. Double down on what is.

Do not commit to a cadence that requires more than 4 hours/week. That's the burnout boundary for sustainable content production around a full-time job + homelab + family.

12. Path C × other paths cross-references

  • Path A (project-tracker.md): every Path A deliverable (GitLab setup, staging VMs, etc.) becomes a candidate Path C post.
  • Path B (learning-tracker.md): every Path B curriculum item (ZFS, k8s, networking deep-dives) becomes a content series. "Learning in public" is the underrated pattern.
  • Path D (home-cloud-tracker.md): family-cloud posts (Nextcloud, Jellyfin, CalDAV, etc.) appeal to a specific audience (parents + tech enthusiasts) — surprisingly engaged niche.

Path C feeds back into all three: writing about a thing forces you to understand it deeply (Path B), surface decision-points more clearly (Path A architecture), and uncover gaps in user experience (Path D).

13. Maintenance schedule for this tracker

  • Weekly (Friday): pick next week's drafts; update §5 backlog; mark anything published in §6.
  • Monthly: review §9 metrics; cut underperforming topics; promote 🟡 ideas to 🟢 if context now exists.
  • Quarterly: re-evaluate cadence (§11). Decide on tooling upgrades (§7).
  • Annually: portfolio review. Audit which posts to feature on CV / About page.

End of Path C tracker. Mission: build a body of public work that proves Kay's technical depth. Method: ship one excellent post at a time, never sacrifice quality for cadence, let the body of work compound.