BLOG - The Self-Hosting Balancing Act

Jason Kuehl — Wed, 27 May 2026 12:10:49 +0000

Self-Hosting Is A Balancing Act

Self-hosting is like a counterweight scale. You weigh your options when deciding whether to self-host something. That scale will look drastically different depending on the person and the environment they have set up, and it can change as people gain more knowledge.

One side of that scale is reliability, and the other is stability. In a home lab context, stability is a system's ability to remain steady and return to its normal state after a disturbance. For example, if you run an update on your home media server and something breaks, good stability means your server can recover and work as expected again without too much hassle. Reliability, on the other hand, is the probability that the system will consistently perform its intended function without error over a specific period (per M$ documentation). Think of reliability as making sure your media server is always up and running whenever your family wants to stream a movie, week after week, with very few interruptions.

When you look at software to host to replace other services, let's use web hosting as an example, the easy choice to start. Maybe the choice to self-host is due to cost, data control, or security. Or maybe you just don't care and want to, just to learn.

It all comes down to how much risk you are willing to accept with self-hosting, and what level of reliability you need. To make these choices clearer, here's a quick step-by-step approach I use when deciding between different tools or setups:

Define what you want to host and your goals (for example, personal use, learning, or production).
Consider how critical the service is: Would it be a big problem if it went offline? How much downtime can you tolerate?
Assess your technical comfort and available time. Are you ready to troubleshoot breaking changes, or do you need something simple and stable?
Research stable, reputable options that fit your needs (for example, using nginx or Apache for a web server if you want reliability and stability).
Think about your environment: Do you want to try containerization with Docker Swarm or Kubernetes? Or are you ready for more advanced setups like a multi-node Proxmox cluster?
Finally, balance the temptation of new technologies versus the trustworthiness of established solutions if you want fewer headaches.

The options are endless, and each decision you make will shape how you build things.

It all comes down to this: after you figure out all that, now risk. How mad will I be if I lose this data? How upset will I be if I can't access this web server? Will my family disown me, or will my wife and kids be upset? The different things that can be run will always have distinct risk factors. Which again goes back to you weighing the options of running these different services.

To make this even more practical, here is a simple risk assessment checklist you can use before self-hosting a service:

How critical is this service or data to me or others using it?
What would happen if this service went offline for an hour? A day? A week?
What is the impact if some or all of the data is lost?
Could downtime affect my work, my family, or anyone else who depends on it?
Do I have a recent backup that I can actually restore from if things go wrong?
Will I be able to resolve issues quickly, or will lack of access create major headaches?
Are there any legal or compliance concerns with hosting this service or storing this data myself? Going through these quick questions before setting up anything new can save you a lot of frustration and help you decide if the risks are worth the rewards.

At the end of the day, you might not care about any of this, but it becomes a time to do. But for the love of God, please have a good backup strategy for the data you actually care about that doesn't live within your own self-hosted environment.

Science Fiction Was the Roadmap

Jason Kuehl — Wed, 06 May 2026 12:41:30 +0000

I don't think people realize how much Star Trek has prepared us for using AI as we are using it today.

My interaction with Co-Pilot, Gemini, or Claude, if you look at it, is very similar to how they're using AI in Star Trek. It's just a conversation with the computer to get outputs of the things that they're looking for.

You can even see how interacting with the computer in Star Trek changed over many generations, from simply reading fundamental data to providing output to what we have now in TNG, which could be construed as vibe coding if you consider the holodeck.

When I say "vibe coding," I mean the process of describing what you want in natural language, focusing on the intended feel or high-level concept rather than writing explicit code instructions. This approach is sometimes controversial because some people feel it yields less precise or predictable results, and they worry about a lack of control over what the AI generates.

The holodeck is a magical place that allows people to just talk about what they want, and it generates a vibe, which is what a lot of people are hating on vibe coding right now. However, I have been loving it for its ability to generate the things I've always wanted to create. It's literally opened up a new world for me to build the silly things I have always wanted. Which, if you think about it, is the holodeck.
The holodeck was also used for trading, teaching, and tactical purposes. But those were more finely tuned and highly refined programs. For a lot of us, we're starting to use DSLs with AI to make sure the output from our AI of choice builds exactly what we're looking for for those specific purposes.

(A DSL, or domain-specific language, is a specialized type of programming language designed for a particular task or field. In the context of AI, that could be something like a language tailored for creating educational simulations or tactical training scenarios, making our interactions much more precise and aligned with the needs of the user.)
You even have hallucinations in Star Trek. There have been many episodes of DS9 or TNG where they're given inaccurate data.

For example, in the TNG episode "The Naked Now," the Enterprise's computer provides misleading information due to a contaminant affecting the crew and the ship's systems. Similarly, in DS9's "Civil Defense," the station's computer triggers an outdated security protocol, causing chaos for the crew based on faulty or obsolete logic.

In these cases, the computer straight up has the wrong data, and the people requesting that information are seeing it as a hallucination because they say the data is incorrect.

Within this whole world, you still have human-in-the-loop control. It's still a person, at the end of the day, who's making those final decisions. Sure, the computer is doing all the heavy lifting, but the person is still making the fine-grained decisions about how they want that to look, work, and interact with others.

This is not the first time Star Trek has done this. Throughout the series, Star Trek has predicted and even inspired the creation of a wide range of technologies.

Here's a look at some of the biggest ones, when Star Trek introduced them, and how long it took for reality to catch up:

Communicator → Flip Phone — Introduced in TOS (1966). Motorola's StarTAC flip phone arrived in 1996, a 30-year gap.
PADD → Tablet / iPad — Introduced in TNG (1987). Apple's iPad launched in 2010—a 23-year gap.
Universal Translator → Google Translate — Introduced in TOS (1966). Real-time spoken translation became practical in the 2010s. ~50-year gap.
Voice-Activated Computer → Siri / Alexa — Introduced in TOS (1966). Siri launched in 2011, Alexa in 2014. ~45-year gap.
Viewscreen → Video Calling — Introduced in TOS (1966). Skype launched in 2003, and Zoom went mainstream in 2020. 37–54-year gap.
Automatic Doors — Introduced in TOS (1966). Became commercially common through the 1970s–80s. Nearly simultaneous.
Holodeck → VR / AI Environments — Concept originated in 1968, named and featured in TNG (1987). Consumer VR arrived in 2016; truly immersive AI environments are still emerging. Still not fully there.

These examples show how Star Trek has consistently anticipated future innovations, making its vision feel as relevant now as it was decades ago.
Also, within Star Trek, the computer is not a replacement for anyone. It is a tool used to extend their knowledge and help them become better people. You still have all these people running engineering. You still have all these people running hydroponics and so on, running tactics and making decisions.

I think if Star Trek has shown us anything, it's that yes — there are definitely ways to misuse AI, and people will do that — but the vast majority will use it as a tool to better themselves.

Of course, Star Trek doesn't shy away from showing what can go wrong, either. For example, episodes like "The Ultimate Computer" explore what happens when AI systems, such as the M-5 computer, are given too much control, leading to unintended and dangerous consequences.

In the real world, we've already seen issues such as biased outputs, loss of privacy, and reliance on flawed data when using AI systems. By highlighting both the positive uses and the potential pitfalls, Star Trek encourages us to think critically about how we develop and interact with these powerful tools.

DEV Community: Jason Kuehl

BLOG - The Self-Hosting Balancing Act

Science Fiction Was the Roadmap