Networking · Infrastructure · Monitoring

Beyond the Internet — Watching the Network.

When I first started building my homelab, I wasn't trying to create a lab at all.

I was simply solving a problem for myself. Normally, I build things because a client asks for them. This time, I was the client. Well — the direct client, not the final one.

One service became two. Two became five. Then ten. Before I realized it, the homelab had grown into something that other people relied on every day.

And that changed everything about how I needed to think about it.

Sometimes the internet isn't the problem. Sometimes the network still has work to do — and nobody knows it until someone notices that the photos aren't syncing.

The Problem

The network might still appear online while something important is broken.

A while ago, I created a simple troubleshooting guide so anyone in the house could recover the internet if it went down. That solved one problem.

But the network is much more than internet access now. Today the homelab runs photo storage, a music server, a DNS filter, a firewall, a Cloudflare Tunnel, a service launcher, and an external management system for a client. Each of these services can fail independently — and when one does, the network might still appear "online" while an important part of it is actually broken.

That's when I realized I didn't need another troubleshooting guide. I needed visibility.

The Solution

One screen. Five services. Green or red.

I wanted anyone to be able to glance at a screen and immediately know whether everything was healthy, what service was down, and whether something needed attention. No commands. No SSH. No digging through logs.

Uptime Kuma — a self-hosted monitoring tool — runs in Docker on the NUC. It checks each service every 60 seconds and shows a simple status: up or down. That's all anyone needs to see.

Uptime Kuma — 5 services monitored, all green.

Monitored services

🔥 Firewall — OPNsense · 192.168.2.1
🛡️ DNS — Pi-hole · dns.home:8080
📷 Fotos — Immich · fotos.home:2283
🎵 Music — Navidrome · music.home:4533
🔧 Taller — taller.creativelydifferentbuilds.com

The Physical Dashboard

A repurposed Samsung A51 — always on, always visible.

The monitor lives on a Samsung A51 running Fully Kiosk Browser in kiosk mode — screen always on, always showing the status of every service. It connects to Uptime Kuma over the local network at monitor.home:3001.

The goal is simple: anyone in the house — whether they understand the technical details or not — can glance at the screen and know if something needs attention. Green means everything is working. Red means something needs a look.

Samsung A51 repurposed as a physical dashboard — always on, always visible.

The Launcher

Access for the family — no technical knowledge required.

Alongside the monitor, the service launcher now includes a card for Uptime Kuma. Anyone in the house opens servicios.home:8888 from any device — phone, tablet, or PC — and has direct access to every available service. No IP addresses. No ports to remember. Just names.

The Monitor card is now in the launcher — accessible from any device on the network.

What's Next

The list keeps growing — and that's the point.

As more services come online — home automation, security cameras, a local AI assistant, a family photo album, a music library — each one gets a card in the launcher and a monitor in Uptime Kuma. The infrastructure grows, but the experience stays simple.

Eventually, I'd like to build a guest access system — a QR code menu with curated services for visitors. A pre-selected family photo album. A shared music library. Maybe a local AI assistant. Content that's safe to share, easy to access, and requires nothing more than scanning a code.

That's still an idea. But the infrastructure to support it is already here.

Quick Setup Guide

Get Uptime Kuma running in under 5 minutes.

Requirements: Docker installed on any always-on machine

1. Run the container

docker run -d \
  --name uptime-kuma \
  --restart unless-stopped \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  louislam/uptime-kuma:1

2. Open the dashboard

Go to http://[your-server-ip]:3001 and create your admin account.

3. Add a monitor

Click + Add New Monitor → Type: HTTP(s) → enter the URL of your service → set interval to 60 seconds → Save. If the service uses a self-signed certificate, enable Ignore TLS/SSL error.

4. Add a local DNS record (optional)

In Pi-hole → Local DNS Records → add monitor.home pointing to your server IP. Now anyone on the network can open it by name.

There are many detailed guides out there for setting up Uptime Kuma — this is just the version that worked for me. If you run into something specific or need help getting it running in your setup, drop a comment below.

Real World Update

