I’m glad you’re here.

This site is now the main home for my writing: practical notes, essays, guides, and longer-form thinking about the parts of technology that are easy to underestimate until they become important.

I write mostly about self-hosting, software engineering, AI, infrastructure, privacy, and the operational decisions behind running useful systems. Some pieces are beginner-friendly explainers. Some are opinionated engineering notes. Some are (or will be) field reports from trying things, breaking things, fixing them, and turning rough understanding into something more dependable.

The common thread is simple: I’m interested in technology that people can understand, operate, and take responsibility for.

A lot of technical writing ends up in one of two places. The glossy version presents tools as magic, infrastructure as a shopping list, AI as inevitable transformation, and cloud platforms as the default answer before the question has been asked. The hostile version hides useful knowledge behind dense documentation, unexplained assumptions, tribal habits, and advice written as if every reader has already spent ten years inside production systems.

This site is meant to sit between those extremes.

My goal is to write technical material that is serious without being inaccessible, practical without being shallow, and opinionated without pretending there is only one correct way to build things.

What you’ll find here

A large part of this site is about self-hosting.

I do not mean the fantasy version where everything is free, private, effortless, and better than commercial services by default. Real self-hosting is more interesting, and more demanding. It means understanding what you are taking on: Linux servers, DNS, containers, storage, backups, remote access, logs, updates, security, monitoring, hardware choices, hosting trade-offs, and the long tail of maintenance.

Self-hosting can be empowering when it is approached honestly. Running your own services does not automatically make you independent. A badly maintained server can become a liability. A backup that has never been restored is still an assumption. A private service exposed carelessly to the internet is not safer just because it is yours.

That is the kind of nuance I care about.

You will find guides here about Docker, Compose, Linux fundamentals, SSH, VPNs, reverse proxies, TLS, firewalls, storage layouts, backup strategy, restore drills, and the practical difference between “it runs” and “I can keep it alive.” I try to write for people who want to learn properly, not just paste a command and hope.

Another major theme is software engineering.

I’m interested in the parts of engineering that survive beyond the first successful demo: maintainability, architecture, debugging, testing, deployment, technical debt, operational habits, and the gap between clean diagrams and actual systems. Software does not live only in code. It lives in teams, constraints, release processes, infrastructure, habits, documentation, and the ability to understand what will happen when something goes wrong.

That usually makes me less interested in hype around the latest framework and more interested in questions like:

• What makes a system understandable six months later?
• Where should complexity live?
• What should be automated, and what should remain explicit?
• How do we design things so that failure is diagnosable rather than mysterious?
• When is a “temporary workaround” actually the beginning of a permanent architecture?

I also write about AI, but not as a magic trick.

AI is useful. It is also over-marketed, misunderstood, and too often discussed as if judgment no longer matters. My interest is in AI as a practical tool for professionals: writing better prompts, using models for analysis without outsourcing responsibility, reviewing AI-generated code, building AI-assisted workflows, understanding failure modes, and staying clear-eyed about what these systems can and cannot do.

The phrase I keep coming back to is AI without illusions.

That does not mean cynicism. It means using powerful tools without pretending they remove the need for expertise. A language model can help summarize logs, draft code, inspect configuration, generate hypotheses, or improve documentation. It does not know your production environment. It does not own the consequences. It can sound confident when it is wrong. It can flatten important context. It can produce work that looks finished before it is safe.

So I write about AI as something to integrate into professional practice, not something to worship or fear.

Why this site exists

Until now, much of my writing lived on other platforms. That was useful for reach, but rented space is still rented space. This Ghost site is my own place for publishing, organizing, updating, and expanding the material over time.

I have moved roughly a hundred articles here, and the site is no longer a placeholder. It is ready to become the primary place where my work lives.

That matters for a few reasons.

First, I want the writing to have a coherent home. Articles about self-hosting, software engineering, AI, privacy, infrastructure, and maintainability belong together more than they may seem at first. They all circle around the same question: how do we build and operate technology with more understanding and less dependency on hand-waving?

Second, I want more control over the reading experience. A personal site can be calmer, cleaner, and easier to navigate than a feed-driven platform. It can support series, references, updates, and long-running projects without being forced into the rhythm of whatever happens to be popular this week.

Third, I want this place to grow into more than an archive. Some articles will stand alone. Others will become part of larger collections, courses, handbooks, and practical guides. Self-hosting in particular deserves a structured path: from “what is this?” through Linux, networking, containers, storage, backups, security, monitoring, maintenance, and application choices. It should be a learning arc, not a pile of recipes.

Who this is for

This site is for readers who like practical technical writing and do not want to be talked down to.

You may be a developer who wants to understand infrastructure better. You may be a self-hoster trying to move beyond random Compose files copied from GitHub. You may be a technically curious reader who wants more control over your digital life. You may be an engineer trying to make sense of AI without the marketing fog. You may simply enjoy calm, grounded explanations of systems that are usually made more confusing than they need to be.

You do not need to know everything before reading. You should be willing to care about the details.

The details are where systems become real: permissions, ports, mount points, restore procedures, DNS records, firewall rules, update strategies, health checks, logs, identity, trust boundaries, and failure modes. They are not glamorous, but they are often the difference between a setup that feels empowering and one that quietly becomes fragile.

What to expect

Expect practical explanations, careful trade-offs, and strong opinions where they are useful. Expect enough context to understand when those opinions may not apply.

Expect posts that distinguish between a tutorial, a production habit, and a personal preference.

Expect writing that treats beginners with respect and experienced readers as people who still benefit from clear structure.

I will continue publishing new material here and refining the older pieces I have migrated. Some articles may be updated as tools change, as my own thinking improves, or as a topic deserves a cleaner explanation. That is another advantage of having the work here: a site like this can become a living body of knowledge, not just a timeline.

A starting point

Browse around. Pick the topic that matches the problem in front of you.

If you are here for self-hosting, start with the foundations before jumping into application recipes. Learn how the server works, how remote access works, how data survives, and how exposure to the internet changes the risk profile.

If you are here for software engineering, look for pieces about maintainability, architecture, debugging, operational thinking, and the human cost of systems that are clever but hard to understand.

If you are here for AI, expect a practical, skeptical, but not dismissive approach. The tools are real. The productivity gains can be real. The risks are also real. The work is learning where they fit.

Above all, this site is a record of trying to understand technology in a way that survives contact with reality: how to start things, keep them understandable, keep them maintainable, know what you are responsible for, and build enough judgment that tools become tools again.

Welcome to Thomas Byern’s Field Notes.