Series

Longer stories, kept in order.

Grouped Field Notes for projects and subjects that need more than one article.

Article series

Building Eldritch IT

14 parts
  1. Why I Started Eldritch IT Why I am building a deliberately small IT company around trust, documentation, and stable systems instead of growth for its own sake.
  2. Registering My Texas LLC My experience forming Eldritch IT in Texas—and why submitting the paperwork felt more difficult than completing it.
  3. Building the First Version of EldritchIT.com Why I stopped chasing a perfect business website and launched a focused version I could improve with real feedback.
  4. Why I Chose Astro and Cloudflare for eldritchit.me How I split writing, version control, deployment, and public delivery across Astro, GitHub, and Cloudflare.
  5. Building eldritchit.me with Astro What I learned by turning Astro's blog starter into a publication I could understand, maintain, and keep improving.
  6. Why I Chose Cloudflare Why Cloudflare fit my requirements for DNS, edge TLS, Git-connected deployment, and public delivery without making the Eldritch IT websites depend on my homelab.
  7. What Astro Build Failures Taught Me as a Beginner How real build failures taught me about content schemas, layouts, static routes, deployment logs, and the limits of generated code.
  8. Cleaning Up an AI-Generated Site What it took to turn an AI-assisted Astro starter into a site I understood, trusted, and could maintain.
  9. How I Kept Drafts Out of Astro Production Builds The layered controls I use so unfinished Markdown can stay in the repository without reaching pages, feeds, search, or build output.
  10. Why I Write Engineering Notes in Public Publishing completed technical work forces me to separate evidence from memory, useful architecture from private identifiers, and lessons from the exact environment that produced them.
  11. Order from Complexity as an Operating Standard How the Eldritch IT tagline became a practical test for ownership, documentation, recovery, deployment, and support work.
  12. Building One Technical Identity Across Two Sites How I separated a business website from a technical journal without making them look or sound like unrelated projects.
  13. What Walking Into Local Businesses Taught Me About Selling IT I stopped treating outreach like a marketing exercise and started learning what a small business actually gives you time to prove.
  14. The Build Passed. Production Did Not Move. What a green GitHub build and a failed Cloudflare deployment taught me about separating source validation, deployment credentials, and the live site.

Article series

Homelab