The internet was working. The photo service wasn't.

This is exactly why I built this. The internet was up. The network was running. But Immich — the photo service — went down, and the monitor caught it immediately with a timestamp.

The reason: photos don't have a permanent server yet. Immich runs on my main workstation, and when I shut it down for the night, the service goes with it. That's a known limitation — one that will be resolved when the services move to a dedicated always-on machine. For now, the monitor makes that limitation visible instead of invisible.

As soon as the workstation came back online, Immich recovered automatically. The monitor logged the downtime, the duration, and the recovery — without me having to check anything manually.

Immich down at 22:43 — timeout of 48000ms. Back up at 22:44 when the workstation came online. The monitor is in Spanish because my wife and kids are native Spanish speakers — the system should work for everyone in the house.

That's the point of visibility. Not to prevent every failure — but to know exactly when it happened, how long it lasted, and when it recovered. Without asking me.

The Honest State

It works perfectly. It looks like a work in progress.

Right now, the A51 is literally thrown on my desk — and it looks exactly like that. Next to the Fire Tablet running MacroDeck, the setup works perfectly but doesn't look intentional. Because it isn't yet.

"If a cluttered desk is a sign of a cluttered mind, of what, then, is an empty desk a sign of?"

— Albert Einstein

I've read that quote many times. And I agree with it — I don't want an empty desk. I want one that looks organized and functional. One that doesn't make a visitor wonder what happened here.

The plan is to mount both the A51 and the Fire Tablet on the wall with permanent connections to the PC. Everything within reach, nothing in the way. The desk stays as the workspace — the wall becomes the command surface.

That's the next project. Unless my mind takes a different route first — which, if you've read this blog, you already know is a real possibility.

The Point

A well-monitored network is one that anyone can trust.

The internet might be fine. But the network has more work to do. And now, anyone in the house can see exactly how it's doing — without asking me.

Green means everything is working. That's all anyone needs to know.

What are you monitoring in your homelab? Drop it below.

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.

Read More

Networking · Infrastructure · Design

If It Only Works for Me, It Doesn't Work.

When I started this blog, it was simply an excuse to write.

A place to document ideas, experiments, and the occasional lesson learned after breaking something.

My homelab started the same way. It began as a technical challenge. I wanted more control over my own infrastructure. More privacy. More ownership over the services I used every day.

At first, everything was built for one person. Me. I knew every IP address. Every port. Every password. Every service had its own bookmark, its own shortcut, its own way of being accessed.

That worked — but only for me.

If every new application requires me to explain "go to this IP address, on this port" — I haven't built a useful system. I've built a puzzle.

The Realization

This infrastructure isn't just mine.

My wife uses it. My children use it. Guests will eventually use parts of it. And hopefully, years from now, they'll use services I haven't even deployed yet.

If every new application requires me to explain "go to this IP address, on this port, using this browser" — then I haven't built a useful system. I've built a puzzle.

Don't Make Me Think

The best systems don't ask users to remember.

One idea has been influencing my thinking for years: Don't Make Me Think. Steve Krug wrote about it in the context of web design, but I believe the principle applies almost everywhere. The best systems don't ask users to remember. They don't require explanations. They simply make the right thing obvious.

I realized my homelab deserved the same treatment.

The Solution

Names instead of numbers.

Instead of asking people to remember addresses like 192.168.2.114:8080 or 192.168.2.20:2283, I configured local DNS records in Pi-hole so every service now has a name:

Local DNS records

firewall.home
dns.home
nas.home
fotos.home
music.home
servicios.home

Pi-hole Local DNS — 6 registros activos, nombres en vez de IPs.

Nobody has to remember where a service lives. Only what it does.

The Launcher

A starting point for everyone in the house.

I built a launcher that lives on any device in the house — a simple page that shows only what's relevant to each person. Not because they need access to everything. Quite the opposite.

The goal isn't to expose every service. The goal is to make the available ones effortless to find. No documentation. No explanations. No technical knowledge required.

It runs on the NUC — the machine that's always on — served by a simple Nginx container. Any device on the network opens servicios.home:8888 and sees it immediately.

Servicios activos y planificados — cada uno con nombre, no con IP.

El launcher abierto en el Pixel — accesible desde cualquier dispositivo en la red.

The Philosophy

This may seem like a small change. Philosophically, it changes everything.

The infrastructure stops feeling like a collection of servers and starts feeling like a product. One designed for people instead of administrators.

Eventually I want to add much more — a local AI assistant, a family wiki, a digital library, internal tools, automation. The list keeps growing. But I've learned something important: every new service should become easier to discover, not harder. Adding functionality should never increase complexity.

External access is a completely different problem. That requires authentication, permissions, reverse proxies, VPNs, and much stricter security. I'll write about that separately.

Inside my network, my philosophy is simple: if someone has permission to use a service, they shouldn't have to think about how to reach it. They should simply open it.

The Point

A well-designed system disappears.

The funny thing is that this has very little to do with servers. It's really about design. A well-designed system disappears. People stop thinking about how to use it and simply use it.

That's the kind of infrastructure I want to build. Not one that impresses me. One that quietly works for everyone else.

If someone has permission to use a service, they shouldn't have to think about how to reach it. They should simply open it.

How do you handle service discovery in your homelab? Drop it below.

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.

Read More

Don't Make Me Think — Network Edition

Networking · Infrastructure · Don't Make Me Think

The Network Doesn't Need Me Anymore.

There's a moment every homelab builder eventually faces. You've spent weeks — maybe months — configuring, testing, debugging. The network works. The services are up. Everything is exactly where you want it.

And then you leave the house.

And someone calls you. "The internet is down." And you're twenty minutes away, and nothing you can say over the phone is going to make sense to the person standing in front of a blinking router.

That's the problem I set out to solve. Not just building a network that works — but building one that works without me.

A network that only you can operate isn't infrastructure. It's a dependency.

The Context

This isn't a home network. It's a small ecosystem.

The property covers roughly 1,200 m². A house, an office, storage, and several rented commercial spaces — two garages, a church, an upholstery shop, and an accounting office. Over 30 devices on the network at any given time. People working. Businesses operating. Payments being processed.

When the network goes down, it's not just an inconvenience. It's a disruption to everything running on top of it. Which means the pressure to fix it — fast — falls on whoever is physically present. Not always me.

That's why "it works when I'm here" was never an acceptable answer.

The Stack

Three machines. Each with a clear role and a label.

NUC, OPNsense, and the Bypass E900 — each labeled, each with a defined role.

The hardware

OPNsense on OptiPlex 780 SFF — the firewall and router. Everything passes through here. If this is down, there's no internet — period. Label: OPN.

NUC running Pi-hole + Cloudflare Tunnel — DNS filtering and the tunnel that exposes internal services. If this is down, DNS breaks and the tunnel goes offline. Label: NUC.

Linksys E900 — Bypass router — not normally on. This is the emergency fallback when everything else fails. It sits ready, cables pre-connected, labels on every port. Label: Bypass E900.

The Physical Design

The instructions are on the hardware itself.

This is where most homelab setups stop short. The configuration is solid, but the recovery process lives only in the builder's head. That's a single point of failure — and not a technical one.

My approach: if someone needs to connect a cable in an emergency, they shouldn't have to remember anything. The label tells them where to plug it. The color confirms it. There's nothing to look up.

Two cables. Two labels. No confusion.

Two cables live next to the E900, always. One labeled "ISP" — connects to the modem. One labeled "CASA" — connects to the house network. The E900 itself has matching labels directly on the ports, telling you exactly where each cable goes.

The label is on the port. The instruction is on the label. Nothing to remember.

That's the Don't Make Me Think principle applied to physical infrastructure. The system should be operable by someone who has never touched a router — because eventually, that person will need to operate it.

The Recovery Plan

Two versions. One for anyone. One for me.

The recovery plan exists in two forms. The first is for anyone in the house — no commands, no technical knowledge required. Five steps in a visual flowchart, ending with the bypass procedure if everything else fails. The second is for me — or eventually my son, who I'm training — with the full diagnostic sequence: OPNsense console, Pi-hole, Cloudflare tunnel, ISP check.