22 parts
  1. Why I Built a Homelab How a collection of useful services became a place to learn networking, storage, containers, recovery, and calmer troubleshooting.
  2. The Storage Host Became a Contract, Not Just a Server Separating storage from application compute forced me to define ownership, permissions, failure boundaries, and recovery instead of treating shared disks as a transparent dependency.
  3. Why I Self-Host Jellyfin Why I chose Jellyfin for my media library and what running it taught me about storage, containers, networking, metadata, and client devices.
  4. Why Docker Became My Default, Not My Rule Containers gave my homelab a repeatable application model, but the useful part was the discipline around persistence, networking, updates, and recovery.
  5. Reachable Is Not the Same as Playable What self-hosted game servers taught me about proving a network path from application startup to a real remote session.
  6. Why I Chose UniFi Why I chose UniFi for a home network that needed segmentation, wired multi-AP coverage, useful visibility, and room to experiment without becoming a second full-time job.
  7. The Application Host Is Replaceable on Purpose Separating application compute from authoritative storage made my homelab easier to rebuild, troubleshoot, and change without pretending a second machine is automatic redundancy.
  8. Pterodactyl Taught Me to Separate the Control Plane From the Game Running Pterodactyl at home made game hosting easier, but the bigger lesson was learning to separate management intent, node control, Docker execution, gameplay, storage, and recovery into distinct failure domains.
  9. What an Unresolved Satisfactory Connection Taught Me Why a game server that worked locally but failed remotely became a better lesson in evidence, network boundaries, and honest troubleshooting than a guessed fix ever could.
  10. When the Homelab Became Household Infrastructure What changed when experimental self-hosted services became useful enough that other people expected them to work.
  11. The Rack Planning Pass That Exposed My Real Constraints Why rack-unit count stopped being my definition of capacity once I planned around depth, power, airflow, cables, weight, and service access.
  12. The Backup Readiness Review That Changed My Build Order How inventorying data, configuration, credentials, and restore dependencies exposed what my homelab could and could not actually recover.
  13. What My Homelab Taught Me About Calm Troubleshooting How repeated homelab failures taught me to control uncertainty, separate layers, preserve evidence, and make smaller, more defensible changes.
  14. Turning Lab Work into Reusable Support Skills The useful part of a homelab is not copying configurations into production. It is practicing the habits that survive a change in platform, scale, and ownership.
  15. Why Container Paths Have to Match Across the Media Stack How inconsistent Docker mounts create failed imports, duplicate copies, broken hardlinks, and misleading permission errors across a media automation stack.
  16. What Hardware Transcoding Actually Changed in Jellyfin How GPU acceleration reduced CPU pressure without removing codec, subtitle, network, container, and client constraints.
  17. The Checklist I Use Before Updating a Container A practical change process for protecting state, controlling scope, validating outcomes, and rolling back Docker Compose services deliberately.
  18. Before I Add a Service, I Write Down the Job The admission test I use to keep useful homelab services from turning into undocumented maintenance, accidental dependencies, and permanent clutter.
  19. When an Empty Mount Looked Like an Empty Library A healthy container and an empty media library exposed a quieter failure underneath: the path existed, but the filesystem I expected was not mounted there.
  20. The Browser Opened the Game. Storage Stopped It. Why a browser-based game that loads successfully can still fail before play, and how to test the real storage budget instead of blaming the network.
  21. The Service Existed. Swarm Had Nowhere to Run It. Diagnosing a Docker Swarm service that exists but has no running tasks.
  22. The Whitelist Was On. The Server Still Needed an Access Plan. What a Pterodactyl-managed Minecraft server taught me about separating player authorization, account authentication, network exposure, and panel access.

Article series

Homelab Fundamentals

1 part
  1. Homelab Architecture Handbook: Designing a Reliable Homelab from Scratch (2026 Edition) A practical architecture and operations handbook for planning a homelab from scratch: workloads, hardware, storage, networking, platforms, security, monitoring, backups, recovery, and the order to build them in.

Article series

Homelab Operations

5 parts
  1. A Black Screen Does Not Prove a Failed Boot What an unproven headless-boot failure taught me about separating POST, Linux boot, display output, and service health.
  2. When Compatibility Became Part of the Architecture What maintaining old and current versions of the same application taught me about treating compatibility as a boundary instead of a temporary inconvenience.
  3. I Had Enough Hardware for a Cluster. I Chose Not to Build One. Why having spare machines, spare disks, and a more elaborate architecture available was not enough reason to replace a homelab that already worked.
  4. Before I Buy Another Switch, I Check What the Existing Ports Can Actually Do A small homelab port shortage reminded me that physical port count, topology, and device capabilities are different problems, and that hardware purchases should come after understanding the path.
  5. Spare Hardware Is Part of the Recovery Plan Why an unused computer can be more valuable as known-good recovery capacity than as one more permanent homelab node.

Article series

Lessons Learned

8 parts
  1. The Test Matrix I Use Before I Trust a Change How I validate the original outcome, dependencies, clients, restart behavior, recovery, and failure paths instead of settling for a green dashboard.
  2. A Backlog Is Not Finished Until the Ideas Are Distinct What rebuilding a crowded draft queue taught me about overlap, evidence, privacy, and deciding when a field note is actually ready to publish.
  3. Buy Once, Cry Once, Sometimes A practical framework for deciding when better hardware saves money and when an expensive purchase only creates a different kind of problem.
  4. What Goes in Public Documentation, and What Stays Private A practical boundary for publishing useful technical detail without exposing the environment that produced it.
  5. The Mistakes I Record After Every Project The retrospective format I use to turn failed assumptions into better tests, guardrails, and documentation without rewriting the project into a cleaner story than it really was.
  6. The Difference Between Maintenance and Endless Tinkering How I decide whether a change preserves a service, solves an observed problem, or simply reopens a finished project.
  7. A Project Is Finished When It Can Survive You Walking Away Why I stopped treating completion as a feeling and started defining done through scope, evidence, ownership, reproducibility, and a maintenance path.
  8. Shipping Gave Me a Better Definition of Progress Why putting real work into production changed how I measure progress, choose revisions, and decide when another pass is actually worth doing.