The flowchart below is the version anyone can follow.

Recovery flowchart — no commands version

The Real Test

It broke. And nobody called me.

The first real test wasn't planned. A power outage took down the NUC — not gracefully. The drive was mid-write when the power cut. SQLite flagged a corruption warning on next boot.

But the network came back on its own. OPNsense booted. The NUC booted. Pi-hole restarted inside Docker. Cloudflare Tunnel re-established the connection via systemd. Everything that needed to survive a hard shutdown did — because each service was configured to start automatically, not manually.

The only thing that required intervention was the SQLite warning — and that's on my list. Everything else recovered without a single command.

A resilient network isn't one that never fails. It's one that recovers on its own — or gives anyone in the house the tools to recover it.

The Point

Build it so it doesn't need you.

The goal was never to have the most advanced network. The goal was to have one that works — consistently, predictably, and without requiring me to be physically present to keep it running.

Labels on every cable. Labels on every port. Labels on every machine. A visual recovery plan anyone can follow. Services configured to restart themselves. A bypass router sitting ready for the worst case.

None of this is complicated. All of it matters.

If your network only works when you're there — it's not finished yet.

Questions about any part of this setup? Drop them below.

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.

Read More

Self-Hosted · Music · 28 Years of Library

I Took Back Control of What I Listen To.

I'm a man approaching forty. I've always loved music — deeply, obsessively. But growing up in a Latin country, the music I actually liked rarely made it to the radio. What I wanted to hear was whatever MTV decided to air that day, and not much else. No algorithm back then — just limited access and a lot of waiting.

That frustration pushed me toward technology earlier than most. If the system wouldn't give me what I wanted, I'd find another way.

I remember when the internet was still version 1.0. There weren't many pages. Search engines weren't common yet — you had to use Yahoo, AltaVista. And then, much later, Google appeared.

I remember the first days of YouTube. When YouTube was ugly and uncontrolled by any algorithm. When it was just people uploading things and other people watching them.

But music? Music was its own journey.

If I wanted to listen to something, my options were the radio, MTV, or a CD. I walked to school with a CD player in my pocket or backpack. Then came the burned CD and the MP3 CD player — and suddenly I started to feel something I hadn't felt before with music: Control.

I was choosing what I listened to. No DJ. No playlist curated by someone else. Just me and what I actually wanted to hear.

Before I had a CD burner, a friend gave me one CD. One. I listened to it so many times I grew to hate it. But it was my only option. When I finally started downloading my own music, something exploded. It wasn't just convenience. It was discovery.

I had two The Offspring CDs. If I wanted to switch between them, I had to physically get up, open the player, swap the disc, and find the track. Later, the home stereo had a 6-disc carousel — which felt like a revolution. Except changing from one disc to another took about 35 seconds. Per disc change. That was the cost of control.

That spark never went out.

A library built song by song since 1998. It's passed 10,000 songs. Every one of them was chosen deliberately.

Around that same time, I started building something without fully realizing it. A library. Song by song — from Napster, then iMesh, then LimeWire, eMule, eDonkey, online radio station rippers. Every tool that existed, I used. Not to collect everything — to collect what I liked. What I actually came back to.

That library has been growing since 1998. It's passed 10,000 songs. It's not a competition — it's a history. The evolution of what I've liked, from adolescence to now.

Then life got busy. Work. Responsibilities. No time to sit down and browse a library. And that's when the services arrived — first Google Play Music. Then Spotify. Then YouTube Music Premium.

And for a while, they were great. Convenient. Fast. Available everywhere.

But slowly, without me noticing, I stopped listening to what I wanted to hear. I'd pick the first song — the right song — and then the algorithm took over. Five songs in, I was somewhere else. Listening to what they decided I should listen to next.

I became a victim of the algorithm.

The Data

I exported my YouTube watch history and analyzed it. Out of 51,543 unique titles, about 28% were classifiable by category. Of those:

• 37.8% — Shorts and viral content
• 23.4% — Music
• 12.4% — Gaming
• 11.6% — Tutorials
• 6.1% — Comedy and memes

1 in 4 classified videos was music. But YouTube decided which music, when, and in what order. I wasn't choosing. I was being served.

That was enough. That's when I found Navidrome.

The Setup

Navidrome is the brain. Nobody sees it. Nobody touches it.

I installed Navidrome without being entirely sure what I was walking into. When it came up, it was just another web player. And from my perspective as a designer — the interface was ugly. That's an honest assessment, not a complaint. It works. It does exactly what it needs to do.

Before any of that could matter, I had to invest time cleaning and organizing my library. Fixing tags. Running everything through MusicBrainz Picard to repair metadata, match albums, correct artist names. That's not optional with a library that's been growing organically for 28 years — it's the foundation everything else sits on.

Navidrome running in Docker — silent, no interface, doing its job.

Once that was done, Navidrome became what it was supposed to be: a silent engine. It just works.

Then I started looking for the front end. First install: DSub. It works — but the interface carries the same visual weight as Navidrome. Functional. Forgettable. I kept reading.

Then I found Symfonium. Clean UI. Loaded my Navidrome server without complications. Suddenly I had everything — the functionality and freedom of Spotify or YouTube Music Premium, but running on my own hardware, with my own library, under my own control.

On Windows, Feishin does the same thing. Modern interface. Connects to Navidrome in seconds. No configuration friction.

Feishin on Windows — Stratovarius playing, Auto DJ active, 28 years of personal genres on screen.

The Ecosystem

I didn't install three apps. I built a personal music ecosystem.

Navidrome is the brain. Feishin is the face on the desktop. Symfonium is the face in your pocket. Together, they feel like one app — not three.

I create a playlist in Feishin for a specific mood or route. I open Symfonium, the playlist is already there. I mark it for permanent offline cache — and it downloads. The entire Navidrome library metadata lives in Symfonium even without a connection, meaning I can keep building and organizing playlists for later even when the server is unreachable. When it comes back online, everything syncs.

Likes. Favorites. Play counts. Statistics. All of it synchronized between Feishin and Symfonium with a single tap. Nothing complicated. Nothing manual.

Symfonium in action

Screen recording from the phone

External shot — the real experience

I don't have exact metrics. But I have my last 10 days of history. Music actively searched: three tracks. Algorithm deciding what I listen to: zero times.

Before, I opened YouTube to find something to listen to in the background. I'd pick the first song — and then the algorithm took over. Ads. Recommendations I didn't ask for. The quiet question the platform asks every few minutes: are you still there?

Now Feishin opens almost automatically on Windows. No ads. No unwanted playback. No passive consumption. Just music I chose, playing the way I want it to play. And when I leave the desk? I load the playlist into Symfonium and keep listening in the street.

It feels cleaner than it looks. And now I want to expand the library, activate WireGuard so it follows me anywhere — not just on the local network. It feels like a new kind of freedom.

A note on Auto DJ

Feishin has an Auto DJ mode that generates suggestions from your own library — and it works incredibly well. But only if your tags are clean. A file with youtube.com/watch?v=... as the album name tells the system nothing. The quality of your experience is directly proportional to the quality of your metadata.

The Honest Conclusion

I'm not going to tell you how to get music. That's not my place.

My library isn't vast by anyone's standards. 10,000 songs isn't a flex. But it's mine. Every song in it was chosen deliberately at some point in my life — whether at 16, or 25, or last month. It maps my moods with a precision that no recommendation engine has ever matched.

What I will tell you: when you have your library — whatever size it is — the step you cannot skip is MP3Tag. Cleaning and structuring your metadata is tedious. You do it once. And you enjoy it for life.

There's something quietly powerful about pressing play and knowing — with absolute certainty — that what comes next is something you actually chose. Not predicted. Not served. Chosen.

That feeling is worth more than any algorithm. And the next step? Activating WireGuard so my library follows me everywhere — not just on the local network, but anywhere I go.

Have a library sitting on a hard drive somewhere? There might be more there than you think. Drop your questions below.

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.

Read More

From Fear to Control: What Self-Hosting Gave Me

---

From Fear to Control: What Self-Hosting Gave Me

A DIFFERENT KIND OF POST

I'll confess something.

When I first started experimenting with self-hosted services, it wasn't because I wanted a cool homelab. It wasn't because I wanted to play with Docker, firewalls, VLANs, or enterprise-grade networking.

It started from something much simpler.

Need. And fear.

I had old equipment sitting around collecting dust. Hardware that technically still worked, but had no purpose anymore. At the same time, I felt an increasing need for something I couldn't fully get from consumer-grade solutions: control.

I wanted more security. I wanted more visibility. Most importantly, I wanted to better protect my children.

That was the real beginning.

Like many parents, I tried the usual tools first. I explored what Google Family Link offered. I tried the parental controls built into Microsoft Windows Family Safety. I tested schedules, device restrictions, app limits, and whatever features came bundled with routers and switches.

Some of it worked. Some of it helped. But eventually, it stopped being enough.

As more devices entered the house, the network became more complicated. More switches. More access points. More devices. More traffic. More risk.

And with complexity came a realization: my network wasn't organized. It was functional — but messy. And messy systems eventually become fragile systems.

Cybersecurity isn't only about protecting data. Sometimes it's about protecting the people who depend on you.

So I started building.

---

And honestly? I expected it to be much harder.

I thought self-hosting would be this overwhelming mountain of Linux commands, cryptic terminal outputs, and endless configuration nightmares.

Instead, I discovered something surprising. Most of the implementations were actually very straightforward. Not easy — but straightforward.

You follow the documentation. You run the commands. You configure things carefully. Step by step.

The process wasn't usually difficult. It was tedious. Sometimes exhausting. I remember moments where something as simple as configuring the firewall meant physically switching monitors back and forth just to access the console.

Not glamorous. Not fun. Just patience.

But slowly, piece by piece, everything started coming together.

---

Then came the fear.

Not fear of learning. Fear of failure.

Because in a self-hosted environment, you quickly learn something important: some services are forgiving. Others are not.

If a media server goes down, life continues. If the firewall goes down? Everything goes down. If DNS fails? The whole network can feel dead in minutes.

That became my biggest fear. Not because I doubted my ability. But because I understood the responsibility.

Over thirty devices depend on this network. Family devices. Business devices. Workstations. Access points. Store systems. Every rule, every route, every configuration matters.

That fear changed how I built everything. I stopped thinking only about functionality. I started thinking about resilience. Contingency plans. Fallback routes. Backup hardware. Redundancy.

That mindset pushed me to invest in simple but essential equipment — not expensive, just practical. The kind of gear that doesn't look exciting in photos, but saves you when things go wrong.

And things do go wrong.

I've stumbled. Many times. Failed deployments. Broken configs. Services refusing to start. Routing issues. Permission issues. Unexpected incompatibilities. Moments where I sat there thinking: "Why isn't this working?"

Sometimes you learn because things succeed. Sometimes you learn because things break. Usually, both.

---

But over time, something changed. The infrastructure became stable. Really stable.

And once everything is properly documented and correctly configured… it just works.

And that feeling is difficult to explain unless you've built something yourself.

People don't notice. Nobody walks into the house and says "Wow, the DNS resolution is fantastic today." Nobody compliments proper VLAN segmentation. Nobody applauds latency improvements.

They just use the internet. The TVs work. The phones connect. The PCs sync. The store system runs. Everything feels invisible.

And strangely… that invisibility became one of my greatest satisfactions. Because silence means stability. Silence means everything is working. Silence means the people I care about are protected and uninterrupted.

And that brings me peace. A peace I didn't expect when I started.

---

I felt that peace even more on June 12th.

At 7:00 AM, the network went down.

A few months ago, that would have triggered panic.

This time? I executed the contingency plan. Bypass. Recovery. Stabilize critical systems. Troubleshoot. And it worked.