Article series

Linux

1 part
  1. Linux Mint Is Where I Would Start a Windows User Why I think Linux Mint, especially Cinnamon, is one of the best places to start when someone wants to leave Windows without relearning the desktop all at once.

Article series

Reliable Self-Hosting

1 part
  1. The Definitive Guide to Linux File Permissions for Self-Hosted Services (2026 Edition) A practical, security-conscious guide to Linux ownership, modes, groups, ACLs, umask, Docker UID and GID mapping, network shares, SELinux, AppArmor, and permission troubleshooting.

Article series

Secure Self-Hosting

1 part
  1. The Definitive Guide to Tailscale for Homelabs (2026 Edition) A practical guide to designing, deploying, restricting, validating, and recovering private remote access to a homelab with Tailscale.

Article series

Self-Hosted Media

3 parts
  1. The Definitive Guide to Jellyfin on Ubuntu with Docker (2026 Edition) A practical, start-to-finish guide to deploying, securing, accelerating, backing up, upgrading, and troubleshooting Jellyfin 12 on Ubuntu Server with Docker Compose.
  2. The *arr Stack on Ubuntu with Docker: Architecture & Reference Guide (2026 Edition) A reference guide to the storage, identity, networking, security, recovery, and service boundaries behind a Docker-based *arr media automation stack.
  3. Build Your *arr Stack: A Step-by-Step Docker Media Automation Guide A practical start-to-finish Ubuntu and Docker walkthrough for building a media automation stack with Sonarr, Radarr, Lidarr, Prowlarr, Bazarr, Seerr, SABnzbd, Deluge, Gluetun, and Jellyfin, adapted from TRaSH Guides and Mathias Furenes' Synology ARR-stack guide.

Article series

Windows

9 parts
  1. Preserve the Evidence Before Reinstalling Windows Why I capture symptoms, hardware health, logs, data, encryption status, and trust indicators before a broad Windows repair erases the useful context.
  2. How My Recovery USB Became a Curated Toolkit Why I replaced an ever-growing pile of utilities with a documented, reproducible set of trusted Windows recovery media and tools.
  3. The Windows Tasks That Made PowerShell Earn Its Place How repetitive inventory, connectivity, service, file, registry, and event-log questions became small, reviewable PowerShell workflows instead of another layer of complexity.
  4. What Standardization Changed About My Troubleshooting How a known Windows baseline made configuration drift useful evidence without pretending every device or user should be identical.
  5. Repair, Reset, or Reinstall: Choosing the Right Windows Recovery Boundary How I decide between targeted repair, Windows repair reinstall, Reset this PC, an in-place reinstall, and a clean build without wiping by reflex.
  6. The Deployment Handoff Checklist I Actually Use The concise record that connects requirements, build decisions, validation, recovery, and the next support owner.
  7. Enterprise Support Taught Me That Closure Is Not the Same as Ownership What enterprise help-desk work taught me about evidence, consistency, escalation, handoffs, documentation, and owning the user's actual outcome.
  8. Windows Recovery Works Better as a Managed Workflow Why intake, evidence, trust, escalation, validation, and handoff matter more than treating the installer as the center of Windows recovery.
  9. The Best Windows Build Was the One That Passed the Test What rebuilding an older PC for school taught me about optimizing endpoints for requirements instead of chasing the cleanest possible install.