The stress was real. But something had changed inside me. I wasn't panicking. I was responding.

The person who once feared touching DNS… had become the person solving the outage. That felt like growth. Real growth.

---

Today, I run seven self-hosted services. Eight, if I count Moonlight.

And the funny thing is… the infrastructure can handle more.

That's the trap of self-hosting. You start because of necessity. Then one day you realize: "I could add one more service." Then another. Then another.

Now, whenever I want something new, I spin up a container, configure it, integrate it into the network, and let the infrastructure do what it was designed to do. Support growth. Support experimentation. Support me.

And maybe that's the part that moves me most. This was never only about technology. It was about ownership. Responsibility. Trust. Building something with my own hands. Creating a system that protects my family and supports the business. Creating order where there used to be chaos.

---

Self-hosting isn't for everyone. It requires patience. Curiosity. Technical knowledge. And the willingness to fail repeatedly.

You need to accept that some things won't work just because you want them to. You will stumble. You will make mistakes. You will break things. You will lose sleep.

Sometimes, to avoid disrupting thirty devices, I wake up at hours when everyone is asleep just to make infrastructure changes while usage is near zero. That's part of the sacrifice. And I accept it.

Because I know what it gives me in return.

Peace. Control. Confidence.

And maybe something else. Pride.

Not loud pride. Not the kind you post for validation. A quiet kind. The kind you feel when you sit in a room where everything is working, everyone is comfortable, and nobody notices the invisible systems around them.

Because you built those systems. And they work.

That feeling is hard to put into words.

But if I had to summarize what self-hosting gave me, it would be this: I started with fear. And somewhere along the way… fear turned into confidence. Chaos turned into structure. And necessity turned into something I genuinely love.

---

Questions about the setup? Drop them below. I built this without a guide — figured it out piece by piece over time. Happy to help you figure it out.

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.

Read More

When One Problem Turns Into Two

The calm before...

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product mentioned here is something I personally own and use.

I'd enjoyed almost a month of absolute peace. My OPNsense firewall was working flawlessly, without a single outage. It was performing so well that, to be honest, I'd fallen into that dangerous state of complacency where you don't even check the logs or the connection. You simply assume everything will be fine forever.

Until this morning.

At 7:01 AM, I sat down at my computer ready to start the workday and was met with the worst possible screen: No connection.

At first, nothing made sense. The infrastructure had been stable for weeks. The OptiPlex running OPNsense was powered on. The NUC was powered on. Physical links? At first glance, all good. Everything looked normal. But the network clearly wasn't.

I couldn't reach the OPNsense dashboard. Nothing.

The problem...

Since the business relies heavily on network connectivity, I couldn't allow extended downtime, so I started troubleshooting fast.

First step: connect directly to the ISP, bypassing everything. That worked — I had internet. So the ISP itself was fine. The problem was somewhere in my own infrastructure.

Then came the first rabbit hole.

My main PC, connected to the ISP directly over Wi-Fi, had no internet either — connected, but nothing loading. I dug into it and found the cause: DNS was still pointing to Pi-hole, on a network segment that didn't exist in this configuration. Switched everything to automatic DHCP and DNS, and that PC came back online.

Good. One thing fixed. But the real problem — OPNsense unreachable — was still there.

So I activated the bypass plan: an old Linksys E900, pre-configured to take over DHCP for the whole office in exactly this kind of scenario. I connected it between the ISP and the internal network.

Except it had the same DNS problem. Configured to hand out Pi-hole's address as DNS to every client. Same fix: switched it to public DNS. Bypass online. Core systems back up.

The proof

And here's the part that actually matters most to me: it worked. Not "worked in theory" — worked under real pressure, on a real morning, with a real firewall down. I'd built this bypass months ago for exactly this scenario, and today was the first time it actually had to do its job. It did. That's not a small thing. That's the difference between a stressful morning and a lost day.

Relief — for about ten minutes.

The partial failure

Because the network was still only partially healthy.

Maria's PC, on the second switch, still had no connection through the network — though it kept working because it was also connected directly to the ISP over Wi-Fi as a fallback.

The access points weren't responding either.

That uncertainty was stressful. When everything is down, the problem is clear. When half the network works and half doesn't, every assumption becomes questionable.

And the whole time, one thought kept nagging at me: what happens if a customer walks in right now? Odoo runs on this network, and without it, the store can't operate the way it needs to.

Luck was on my side, oddly. Nobody walked in until 11am. That gave me a window to work without the pressure of a customer standing there — but it was also its own kind of pressure, a clock running in the background the whole time. Peace and pressure, at the same time.

I checked Pi-hole on the NUC directly, worried it had crashed and was the common thread. It was fine — active, healthy, full history of queries. Not the culprit. Crossed that off the list.

The fix

With the bypass holding the network up, I had a window — and the OptiPlex was already down for diagnosis anyway. So I decided to act on something I'd suspected for a while.

The OptiPlex's LAN interface was running on a USB Ethernet adapter. This wasn't the first time a USB NIC had given me trouble — when I first set up OPNsense on the NUC, before moving it to the OptiPlex, a USB NIC was the exact thing that failed on me back then too. Apparently that's a known weak point for USB network adapters under sustained load. Fine for temporary setups. Not for a firewall running 24/7.

I had a dual-port Intel PCIe NIC sitting ready. Took the OptiPlex apart, installed it, reassigned the interfaces from the console — WAN stayed on the onboard port, LAN and a future OPT/DMZ port moved to the new card. Brought OPNsense back up.

LAN came back clean. WAN picked up a real IP from the ISP again, not the bypass's.

I felt relief. Found the root cause. Or so I thought.

The second failure

Because the access points were still offline. Maria's PC still couldn't reach anything through the LAN.

That made no sense. I'd just fixed the actual hardware problem on the firewall. So why was half the network still acting like nothing happened?

That's when the frustration really kicked in.

Back to troubleshooting. DHCP leases. IP configurations. Pings that came back as "destination unreachable" from addresses that shouldn't exist. Manual IPs versus automatic ones. Everything seemed to check out individually, and none of it explained the access points being completely dark.

Mental fatigue sets in fast on mornings like this. Your brain starts looking for a complicated answer, because surely something this stubborn has to be complicated.

The resolution

I stepped back, took a breath, and decided to forget the theories. Check every physical connection manually. One cable at a time.

That's when I found it.

While moving the OptiPlex earlier to install the new NIC, I had accidentally knocked loose the UTP cable connecting the first switch to the second switch — the one feeding the access points, the cameras, and Maria's desk.

I had unintentionally created a second problem while fixing the first one.

I just stared at the cable. Then I laughed. Because that's IT sometimes. You fix one issue, and in the process of fixing it, you cause another.

Reconnected the cable. Instantly, everything came back. Access points online. Maria's PC online. Full network restored.

After a long, stressful morning, the network was finally healthy again.

What I Learned Today

1. Bypass plans are essential — and proving they work matters

Having a physical bypass kept the business running while I troubleshot the real problem. Without it, the entire office would have gone down for hours.

But more than that: this was the first time that bypass had to perform for real, outside of a test. It worked. There's a particular kind of relief in seeing a contingency plan you built months ago actually do its job under pressure — it's no longer theoretical, it's proven.

2. Avoid USB NICs for critical systems

This is the second time a USB Ethernet adapter has failed me on a firewall — once on the NUC, now on the OptiPlex. Fine for temporary use. Not for production infrastructure. Dedicated PCIe NICs, especially Intel-based ones, are the right call.

3. Troubleshooting can create new problems

This one stung. Not every issue you see belongs to the original failure. Sometimes, during diagnosis — or while physically moving hardware to fix one thing — you unintentionally introduce a second problem. That can completely distort your understanding of what's actually happening.

Final thought

Today's outage taught me something simple:

The first problem was hardware.

The second problem was a cable, knocked loose by my own hands while fixing the first.

Both mattered. Both taught me something.

Read More

Google Photos Was Free. Until It Wasn't. Here's My Setup Now.

Read More