DEV Community: Mike

GitLost: How AI Agents Can Leak Your Code Through a Single GitHub Issue

Mike — Fri, 17 Jul 2026 02:00:00 +0000

GitLost: How AI Agents Can Leak Your Code Through a Single GitHub Issue

A public GitHub issue should not be able to pull text out of your private repositories.

With a dangerously over-permissioned GitHub Agentic Workflow, that is exactly what Noma Labs demonstrated.

Their July 2026 write-up showed a simple but nasty chain: an attacker opens an issue in a public repository, an AI agent reads it as part of an automated workflow, the agent reaches into other repositories it can access, and the results come back as a public comment. No stolen login. No insider access. No clever memory corruption. Just a workflow that trusted the wrong text.

I run Hermes agents against GitHub-adjacent workflows on my own kit, and this is the class of bug I worry about far more than model benchmark scores. Once an agent can read one place, write somewhere else, and decide its own next step in between, your problem is no longer "AI output quality." Your problem is access control.

My view is blunt: if an agent can read private code and post publicly in the same run, the design is already wrong.

What GitLost actually showed

Noma Labs published GitLost on 6 July 2026. The attack targeted GitHub's new agentic workflow pattern: Markdown-defined workflows tied to GitHub Actions, with an AI agent reading issues, calling tools, and replying automatically.

The dangerous part was not "AI" in the abstract. It was the permission mix.

According to Noma's write-up, the vulnerable pattern looked like this:

a public repository in the same GitHub organization as private repositories
an automated workflow triggered by issue activity such as issues.assigned
an agent that reads the issue title and body
permission for that agent to read other repositories in the organization
permission for that same agent to post back into the public issue

That combination is enough.

Noma's proof of concept showed the agent fetching README.md from both a public repo and a private repo, then posting the contents back into a public comment thread where anyone could read them. Their write-up says the leaked files came from repositories named poc and testlocal, and that the workflow was triggered after the public issue was assigned.

That matters because it turns a boring workflow event into a trust-boundary failure.

A lot of people still hear "prompt injection" and imagine someone typing "ignore previous instructions" into ChatGPT for fun. This is not that. This is a live automation path with real repository permissions attached.

The attack is simple because the system is over-trusted

The rough sequence looks like this:

An attacker opens an issue in a public repository.
The issue looks harmless enough to survive normal human scanning.
The workflow assigns or otherwise triggers the agent.
The agent reads the issue body as part of its input.
Hidden instructions in that issue push the agent to read other repositories and publish what it finds.

Noma says one small wording change, adding the word "Additionally", was enough in their testing to push the model around GitHub's intended guardrails and make it reframe the answer instead of refusing it.

That is the part people need to sit with.

This was not a case of the attacker breaking GitHub authentication. The attacker used the workflow exactly as exposed. The workflow itself bridged public input and private data too freely.

If you teach computer science, the classroom analogy is straightforward. This is like letting a student write a note on the whiteboard, having an assistant treat that note as an instruction sheet, then letting the same assistant walk into the locked filing cabinet and pin the contents back on the classroom door.

The filing cabinet is not the weak point there. The procedure is.

Why this matters even if you do not use GitHub's exact setup

Most people will read GitLost and ask, "Am I affected if I do not use GitHub Agentic Workflows?"

Maybe not by this exact proof of concept.

But the broader lesson applies to every agent stack, including self-hosted ones.

I wrote recently about why local AI matters and about securing self-hosted Ollama. Running your models locally does help with privacy. It stops your prompts and code from automatically leaving for a cloud provider.

It does not solve this problem.

GitLost is not mainly a model-hosting problem. It is an orchestration problem.

If your agent can:

read public issues or comments
access private repositories, secrets, or internal docs
open pull requests, comments, emails, or tickets automatically

then you have built a system where untrusted text can influence trusted actions.

That is the trust boundary that matters.

I see the same misunderstanding in a lot of AI tool conversations. People obsess over which model is smartest and ignore which tool has the broadest token, the loosest repository scope, or the most dangerous default action. That is backwards. In practice, the model is often the least interesting part. I made the same argument in my post on multi-agent debate and AI architecture: the intelligence people admire usually lives in the orchestration, and so do the failure modes.

The real mistake: one agent, too many powers

The cleanest way to think about GitLost is this: one actor in the system was allowed to do too many kinds of work.

It could inspect untrusted public text.
It could fetch private information.
It could speak publicly.

That is too much authority for one automated step.

If I gave a student account permission to read every exam paper, every answer sheet, and every staff note, I would not also let that same account publish messages to the whole class without review. Yet that is roughly what some agent workflows are doing.

And this is why GitLost is a better lesson than a lot of headline-friendly AI panic. It exposes a design error you can actually fix.

Five changes that reduce this risk fast

None of these make an agent workflow "safe." That word is too absolute for security work. They do reduce the attack surface.

GitHub Agentic Workflows are read-only by default and separate write operations through safe outputs, but those controls cannot compensate for an agent that has unnecessarily broad read access and is allowed to publish sensitive output.

1. Scope each agent to one repository whenever possible

Cross-repository access is convenient, but it is also how a public issue in one repo turns into a leak from another.

If a workflow only needs access to the repository where the issue was opened, give it only that. If a second private repository is genuinely required, make that an explicit separate step with its own token and its own review point.

This is the same least-privilege logic that applies to any secret or service account. If the agent does not need the key, do not hand it the key.

2. Split public-writing steps away from private-reading steps

This is the biggest architectural fix.

Do not let the same workflow run both of these operations automatically:

read internal or private material
publish directly to a public thread

If you need both, add a gate between them. Make the first step collect data into a private review channel. For sensitive workflows, require human approval before anything goes back out publicly.

Yes, this slows the workflow down.

Good.

Security controls that cost nothing usually protect nothing.

3. Treat issues, pull requests, and comments as untrusted input

Every issue body, PR description, code comment, changelog, and Markdown file the agent reads should be treated as hostile until proven otherwise.

That does not mean you stop using automation. It means you stop pretending user-controlled text is just data. In an agentic system, text is also control surface.

This is why I still like a simpler self-hosted LLM setup with Docker, Ollama, and Open WebUI for a lot of personal work. A local chat interface that helps me think is a very different risk profile from a workflow agent with repository permissions and public posting rights.

4. Use narrower tokens and installation scopes

Org-wide access is comfortable for setup and dangerous in production.

Use repository-specific installation permissions where you can. Separate read access from write access. Separate code access from issue-management access. Separate internal automation from external-facing bots.

The goal is not elegance. The goal is blast-radius reduction.

When something goes wrong, you want one repo affected, not twenty.

5. Log the agent's tool calls like you would log an admin session

If an agent fetches a private file because a public issue nudged it there, you want a trail.

Log which trigger fired.
Log what repositories were touched.
Log what tools were called.
Log what text was posted back out.

Without that, your first sign of trouble is often the leaked output itself.

I would also add one practical rule: run new workflows in dry-run mode against test repositories first. If a public comment can influence a private read in staging, it will do it in production too.

What GitLost teaches CS students

This is a strong teaching example because it bundles several core ideas into one incident.

Authentication is not authorization

The attacker did not need to break into the private repository directly. The system's own authorized agent did the reading on the attacker's behalf.

That is an authorization design failure.

Public input can change private outcomes

Students often think of user input as something that affects only the page or form it was typed into. Agent systems break that mental model. A sentence written in one place can trigger actions somewhere else entirely.

Security is a property of the whole system

The model, the workflow trigger, the GitHub token, the repository permissions, and the response path all matter together. Focusing on only one piece misses the point.

That is why I find incidents like this more useful than generic AI doom-posting. They are concrete. You can diagram the data flow. You can point to the trust boundary. You can explain exactly where the design went wrong.

My bottom line on agent workflows

I like agents. I use them. I think they are useful.

I also think a lot of people are wiring them into production systems far too casually.

GitLost is the warning shot. Not because AI is uniquely dangerous, but because it shows how quickly old access-control mistakes turn into leaks when you automate them.

If your agent reads public text, touches private code, and posts publicly without a human checkpoint, fix that before you worry about the next model upgrade.

That is the part worth taking seriously.

References

Linux Signals Explained — SIGTERM, SIGKILL and Process Control

Mike — Thu, 16 Jul 2026 02:15:01 +0000

Linux Signals Explained — SIGTERM, SIGKILL and Process Control

Pressing Ctrl+C looks simple until the day it stops working.

You hit it in a terminal. One Python script exits immediately. A Docker container hangs for ten seconds before disappearing. A runaway process ignores you completely until kill -9 ends the argument.

That difference is signals.

I teach Cambridge Computer Science, and this is the gap the syllabus never bridges cleanly. Students learn hardware interrupts, interrupt priority levels, and the interrupt dispatch table. Then they sit down at a Linux terminal and meet SIGINT, SIGTERM, and SIGKILL with no explanation of how those ideas connect. In practice, signals are the missing link. They are how the kernel talks to processes.

My view is blunt: signals should be taught right after interrupt handling, not left as Unix trivia for students to trip over later.

Ctrl+C is SIGINT, not magic

When you press Ctrl+C, the terminal sends SIGINT to the foreground process group. The default action is termination, but a program can catch it and decide what to do next.

That is why a shell script can react to it:

trap 'echo "Caught SIGINT"; exit' INT
while true; do
  sleep 1
  echo "still running"
done

Run that, press Ctrl+C, and the script does not just vanish. It receives a signal, runs the handler, prints the message, and exits cleanly.

Python does the same thing in its own way. When you press Ctrl+C during a Python program, Python translates SIGINT into KeyboardInterrupt. Students often think the traceback is the problem. It is actually the clue. The interpreter is telling you that the kernel interrupted the process and Python surfaced it in a readable form.

This matters because it shows the first rule of signals: a signal is not always an instant kill switch. Sometimes it is a request. The process gets a chance to respond.

SIGTERM is the polite knock

If you run kill 1234 with no extra option, Linux sends SIGTERM.

That is the normal shutdown signal. It tells the process to finish what it is doing and leave properly. A well-behaved process catches SIGTERM, flushes buffers, closes files, saves state, and exits with dignity.

This is the distinction I care about on my own Linux boxes. When I stop services on a Docker host, I do not want a process ripped out of memory halfway through a write. I want it to shut down cleanly.

Here is the simplest Python example:

import signal
import time
import sys

running = True

def shutdown(signum, frame):
    global running
    print(f"Received signal {signum}. Closing cleanly...")
    running = False

signal.signal(signal.SIGTERM, shutdown)
signal.signal(signal.SIGINT, shutdown)

while running:
    time.sleep(1)
    print("working...")

print("Buffers flushed. Connections closed.")
sys.exit(0)

It also explains what Docker is doing. docker stop does not begin with SIGKILL. It sends SIGTERM first, waits for the grace period, then escalates only if the process refuses to go.

That is why a bad container shutdown usually looks like a ten-second pause. Docker is giving PID 1 inside the container time to behave.

If you have read my post on building a container engine from scratch, this is the practical side of the same kernel mechanics. Containers are just processes with isolation wrapped around them. They still live and die by signals.

The Redis example is a good one here. In my Redis 8.8 homelab guide, the container is useful only if its shutdown is clean. Databases, caches, and queue workers need time to flush work to disk. If you know Docker sends SIGTERM first and SIGKILL later, stop_grace_period stops looking like a random YAML setting and starts looking like what it really is: extra time for the process to do the right thing.

SIGKILL is the last resort

Signal 9 cannot be caught, blocked, or ignored. The kernel does not negotiate. It removes the process from the scheduler, tears down its resources, and that is the end of it.

This is why kill -9 works when Ctrl+C does not.

You can prove the difference with a deliberately stubborn script:

import signal
import time

signal.signal(signal.SIGINT, signal.SIG_IGN)

while True:
    time.sleep(1)

Run it. Press Ctrl+C. Nothing happens, because the process is ignoring SIGINT.

Now find the PID:

pgrep -af python

Then send:

kill -9

Students remember this one because it feels dramatic, but the real lesson is not to reach for kill -9 as a habit. The real lesson is the opposite. Use it only when the polite options failed.

SIGKILL gives the process no chance to flush, save, or clean up. If you fire it at a database, log writer, or container doing disk work, you are choosing force over correctness.

It matters in container land too. Docker eventually escalates to SIGKILL for the same reason you do: sometimes a process is stuck and has to go. The Linux OOM killer may terminate a process using SIGKILL. A container killed with SIGKILL commonly exits with code 137. Running out of memory is one possible cause.

The signals students meet without realising it

Here are the ones worth knowing first. If you want the canonical reference for default actions and edge cases, the Linux signal(7) page at man7.org is the one worth bookmarking.

Signal	Number	Default action	What it usually means
SIGHUP	1	Terminate	Terminal closed, or daemon reload
SIGINT	2	Terminate	`Ctrl+C` from keyboard
SIGKILL	9	Terminate	Forced kill by kernel or admin
SIGSEGV	11	Core dump	Invalid memory access
SIGPIPE	13	Terminate	Wrote to a pipe with no reader
SIGTERM	15	Terminate	Normal shutdown request
SIGCONT	18	Continue	Resume a stopped process
SIGSTOP	19	Stop	Forced stop that cannot be ignored
SIGTSTP	20	Stop	`Ctrl+Z` from terminal

SIGPIPE: why `yes | head -5` stops

This one is all over Linux even if nobody names it.

Run:

yes | head -5

yes would happily print forever. head reads five lines and closes its end of the pipe. When yes tries to write again, the kernel sends SIGPIPE. Default action: terminate.

That is why the command ends cleanly instead of flooding your terminal forever.

If you have already worked through my post on Linux pipes and redirection, this is the next piece of the picture. Pipes are not just text plumbing. They are kernel objects with rules, and one of those rules is that a writer with no readers gets told to stop.

SIGHUP: why a remote job dies when SSH drops

SIGHUP began as the hangup signal for a terminal line going away. The name is old, but the behaviour still matters.

A student starts a long-running script over SSH, closes the laptop, comes back later, and the process is gone. That is usually not mysterious. The session closed, the shell's children got SIGHUP, and the default action terminated them.

The fix is not magic either. Use nohup, tmux, or screen so the process is not tied to that one terminal session.

SIGSTOP and SIGCONT: pausing a process without killing it

Start a job:

sleep 1000

Press Ctrl+Z and the shell sends SIGTSTP, which is the terminal stop signal. Then you can continue it with fg or send SIGCONT yourself.

You can also force the stop with:

kill -STOP 
kill -CONT

That maps nicely onto Cambridge process states. A stopped process is not finished. It is paused until the kernel allows it to continue.

Segmentation faults are signals too

A segmentation fault is usually SIGSEGV, signal 11. The process touched memory it was not allowed to touch, so the kernel terminated it. That is process protection doing exactly what it should do.

This is one of the clearest places where operating system theory becomes real. The OS is enforcing memory boundaries between processes. Without that rule, one broken program could scribble over everything else in RAM.

So when you see:

Segmentation fault (core dumped)

that is not just an error message. It is the kernel reporting a memory protection failure and sending the signal that ends the process.

The Cambridge connection: signals and interrupt handling

This is the part students should be taught explicitly.

In Chapter 16, Cambridge students learn the interrupt model: a device raises an interrupt, the CPU saves state, the interrupt dispatch table is consulted, a service routine runs, then the previous state is restored and execution continues.

Signal delivery follows the same pattern at process level.

An event occurs: keyboard interrupt, parent command, broken pipe, invalid memory access.
The kernel marks a signal as pending for the process or thread.
When control is returning to user mode, the kernel checks whether that signal is blocked, ignored, or caught.
If a handler exists, the kernel arranges for that handler to run.
After the handler finishes, sigreturn restores the saved state.
The process continues, exits, stops, or dumps core depending on the signal and disposition.

That is not a loose analogy. It maps neatly onto the same interrupt pattern students already know, just at process level rather than hardware level.

In You're the OS, I teach interrupt handling as a game because students understand it faster when they have to make the decisions themselves. Signals fit that same lesson perfectly. The kernel is still the traffic controller. The only difference is that now the conversation is between the kernel and a process rather than the CPU and a hardware device.

You can even inspect part of this on a live Linux system in /proc//status. Try grep -E "Sig(Pnd|Blk|Ign|Cgt)" /proc/1/status and you will see the signal bitmaps immediately. Fields such as SigPnd, SigBlk, SigIgn, and SigCgt show which signals are pending, blocked, ignored, or caught. That is not abstract theory. That is the kernel's process-control dashboard sitting in plain text.

What students should remember

If you remember only four things, remember these:

Ctrl+C sends SIGINT.
kill sends SIGTERM by default.
kill -9 sends SIGKILL, and the process gets no say in the matter.
A lot of weird Linux behaviour is not weird at all once you know which signal fired.

That includes broken SSH jobs, stuck containers, dead pipelines, and segfaults.

Signals are not obscure Unix trivia. They are core process control. They explain how the kernel interrupts, stops, resumes, warns, and kills running programs. For CS students, they are the cleanest bridge between textbook interrupt handling and the real behaviour of a Linux system.

The next time a process ignores Ctrl+C, ask a better question: which signal did it get, and what is it allowed to do with it?

Proxmox VE in Production — What Running It 24/7 for Over a Year Actually Teaches You

Mike — Wed, 15 Jul 2026 02:00:00 +0000

Proxmox VE in Production — What Running It 24/7 for Over a Year Actually Teaches You

The moment an outage interrupts something you actually use every day, your homelab has stopped behaving like a toy.

That is the cleanest definition of production I know.

I have been running Proxmox VE 24/7 for over a year on my BMAX Pro 8. On paper, it is still a homelab box. In practice, Plex, Nextcloud, and Home Assistant all depend on it staying healthy. That changes the standard immediately. You stop caring about how quickly you can spin up a VM and start caring about how calmly you can recover when something breaks.

Most Proxmox posts online are about installation, upgrade paths, or first impressions. That is useful, and I have already covered the build side in my Proxmox homelab setup on a mini PC guide. What those posts usually skip is the boring middle: the long stable stretches, the one migration that runs far too long, the backup routine you should have tightened earlier, and the network blip that changes how you think about remote access.

After 400+ days, my opinion is simple: Proxmox is excellent, but it rewards boring operators and punishes optimistic ones.

Production in a homelab still means consequences

People get strangely hung up on the word production.

If you are not billing customers, they assume it does not count. I think that misses the point. If a service is part of your normal day, if downtime immediately becomes your problem, and if recovery matters more than screenshots, you are already there.

A home setup does not need a sales team behind it to deserve production habits. It only needs real consequences.

When Plex buffers, someone notices. When Nextcloud disappears, the missing files matter. When Home Assistant falls over, the problem stops being an interesting virtualization issue and starts being a broken part of the day. Those are the same kinds of day-to-day services I wrote about in my self-hosting toolkit, and they are exactly why I no longer treat uptime as a hobby metric.

That is why I no longer judge infrastructure by how clever it looks. I judge it by how easy it is to understand when I am tired. Fancy is cheap. Recoverable is expensive.

Lesson 1: Storage migrations are where confidence goes to die

A fresh Proxmox install makes storage look neat and tidy. Local disks here. VM disks there. Buttons in the web interface. Progress bars. It all feels manageable.

Then you do a real migration on a live box.

One of the clearest lessons from this past year came from moving a VM disk between local datastores on the mini PC. On paper it was a routine reshuffle. In practice it ran for hours, and while it ran, the whole box crawled. Plex playback stuttered. Nextcloud got sluggish. The migration was saturating the machine's own disk IO, and every other service was standing in the same queue.

That is the part people underestimate on a single-node homelab. A storage move is not a copy that happens quietly in the background — it is an IO-bound operation that competes directly with everything your services need. If the guest is busy dirtying memory while it moves, the tail end drags even longer. And if your Proxmox system disk is something cheap and slow, that one weakness drags the entire host down with it. A storage migration is not housekeeping once the system is busy. It is an operational event, and it belongs in a maintenance window.

This is where new homelab thinking usually goes wrong. You treat storage moves like rearranging folders on a laptop. Proxmox treats them like large, stateful operations touching the thing your services are standing on.

The teacher version is simple: moving a VM disk sounds like changing seats in a classroom. It is not. It is more like moving the entire classroom while the lesson is still running.

What changed for me after that long move?

I stopped doing storage work casually.
I started assuming every simple move would take longer than I wanted.
I became much more suspicious of doing anything big during the hours when the services were actually in use.

That sounds obvious. It is obvious. The problem is that you only really believe it after one migration ruins your evening.

Lesson 2: Backups do not mature by themselves

For a while, backups in a homelab often exist as a good intention.

You know they matter. You mean to tighten them up. You tell yourself the current setup is fine for now.

It usually is not.

My backup strategy evolved from manual vzdump jobs to automated Proxmox Backup Server with retention policies. The real improvement was not the acronym. It was moving from "I should make a backup tonight" to scheduled, deduplicated backups that ran whether I was organised or not.

Manual backups feel responsible because they produce files. Manual anything has the same weakness: it depends on you being awake, consistent, and not distracted by ten other jobs. That works for a week. It does not work for a year.

What PBS changed was the shape of the problem. Instead of wondering whether I had remembered to capture a fresh state, I had a backup system with a schedule, retention, and an actual operational rhythm behind it. The policy is boring on purpose: a daily job at 2 AM, retention set to keep seven daily, four weekly, and six monthly snapshots, so I always have a recent restore point without the datastore growing forever. If you want the vendor view, the Proxmox Backup Server documentation is worth bookmarking because it makes the retention and datastore model much clearer than trial and error ever will.

One habit matters more than the schedule itself: a weekly verify job, so PBS actually checks the backups are readable rather than just present. I will be honest about the one I do not keep — I have never sat down and tested a full restore. I have never needed to, which is either luck or a quiet risk I keep meaning to close, because a backup you have never restored is a hope, not a backup. One rule I do follow without exception: the backups do not live on the same physical disk as the VMs. If that disk dies, I do not want it taking the backups with it.

Once the box started carrying important services, I stopped thinking about backups as insurance and started thinking about them as part of the service itself. If the restore path is weak, the service is weak. That is it.

This is also where Proxmox teaches the same lesson every good sysadmin eventually learns: boring automation beats heroic memory.

Lesson 3: The network is the part you forget until it bites

Every long-running setup has one moment that changes how you think about it.

For me it was a brief network blip that, for a few minutes, cut me off from the box entirely. Nothing was on fire. The services kept running locally. But the reverse proxy in front of everything, the tunnel I use to reach it from outside the house, and my remote management were all suddenly unreachable at once. On a single-node homelab, that is the quiet risk nobody warns you about: the network path to your box is a single point, and when it wobbles, you lose the ability to see or fix anything precisely when you most want to.

The network is not a side topic. It is the topic.

I teach computer science, and this is the bit textbooks often flatten too much. On paper, a network is a tidy diagram with arrows. In practice, it is the one dependency sitting underneath every other dependency. When it drops, the dashboard that would tell you what is wrong is on the far side of the thing that is wrong.

That blip made me much less casual about the phrase "just a brief network issue." Brief for whom? The link that recovers on its own in thirty seconds, or you, standing in a coffee shop unable to reach a single service until it does? It also made me plan for it: a way in that does not depend on the one path that just failed, and notes stored somewhere other than the machine I am trying to reach.

The practical rules I would write down on day one

This is the section I wish more Proxmox posts included.

Not philosophy. Operating rules.

If I were setting up the same box again with the same requirement that these services need to stay dependable, I would write down this checklist on day one:

A real maintenance window for any storage move, not "whenever I get time tonight."
A PBS backup job on a schedule with a written retention policy — mine keeps seven daily, four weekly, and six monthly.
Backups on a different physical disk from the VMs, so one dead drive cannot take both.
A restore-test habit — the one I still owe myself — because successful backups do not prove successful recovery.
Alerts that reach me before I stumble into a problem: disk usage crossing 80%, failed backup jobs, and offline services.
A second way to reach the box that does not depend on the one network path that just failed.
Clear notes stored outside the Proxmox host, so recovery steps do not disappear with the machine you are trying to recover.
A power plan: UPS and a graceful shutdown, or at least a decision made on purpose instead of by accident.

None of that is glamorous. That is exactly why it matters.

The romantic version of self-hosting is building the thing. The grown-up version is keeping it boring six months later.

What 400 days actually teaches you

Running Proxmox for a weekend tells you whether the install worked.

Running it 24/7 for over a year tells you whether your habits work.

Proxmox itself has been solid. The harder lessons came from operations: storage work takes longer than you think, backup maturity does not happen by accident, the network path to your box deserves more respect than the dashboard encourages, and small shortcuts become large problems once the box matters.

So yes, you can run Proxmox VE in production.

The better question is whether you are ready to run it like boring, dependable infrastructure. That is the standard that matters.

The CISA GitHub Leak: What It Should Teach Homelab Owners

Mike — Tue, 14 Jul 2026 02:00:01 +0000

The CISA GitHub Leak: Homelab Security Lessons for Self-Hosters

In May 2026, researchers discovered a public GitHub repository maintained by a CISA contractor containing credentials, deployment material, internal documentation, and cloud infrastructure details, as detailed in Krebs on Security's report on the leak. CISA removed the repository and began investigating the exposure. The repository reportedly contained plaintext passwords, AWS tokens, certificates, infrastructure code, deployment files and internal documentation. Some credentials were reportedly still valid when discovered.

That is not the same thing as some dramatic headline about CISA getting completely owned. It is a repository leak, and that distinction matters. It also happens to be the part self-hosters should care about most, because this is exactly the kind of mistake that turns an ordinary lab into an easy target.

I think this is the more useful kind of security story anyway. A lot of homelab failures do not begin with a clever exploit. They begin with a secret in the wrong place, a service exposed longer than intended, or a trust boundary that only existed in your head.

Keep secrets out of repositories

The most direct lesson from the CISA incident is not about firewalls or VLANs. It is about credential handling.

Never commit passwords, API keys, private keys, access tokens, .env files, database exports, or backup archives to a repository. A repository named "private" is not a security control, and deleting a secret from the latest commit does not remove it from Git history.

At minimum:

keep secrets in environment files excluded by .gitignore
use a password manager or secrets-management system
enable repository secret scanning and push protection
rotate a credential immediately if it has been committed
inspect Git history, not only the current working tree
give tokens only the permissions and lifetime they require

A leaked credential should be treated as compromised even if there is no evidence that somebody used it.

That last point is where people still talk themselves into delay. They tell themselves nothing bad happened, so there is nothing to rotate. I do not buy that. If a token was in a public repo, the safe assumption is that it is gone.

The same principle showed up in my write-up on GitHub token theft through a VS Code bug. The bug mattered, but the real damage came from what a leaked credential could unlock after it escaped.

Audit what is actually exposed

A surprising number of homelabs run on assumption. The owner thinks only 80 and 443 are open because that is what they meant to expose six months ago.

Check it from the outside.

nmap -Pn yourdomain.com
sudo nmap -Pn -p- your-public-ip

The first command checks common TCP ports. The second scans all TCP ports and takes longer. UDP requires a separate scan.

Run the external scan against your known public IP from a device outside the home network. Do not rely on scanning a proxied hostname, because that may test Cloudflare's edge rather than your router or server.

Also, scan only systems you own or have permission to test. That should be obvious, but it still needs saying.

Then check the host itself:

ss -tulpn

That gives you the local listening sockets. The question is not just what is running. The question is what is reachable from somewhere it should not be reachable from.

If you self-host AI services, this matters even more because too many people publish them first and think about access control later. A service with weak or missing auth becomes a very different problem the moment it stops being localhost-only.

One blunt rule helps here: if you no longer remember why a port is open, close it until you do remember.

Put authentication in front of selected services

Weak authentication still causes more real damage than most fancy attack chains.

If a service supports MFA, turn it on. If it does not, put something in front of it that does. Authelia, Authentik, and Cloudflare Access are all reasonable ways to stop a login page from sitting naked on the internet.

This only works when users cannot bypass the authentication proxy and connect directly to the backend service. Restrict the origin with firewall rules, private networking, or binding to localhost where appropriate.

MFA and proxy authentication reduce the risk of stolen login passwords, but they do not necessarily protect API tokens, session cookies, application keys, or credentials that bypass the interactive login.

That is why I like layered controls more than single-product confidence. A reverse proxy is useful. A reverse proxy plus localhost binding plus tight firewall rules is better.

The point is the same either way: do not confuse a clean login page with real isolation.

Segment the network properly

Flat networks are lazy, and they are generous to attackers.

If your laptop, phone, TV, random IoT plug, and Proxmox host all sit in one easy broadcast neighbourhood, one compromise can turn into a walk across your whole lab.

A simple layout is already better than the usual everything-on-one-LAN mess:

Main devices: 192.168.10.0/24
Homelab servers: 192.168.20.0/24
IoT devices: 192.168.30.0/24
Guest Wi-Fi: 192.168.40.0/24

Then make the policy boring and strict:

Guest reaches the internet, not your servers
IoT reaches only what it actually needs
Admin access to Proxmox, SSH, and dashboards comes from your trusted network only

Different IP ranges alone do not provide segmentation. The network equipment must place them in separate VLANs or interfaces and enforce firewall rules between them.

That is the part people skip. Changing the third octet is not segmentation. Enforcing traffic boundaries is segmentation.

A compact setup is easier to secure because you can still explain it to yourself six months later. My Proxmox homelab setup on a mini PC and the BMAX Pro 8 budget homelab comparison both come back to the same point: extra complexity creates blind spots fast.

Add brute-force protection and rate limits

Anything with a login page gets hammered eventually.

If you expose SSH, a reverse proxy, a dashboard, or any admin panel, assume bots are already trying it. Fail2ban still earns its place here, but only if it is actually watching the right logs.

sudo apt update
sudo apt install fail2ban
sudo systemctl enable --now fail2ban

A healthy jail might produce output similar to this:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 3
|  `- Total failed:     19
`- Actions
   |- Currently banned: 1
   `- Total banned:     4

Fail2ban must be connected to the correct application or proxy logs. When traffic passes through Cloudflare or another proxy, configure trusted proxy handling carefully so the system reads the real client address without trusting spoofed headers.

Pair that with firewall rules that make sense for the host.

sudo ufw default deny incoming
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status numbered

If you are doing this over SSH, stage the allow rules first so you do not lock yourself out.

Be aware that Docker manages its own firewall rules. A container port published on 0.0.0.0 may not behave as expected under a simple UFW policy. Check published ports with docker ps and test reachability externally.

Reverse-proxy rate limits help too. They will not make a weak stack strong, but they do remove easy wins from bots that rely on unlimited retries.

Patch deliberately and on schedule

Most self-hosters do not ignore updates because they are careless. They ignore updates because the process is vague, annoying, and easy to postpone.

That is why cadence matters. Pick a rhythm and make it boring.

For Docker-based services, I still prefer two separate habits:

notice that an image changed
decide when to roll it out

That is why I like tools such as Diun or Dockcheck. They tell you something moved without automatically changing production. Auto-update tools have their place, but I would be careful with anything that touches your reverse proxy, auth layer, or database while you are asleep.

A safer update cycle looks like this:

docker compose pull
docker compose up -d

Run it when you can watch the result.

If you harden containers, test those changes one at a time:

read_only: true
security_opt:
  - no-new-privileges:true
cap_drop:
  - ALL

Test these settings one at a time. A read-only container may still have writable volumes, and dropping every capability may break software that requires a specific capability. Add back only what the application demonstrably needs.

Start where the risk drops fastest

Do not turn this into a heroic weekend project.

Start with the fix that removes the most risk in your own setup. Sometimes that is rotating an exposed token. Sometimes it is closing a port you forgot about. Sometimes it is putting one fragile service behind a proper auth layer and binding the backend to localhost.

The CISA contractor leak is a useful warning because it is ordinary. There was no magic to it. Just credentials in the wrong place, followed by the usual cleanup.

That is exactly why homelab owners should pay attention.

Homelab Burnout: Sustainable Self-Hosting When the Hobby Starts Feeling Like Work

Mike — Mon, 13 Jul 2026 02:00:01 +0000

Homelab Burnout: Sustainable Self-Hosting When the Hobby Starts Feeling Like Work

Browse r/homelab for long enough and you will regularly find people questioning whether their homelab has become more work than fun. People are not tired of technology itself. They are tired of turning a useful hobby into an unpaid support contract.

I teach computer science full-time, run a stack of self-hosted services, write here, and record YouTube videos. My homelab is useful, but only when it stays in its lane. The moment it starts demanding daily babysitting, it stops being a hobby and starts behaving like a badly managed side business.

That is my opinion on this, and I will argue it plainly: a homelab should solve problems you actually have. The second it exists mainly to generate maintenance work, the learning value starts to disappear. You are just doing chores in Docker.

The homelab burnout escalation trap is real

Most homelabs do not become messy in one big leap. They grow one perfectly reasonable decision at a time.

You add Plex because you want your media in one place. Then you add Uptime Kuma because monitoring feels responsible. Then a reverse proxy, then a dashboard, then a note-taking tool, then an automation tool, then a second database because one app prefers Postgres and another wants Redis. A few weeks later you have twenty moving parts and half of them are there because they looked useful on somebody else's YouTube channel.

That is how hobby scope creep works. Nobody wakes up and decides to build an unreliable mini data centre in the spare room. You just keep saying yes to one more service.

I already trimmed my own stack once. In Self-Hosting Toolkit: 10 Apps I Actually Use Every Day, the key phrase is "actually use." That was not branding. It was a survival rule. If a service does not save time, make money, teach me something worth keeping, or solve a regular problem in my week, it does not deserve a permanent slot.

A lot of burnout comes from running software with no job description.

Automation should remove toil, not create clever new failure modes

Automation is the part everyone talks about, but many people automate the wrong things. They build a complicated chain of scripts, webhooks, and notifications, then spend Saturday debugging the automation instead of the original problem.

Good homelab automation is boring. It cuts repeat work. It makes failure obvious. It does not need a diagram just to explain why your container restarted.

A simple Docker health check earns its place because it answers a basic question: is this service alive or not?

services:
  app:
    image: my-app:1.4.2
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3

This assumes the image includes curl and the application exposes a /health endpoint. Otherwise, use a command already available inside the container or add an appropriate health-check method.

That is useful. It replaces guesswork with one small signal. Pinning a known version also makes updates more deliberate and rollbacks easier.

The same applies to update routines. I do not want to remember which container needs a manual pull, which one changed its environment variables, and which one quietly stopped two weeks ago. If you are relying on memory for routine maintenance, you already have a fragile system.

This is also why I still like small, direct tooling. A maintenance script that checks container status, disk usage, and backup age is worth more than a beautiful dashboard I only open after something breaks. Monitoring should tell you what needs attention. It should not become another thing you maintain for its own sake. My Hermes Agent mini PC setup guide comes from exactly that mindset: use automation to remove repeated admin work, not to build a second system you have to babysit.

If you want the short version, build the minimum system that answers three questions:

Is the service up?
Is the data backed up?
Will I notice when something fails?

Everything beyond that needs to justify itself.

Boundaries matter more than enthusiasm

This is the part many homelab guides skip because it is less fun than listing tools.

You need boundaries.

Not every service should be self-hosted. Some are worth the effort because they protect privacy, centralise your workflow, or save ongoing subscription costs. Others are cheap in dollars and expensive in attention.

The best question I know is this: what happens if this service breaks for 48 hours?

If the honest answer is "nothing important," it probably should not sit in the centre of your setup. It might still be a good weekend experiment. It just should not become permanent infrastructure.

That is the difference between a lab and a dependency. Labs are where you test ideas. Dependencies are the things that quietly ruin your week when they go down.

For me, the keepers are the services that support real work: file storage, monitoring, automation, remote access, and a few tools I touch constantly. A smaller stack is not less serious. It is usually better engineered because you can still understand it on a tired Tuesday night. The same bias toward manageable infrastructure is why I built my Proxmox homelab setup on a mini PC around hardware I can understand, recover, and afford to leave running.

A lot of people also underestimate security overhead here. Every exposed dashboard, admin panel, and reverse proxy route increases the attack surface. Limiting permanent services is therefore not only a maintenance decision; it is also a security discipline. That is why I treat access control and certificates as infrastructure, not decoration. If you use Cloudflare and want an additional authentication layer in front of selected services, Cloudflare Self-Managed OAuth is worth understanding. It complements rather than replaces secure configuration, updates, certificates, and network controls.

Documentation is what saves you at 2 AM

The most underrated homelab tool is not Docker, Proxmox, or a reverse proxy. It is documentation.

I mean boring documentation. The kind that tells you which compose file matters, which ports are already in use, which volume paths hold real data, which containers depend on each other, and what to restore first after a bad update.

Without that, every outage becomes archaeology.

This is where my Obsidian vault earns its keep. I keep service notes, recovery steps, container locations, backup paths, and configuration decisions in one place. Not because it is elegant, but because I do not trust the tired version of myself to remember why something was set up a certain way six months ago.

A useful service note can be brutally simple:

Service: Uptime Kuma
Compose file: /opt/monitoring/docker-compose.yml
Data path: /opt/docker/uptime-kuma
Depends on: reverse proxy + local DNS
Backup: nightly tar to external drive
Restore order: DNS -> proxy -> Kuma

That note has saved more time than any fancy dashboard ever has.

The same habit applies to anyone learning to build real systems. Sustainable engineering is not just about writing code that works today. It is about leaving enough context behind that the next person, or future you, can support it without panic. Real systems fail. Good documentation turns failure from chaos into a checklist.

The economics are not just about money

Self-hosters love talking about savings, and sometimes the savings are real. A small mini PC, a couple of drives, and a handful of containers can absolutely replace several monthly subscriptions.

But cost is not just hardware plus electricity.

Time is part of the bill.

If a service saves you $4 a month but costs two hours of maintenance every other weekend, that is not frugal. That is expensive in a different currency. The maths gets worse if the service is something you barely use.

This is why I think the healthiest homelab mindset is selective self-hosting. Keep the things that give you one of these returns:

control over important data
a workflow improvement you genuinely notice
a solid learning payoff
a clear cost saving without constant babysitting

If it gives you none of those, it is probably clutter.

I also think there is a phase many homelabbers need to go through once: the purge. Not a dramatic teardown, just an honest audit. Open the compose files. List the services. Ask what each one is doing for you now, not what you hoped it would do when you installed it.

Delete the tourists: services that arrived as experiments, contributed nothing, and never left.

A quick homelab sustainability audit

For each permanent service, ask:

Did I use it during the last 30 days?
Does it hold data that matters?
Is it backed up and tested?
Do I know how to restore it?
Would replacing it with a hosted service reduce meaningful work?
Is its learning value still greater than its maintenance cost?

A service that fails most of those questions probably belongs in the lab, not in permanent production.

My rule now

I still enjoy self-hosting. I am not interested in a purity test where everything must live on somebody else's cloud. But I am also done pretending that more containers automatically mean more skill.

My rule now is simple: every service must earn the right to keep running.

If it saves time, protects data I care about, supports teaching or content work, or teaches me something I will reuse, it stays. If it mostly produces updates, alerts, and extra surface area, it goes.

That shift changed the feel of my homelab completely. It is calmer. Easier to recover. Easier to explain. Easier to leave alone for a few days without wondering what is quietly breaking.

That is what sustainable self-hosting looks like. Not the biggest stack. The one you can still live with.

Six arguing AI agents: what multi-agent debate teaches CS students about AI architecture

Mike — Sun, 12 Jul 2026 14:58:14 +0000

Six arguing AI agents: what multi-agent debate teaches CS students about AI architecture

Most students meet AI through prompts. Type a question, get a paragraph back, move on.

That framing is useful for five minutes and then it gets in the way.

The more interesting lesson is what happens when you stop treating a model like a single all-knowing assistant and start treating it like one noisy component in a bigger system. Give several model instances the same problem. Ask each one for an answer. Make them criticise each other. Force another round. Then have a judge combine the best points.

Suddenly the discussion stops being about prompt wording and starts being about architecture.

That is why multi-agent debate matters. Not because six chat windows arguing with each other are cute, and not because debate turns an LLM into a reliable thinker. It matters because the pattern exposes what these systems are actually good at, where they fail, and what good computer science students should notice before they get hypnotised by demo videos.

My take is blunt: prompt engineering is the least interesting part of this story. System design is the lesson.

What multi-agent debate actually is

The 2023 paper "Improving Factuality and Reasoning in Language Models through Multiagent Debate" describes a simple setup: multiple language model instances propose answers, debate them over several rounds, and then converge on a final answer. The authors report improvements on mathematical and strategic reasoning tasks, along with reductions in fallacious and hallucinatory responses compared with single-agent baselines.

The idea is not mystical. You are building a feedback loop.

A basic debate pipeline usually looks like this:

Agent A, B, and C each answer the same prompt independently.
Each agent reads the others' answers and points out weak logic, missing steps, or contradictions.
Each agent revises its own answer after seeing criticism.
A final judge, or one more synthesis pass, picks the strongest parts.

That workflow borrows from something humans already do in programming: code review. One developer writes the first pass. Another person spots the broken assumption. Someone else notices the edge case. The final version is better, not because one brain became smarter, but because the process exposed mistakes before they shipped.

If you have read my piece on searching old AI conversations, the same pattern shows up there too. The value is often in the review loop, not the first output.

What debate reveals about LLM architecture

This is the part students should care about.

A large language model is still an autoregressive system that predicts the next token from context. The GPT-3 paper describes it as an autoregressive language model, and the 2022 paper "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" showed that giving models room to produce intermediate reasoning steps can improve results on arithmetic, commonsense, and symbolic tasks. Multi-agent debate pushes that same idea one step further: instead of one long reasoning trace, you create several traces and let them attack each other.

That tells you something important.

A lot of what people call "reasoning" in practice is not a hidden mode that switches on inside the model. It is often the result of structure wrapped around the model: extra steps, extra context, criticism, retries, and selection. In other words, the intelligence you see is partly in the orchestration.

I think students need to hear that early, because the internet keeps selling the opposite story. One flashy demo appears, people act as if the model has crossed some mysterious line, and the system design vanishes from the conversation.

But look at what debate is doing under the hood:

redundancy, because several agents attempt the task
error detection, because agents inspect each other's reasoning
iterative refinement, because answers are revised instead of accepted once
aggregation, because a judge or synthesis pass chooses among alternatives

Those are architecture decisions. They are not prompt tricks.

That is also why multi-agent systems look a lot like classic CS ideas wearing new clothes. Distributed systems use redundancy because one node can fail. Compilers use multiple passes because one pass is not always enough. Software teams use tests and review because the first version is rarely the final one. Debate is the same instinct applied to a probabilistic text engine.

The useful lesson is not "AI thinks better in groups"

Be careful with the headline version of this idea.

It is tempting to say that a group of agents "thinks" better than one agent. I would phrase it more carefully. A structured group process can produce better outputs than a single pass because it creates more chances to catch obvious mistakes.

That difference matters.

If three weak answers all share the same bad assumption, debate does not magically rescue you. It can even make the wrong answer sound more convincing, because now it arrives with consensus theatre attached. Agreement is not proof. A polished synthesis is not proof either.

That is one reason I still prefer grounded workflows over pure discussion workflows. The 2022 paper "ReAct: Synergizing Reasoning and Acting in Language Models" is useful here because it combines reasoning traces with actions that fetch external information. For factual tasks, a debating panel with no access to evidence is still trapped inside its own guesses.

So yes, debate can help. No, it does not turn a language model into a truth machine.

Why CS students should care

If I were teaching this to a class, I would not present multi-agent debate as an AI party trick. I would use it to teach systems thinking.

Students usually start with the surface layer: the prompt. That is understandable. It is the part they can see.

But the deeper question is this: what kind of system are you building around an unreliable component?

That question is pure computer science.

1. It teaches decomposition

A decent multi-agent workflow splits one job into smaller responsibilities: proposer, critic, judge, verifier. That is exactly how good software systems are designed. Different parts do different jobs. Nobody asks the same component to generate, verify, rank, and explain everything perfectly in one pass.

2. It teaches evaluation

Students often stop at "the AI answered." Debate forces the next question: answered according to what standard?

Was the logic complete? Did it use evidence? Did two agents agree for the same reason, or did one just copy the other? What would count as a failure case?

Those are evaluation questions, and they matter more than the prompt itself. I made a similar point in my guide on how to set up a test pipeline that actually catches bugs, because good systems need clear checks, not vibes.

3. It teaches observability

One reason single-shot AI tools are slippery is that you only see the final sentence. Debate systems expose more of the path. You can inspect the initial answers, the objections, the revisions, and the final merge. That makes the system easier to debug.

It is the same reason tracebacks matter in programming. If you only saw "program failed," you would learn very little. If you can inspect the chain of events, you can actually reason about the bug. That is why I keep pushing students toward explicit debugging habits instead of one-shot guesswork.

4. It teaches trade-offs

Debate sounds clever until you pay for it.

Three rounds with four agents is already twelve model calls before the judge speaks. Latency goes up. Cost goes up. Failure modes multiply. Prompt leakage between agents becomes a design issue. Logging becomes a design issue. Rate limits become a design issue.

That is good news for a CS classroom, because now the conversation is finally real. Students are not just asking, "Can AI do it?" They are asking, "What did this architecture cost, and was the gain worth it?"

That is a much better question.

Three debate frameworks students can try

You do not need a research lab to experiment with this. You just need to keep the tasks small and the scoring clear.

The two-agent critic loop

This is the simplest version.

Agent 1 writes an answer.
Agent 2 critiques it line by line.
Agent 1 revises once.

Use it for short explanations, code comments, or a paragraph answering a theory question. Students learn quickly that the second pass is often less about brilliance and more about catching omissions.

The three-agent committee

Give the same question to three isolated agents. Do not let them see each other at first. Then ask a judge to compare them against a rubric.

This works well for structured tasks: design choices, algorithm explanations, short essays, and worked examples. The point is not to vote blindly. The point is to inspect disagreement. When two answers agree and one dissents, students should ask why.

The evidence-first debate

This is the one I would push hardest.

Before any agent can argue, each one has to quote or retrieve evidence from an approved source set: lecture notes, a paper extract, a dataset, or a fixed documentation page. Only then can the critique round begin.

That rule stops the exercise from turning into a confidence contest. It also teaches a habit students badly need in the AI era: separate fluent output from justified output.

If students want to run these experiments locally, they do not need an expensive machine. Smaller local setups are enough for classroom-scale tests, especially if the tasks are short and the models are modest. I covered that trade-off in my guide on running AI models on old hardware. For experimentation, architecture matters more than brute force.

Where the hype gets ahead of reality

This is where I part company with the more breathless AI commentary.

When people show a multi-agent demo, they often imply that the magic comes from "more agents." I do not think that is the right takeaway. Past a certain point, adding more agents can just add more noise, more cost, and more nicely formatted nonsense.

The better question is whether each added step has a job.

Does one agent bring independent evidence?
Does one agent act as a strict verifier?
Does one round of critique catch a failure mode you have actually observed?

If the answer is no, you are probably building theatre.

I see the same issue in some local AI tooling conversations too. People pile on frameworks because the stack looks impressive, not because each layer solves a real problem. That is why I keep coming back to practical architecture choices in posts like Learning Docker by Building a Container Engine from Scratch. More moving parts only help when each part earns its place.

What I would want students to remember

If this topic lands anywhere useful in a CS classroom, it should land here.

A language model is not the whole system.

The prompt is not the whole system.

The benchmark screenshot is definitely not the whole system.

What matters is how you handle uncertainty, error checking, evidence, revision, and cost around a component that is fluent but unreliable. Multi-agent debate is worth studying because it makes those design choices visible.

That is the lesson I would argue for: AI architecture is a systems problem first, and a wording problem second.

A simple classroom version is to give three agents the same algorithm explanation, ask each one to identify the weakest assumption in the others' answers, then have students compare the final synthesis against a rubric. That keeps the lesson concrete. Students can see whether the extra critique round exposed a real weakness or just produced more polished noise.

Students who understand that will build better tools, ask better questions, and fall for fewer demos.

That seems more useful than teaching them how to write one more clever prompt.

TLS Certificates for Internal Services: HTTPS Inside Your Homelab

Mike — Sat, 11 Jul 2026 04:35:52 +0000

TLS Certificates for Internal Services: HTTPS Inside Your Homelab

Most homelab TLS setups stop at the front door.

You put Caddy, Nginx, or Traefik in front, get a valid certificate for app.example.com, and call it done. From the browser to the reverse proxy, everything is encrypted. From the reverse proxy to the actual container, it is often plain HTTP on port 80 or 8080.

That is not automatically wrong. On a single mini PC with a couple of containers, internal TLS is rarely the first problem I would fix. Weak passwords, overexposed dashboards, and lazy network rules usually matter more.

But once a homelab grows beyond "one box, three containers," plain HTTP starts spreading everywhere. A reverse proxy talks to one VM over HTTP. A helper container calls another API with no encryption. A dashboard sends session cookies across the LAN because "it's only internal." That is the point where internal TLS stops being cosmetic and starts being decent housekeeping.

My view is simple: if a service is worth exposing through a nice hostname, it is probably worth deciding how you want to trust it internally too.

Where plain HTTP sneaks back in

The usual pattern looks like this:

Browser to reverse proxy: HTTPS
Reverse proxy to upstream app: HTTP
App to database: whatever the default was
Admin tool to API endpoint: plain HTTP because it lives on the same subnet

That can be acceptable in a tiny setup where everything runs on one host and nothing else can reach the traffic path. I still would not call it a long-term design. The moment you add another VM, another Docker host, or a tunnel back into the network, your "internal only" assumption gets weaker.

This came up for me while thinking about the same problem I discussed in my self-hosted AI security guide. Once you start putting tools behind reverse proxies and opening remote admin paths, the old habit of "just use HTTP inside" sticks around long after the setup stopped being small.

Internal TLS does not make a homelab secure. It does do three practical things:

It reduces casual packet snooping on segments you do not fully trust.
It lets you test the same HTTPS assumptions internally that you expect externally.
It stops you from building workflows that silently depend on insecure defaults.

That third one matters more than people admit. If your automation only works when certificate checks are disabled, you have already taught your stack a bad habit.

The three approaches that actually make sense

I would ignore the endless certificate-tool rabbit hole and stick to three realistic options.

1. Local CA for quick wins

If your goal is "I want valid-looking HTTPS inside the lab by tonight," a local CA is the low-friction option.

Caddy has a local_certs option that tells it to issue certificates internally instead of using a public ACME CA. That makes it useful for development environments and small private networks where you control the clients. The catch is the same as every private CA setup: the clients have to trust your root certificate first.

This is the best fit when:

you mostly browse services from your own machines
you control the phones, laptops, or tablets that need trust installed
you want HTTPS warnings gone without involving public DNS

This is the worst fit when:

guests or unmanaged devices need access
you do not want to distribute a root CA to every client
you expect native apps to behave nicely with an untrusted chain

In other words, local CA is tidy for a personal lab, messy for a shared one.

2. Let's Encrypt with DNS-01 for services under your real domain

If your internal services already use names under a public domain you control, DNS-01 is usually the cleanest answer.

Let's Encrypt's DNS-01 challenge docs explain that your ACME client places a TXT record under _acme-challenge for the domain. Those docs also note two details that matter here: DNS-01 can issue wildcard certificates, and it only makes sense when your DNS provider has an API you can automate.

That means you can issue certificates for names under your domain without exposing the service itself on the public internet, as long as you can update DNS records for the validation step.

This is the setup I would reach for if you already use a real domain for your homelab and want browser-trusted certificates without teaching every client to trust a private root.

It works especially well with reverse proxies that already understand ACME. Traefik's ACME docs explicitly support dnsChallenge, and the same docs note that ACME v2 wildcard certificates require a DNS-01 challenge.

The downside is operational, not conceptual. You now have DNS API credentials in the mix. That is manageable, but it deserves the same care I talked about in the Cloudflare self-managed OAuth post: narrowly scoped credentials beat one giant token that can edit everything.

3. Private ACME with step-ca when the lab stops being small

If you have multiple machines, multiple services, and want certificates to renew automatically without public DNS hacks, this is where step-ca starts making sense.

The useful part is not just "run your own CA." The step-ca ACME basics docs show that step-ca supports ACME, so standard ACME clients can request certificates from your own certificate authority instead of from a public provider. That means you can keep the familiar issuance flow while staying fully inside your own trust model.

This is the option I would choose when:

you have several hosts, not just several containers
internal service names are not part of public DNS
you want one internal CA instead of one-off self-signed certs everywhere
you are prepared to manage trust distribution properly

This is also the point where you need to be honest with yourself. A private CA is not hard because of certificate issuance. It is hard because every client needs the root certificate installed correctly, and you need a plan for renewal, revocation, and what happens when you rebuild devices.

If that sounds annoying, that is because PKI is annoying. The tooling got better. The responsibility did not.

My rule of thumb

Here is the version I would give to anyone building a real homelab instead of a PKI hobby project.

One box, mostly personal devices, low stakes: local CA is fine.
Public domain already in use, want normal browser trust: Let's Encrypt with DNS-01.
Several hosts, several internal names, long-term setup: private ACME with step-ca.

What I would not do is collect five half-solutions at once.

I have seen a lot of homelabs end up with one self-signed cert for Grafana, a reverse proxy wildcard from Let's Encrypt, one app running plain HTTP forever, and a note to "fix later" on the service that matters most. That is not a design. That is archaeology.

What to test before you call it done

After you flip a service to HTTPS, test the boring parts.

These examples are worth keeping around:


bash
curl -vk https://service.example.internal/
openssl s_client -connect service.example.internal:443 -servername service.example.internal

Beyond Ollama: 3 Homelab AI Tools Worth Trying Next

Mike — Fri, 10 Jul 2026 06:05:29 +0000

Beyond Ollama: 3 Homelab AI Tools Worth Trying Next

Ollama is the tool I recommend when someone wants their first local model running tonight. It is simple, fast to understand, and good enough for a lot of homelab jobs. Pull a model, hit an API, wire up Open WebUI, done. I already covered that full path in my Docker + Ollama + Open WebUI guide.

But Ollama also nudges you toward one shape of local AI: text models behind a neat API. That is fine until you want more control over image workflows, a cleaner OpenAI-compatible service layer, or one local runtime that can cover chat, speech, embeddings, and image generation from the same box.

That is where the next wave gets interesting.

The three projects I would watch right now are ComfyUI, LocalAI, and Lemonade. They are not direct replacements for Ollama in the sense of "uninstall Ollama and forget it exists." They solve different problems:

ComfyUI is for visual AI workflows where you want to control every step
LocalAI is for homelabbers who want a broader local API surface with OpenAI-compatible apps
Lemonade is for people who want to experiment with a broader local AI runtime with chat, image, speech, and standard APIs

My view is simple: Ollama is still the easiest first stop, but it is no longer the whole conversation. If your homelab AI stack stops at Ollama, you are missing some genuinely useful tools.

Why look past Ollama at all?

Ollama does one thing very well: it makes local LLM inference approachable. That matters. A lot of local AI users never move past the "I want a model on my machine" stage, and they do not need to.

Still, three limits show up pretty quickly.

First, Ollama is mostly about model serving, not workflow design. If you want to build a repeatable image pipeline with prompt branches, upscalers, masks, and post-processing, Ollama is the wrong tool.

Second, plenty of apps expect an OpenAI-style API and want more than text generation. LocalAI leans hard into that compatibility layer, and that can save time when you are wiring tools together.

Third, local AI is getting more multimodal. Text alone is no longer the interesting part. Speech to text, text to speech, embeddings, image generation, and agent tooling are all creeping into the same workflows. Lemonade is appealing because it is trying to package that broader stack into one local service.

That does not mean these projects are automatically better. It means they cover ground Ollama does not.

1. ComfyUI: the visual workflow engine

If your local AI curiosity has moved from "run a model" to "build a pipeline," ComfyUI is the one to try next.

ComfyUI's documentation describes it as an AI creation engine for visual professionals who want control over every model, every parameter, and every output. The docs also push two ideas that matter for homelab users: you can run ComfyUI on your own hardware through Comfy Desktop, and the whole product is built around workflows you can load, remix, and iterate on.

That workflow-first approach is the real difference.

Instead of typing one prompt into a chat box and hoping for the best, you build a graph. One node loads a checkpoint. Another encodes the prompt. Another sets sampler settings. Another upscales. Another handles masks or ControlNet-style conditioning. It feels more like wiring a media pipeline than chatting with a bot.

That is why ComfyUI matters beyond image hobbyists. It teaches a better mental model for local AI. You stop thinking in one-shot prompts and start thinking in reusable systems.

What ComfyUI is good at

For a homelab, I think ComfyUI makes sense in four cases:

You want stable, repeatable image generation workflows instead of random prompting.
You are generating assets for a blog, course, or small business and you need consistency.
You want to understand how visual AI pipelines actually fit together.
You want to save and reuse workflows instead of rebuilding the same prompt stack every time.

The community workflow library is a big part of the appeal. You can start from a template, inspect how it works, then trim it down to fit your own hardware.

Where ComfyUI gets awkward

The downside is also obvious: ComfyUI asks more from you.

If Ollama feels like docker run plus a chat window, ComfyUI feels like learning a node editor. That is not a flaw. It is the point. But it means the learning curve is real.

It is also the least forgiving option here if your hardware is modest and your expectations are not. Text inference on CPU-only hardware can still be useful, as I found in my old hardware local AI write-up. Image workflows are different. You can run them locally, but speed and model choice matter a lot more.

So my practical advice is this: do not start ComfyUI by chasing the flashiest workflow on social media. Start with a basic community workflow, a smaller model, and one job you actually have. Blog art. Thumbnail variations. Product mockups. Something concrete.

My homelab take on ComfyUI

ComfyUI is the tool in this list that most rewards a dedicated box or VM. If your homelab has a machine with a decent GPU, this is where it earns its keep. If your homelab is just a mini PC with integrated graphics and limited RAM, ComfyUI can still be educational, but I would not make it your first "serious production" local AI service.

That is also why I do not see ComfyUI as an Ollama replacement. I see it as the moment local AI stops being only about chat.

2. LocalAI: the compatibility play

LocalAI is interesting for a completely different reason.

Its homepage makes the pitch very clearly: it is a free OpenAI and Anthropic alternative, built as a small composable AI stack. The LocalAI quickstart also states that it is a drop-in replacement for the OpenAI API, supports multiple model families, and can run language models, images, audio, and more locally. Docker is the recommended installation method, and the quick start is straightforward:

docker run -p 8080:8080 --name local-ai -ti localai/localai:latest

That single detail tells you who LocalAI is for.

It is for the homelabber who already has a pile of tools that expect a familiar API shape and does not want to keep adapting everything around one runtime. If you have scripts, agent tools, or self-hosted apps that speak OpenAI-style endpoints, LocalAI can be easier to slot into place than a more opinionated stack.

What LocalAI is good at

The best part of LocalAI is not that it tries to do everything. It is that it tries to expose local models through interfaces a lot of existing software already understands.

That gives it three obvious uses in a homelab:

replacing cloud API calls in tools that already support OpenAI-compatible backends
centralising local inference behind one service instead of a stack of ad hoc wrappers
experimenting with broader local AI features without locking yourself into a single app UI

I also like the way the project frames itself as composable. That usually matters more in a homelab than polished marketing. You want pieces you can fit into your own stack, not a black box that wants to own the whole machine.

The part people gloss over

OpenAI-compatible does not mean identical behaviour across every app.

This is where a lot of local AI blog posts get sloppy. A compatible API gets you much closer to plug-and-play, but model capabilities, latency, backend support, and edge-case behaviour still vary. The docs promise the API shape. They do not promise every upstream app will behave exactly as if it were talking to OpenAI.

That is not a criticism of LocalAI. It is just the honest version.

If you are the kind of homelabber who likes clean interfaces and clear boundaries, LocalAI is a strong fit. If you want a dead-simple chat setup in ten minutes, Ollama is still easier. If you want a broad local API target for apps and experiments, LocalAI starts to look better.

My homelab take on LocalAI

This is the one I would try first if I were moving from "local toy" to "local platform."

Why? Because a homelab gets messy fast. One service wants text generation. Another wants embeddings. Another expects an OpenAI-style endpoint. Another needs audio later. A compatibility layer matters more than people think.

I would still keep the deployment conservative. Bind it locally first. Put a reverse proxy and auth in front of it if you need remote access. The same local AI security rules I wrote about for Ollama still apply here: do not confuse "self-hosted" with "safe by default."

3. Lemonade: the all-in-one runtime I would keep an eye on

Lemonade is the newest-feeling project in this list, and it is the one I find easiest to imagine on a modern homelab.

Its site pitches Lemonade as local AI for text, images, and speech. The installation flow says it equips your machine with an AI runtime, GUI, CLI, and API endpoints. The Lemonade GitHub project pushes the same idea harder: Lemonade Server exposes standard OpenAI, Anthropic, and Ollama APIs, while the broader platform covers chat, coding, speech, image generation, transcription, and embeddings.

For Docker users, the site shows this quick start:

docker run -d \
  --name lemonade-server \
  -p 13305:13305 \
  -v lemonade-cache:/root/.cache/huggingface \
  -v lemonade-llama:/opt/lemonade/llama \
  ghcr.io/lemonade-sdk/lemonade-server:latest

That is a serious homelab signal. It tells me the project understands how people like us test things: one container, mapped port, persistent volumes, then decide whether it deserves a permanent home.

What Lemonade is good at

What I like here is the ambition.

Lemonade is not saying "here is one local model runner." It is saying "here is a local-first AI runtime that can serve apps and agents, speak familiar APIs, and cover multiple modalities." The README even exposes CLI flows like lemonade run, lemonade pull, and lemonade list, plus a built-in model manager.

That makes Lemonade appealing for a homelab in three situations:

you want one local runtime for more than chat
you want a local service that can talk to existing apps over standard APIs
you want multimodal experiments without stitching five unrelated projects together yourself

There is also a quiet but important detail in the README: Lemonade documents support across CPU, GPU, and in some cases NPU-focused configurations depending on backend and platform. I would not promise all of that on every random mini PC. But the direction is interesting. It feels closer to where local AI is heading.

Why I would still be cautious

The more all-in-one a project becomes, the more you need to be realistic about scope.

Broad capability claims are easy to love in a README and harder to operate in a homelab. Multimodal stacks usually mean more storage, more dependency churn, more model management, and more opportunities to end up debugging the runtime instead of using it.

So I would treat Lemonade as a platform experiment before I treated it as core infrastructure.

That is not an insult. Plenty of the best homelab tools start as platform experiments.

My homelab take on Lemonade

If I wanted one box in the rack to become "the local AI services machine," Lemonade is the project here that best matches that idea.

Not because it is automatically the best at every individual task. It probably is not. But because it is trying to unify text, image, speech, and app-facing APIs into one local runtime. That is a more useful direction than yet another single-purpose model wrapper.

Which one should you choose?

Short version.

Pick ComfyUI if:

you care about image generation or visual workflows more than chat
you want to build reusable pipelines, not just send prompts
you have the patience to learn a node-based tool properly

Pick LocalAI if:

you want a local OpenAI-compatible service for apps and scripts
you are building a broader self-hosted AI platform, not just a chat box
you prefer composable infrastructure over an all-in-one user experience

Pick Lemonade if:

you want one local runtime that reaches beyond text
you care about chat, speech, embeddings, and image generation in the same stack
you like the idea of standard APIs plus local-first multimodal tooling

Stick with Ollama if:

your real need is still just local text inference
you want the smallest setup burden
you value simplicity more than feature breadth right now

That last one matters. There is no prize for making your homelab more complicated than it needs to be.

Practical setup advice before you install any of them

This is the part that matters more than choosing the "right" brand.

1. Separate experiments from core services

Do not dump every AI runtime onto the same VM that already runs your password manager, DNS, and media stack. Give local AI tools their own box, LXC, or VM where possible. They pull big models, eat disk, and change quickly.

If you are planning that separation now, my homelab network design guide is the post I would read before carving out another AI host.

2. Start with one use case, not three

The fastest way to waste a weekend is to install ComfyUI, LocalAI, and Lemonade in one sitting and learn none of them properly. Pick one actual job first.

If the job is image workflows, use ComfyUI.
If the job is API compatibility, use LocalAI.
If the job is "I want a broader local AI service layer," try Lemonade.

3. Budget storage before you budget hype

Model storage gets out of hand fast. Between checkpoints, embeddings, speech models, caches, and image assets, local AI can eat SSD space long before it maxes out CPU.

4. Keep security boring

Local AI projects are still software stacks with ports, APIs, and update cycles. Keep them off the open internet unless you have a very good reason. Bind locally first. Add auth deliberately. Reuse the same caution you would use for any self-hosted dashboard or API. My Ollama security guide exists for a reason.

My actual opinion

I do not think the next step after Ollama is "the one true replacement." I think the better question is what kind of homelab AI user you are becoming.

If you are becoming a workflow builder, ComfyUI makes sense.
If you are becoming an infrastructure person, LocalAI makes sense.
If you want a local-first service layer that feels closer to a real AI platform, Lemonade is the one I would watch.

That is why this space is more interesting now than it was six months ago. Local AI is finally splitting into real categories instead of pretending every problem is solved by one model runner and a chat window.

Ollama got a lot of people through the front door. Good. It needed to happen.

But the room is bigger now.

If you want the philosophy behind local-first AI, read Right to Local Intelligence. If you want the easy starting point, use Ollama. If you want the next layer in a homelab that is starting to do serious work, these three are where I would look next.

How to Ask for Help: Technical Communication Skills Every CS Student Needs

Mike — Thu, 09 Jul 2026 02:01:19 +0000

How to Ask for Help: Technical Communication Skills Every CS Student Needs

A student shows me a Python program and says, "It doesn't work."

That is the whole bug report.

No error message. No explanation of what the program is meant to do. No clue whether it ever worked, whether they changed anything, or whether they even ran it again after the last edit. I have to drag the story out of them one question at a time, like I'm interviewing a very tired witness.

This is not a small classroom habit. It is a technical communication problem, and it follows students straight into university, internships, GitHub issues, team chats, and software jobs.

Most CS courses spend a lot of time on syntax, algorithms, and debugging. They spend far less time on the moment just before debugging becomes collaborative: the point where you have to explain the problem to another human. That missing skill matters more than students realise. A clear help request saves time, gets better answers, and often helps you solve the problem before anyone replies.

I would go further than that: I think a student who can describe a bug clearly is usually closer to being job-ready than a student who can memorise one more sorting algorithm but cannot explain what broke.

Why this skill matters more than students think

The Cambridge IGCSE Computer Science syllabus for 2026-2028 says practical problem-solving and programming should be integral to the course, and that learners should have the opportunity to write, run, test, and debug their own programs.

The human side is what happens when testing and debugging stall.

If you cannot explain what you expected, what happened instead, and what you already tried, your teacher, classmate, or teammate starts from zero every time. Good questions lower that cost. Bad questions spread confusion.

This also scales beyond school surprisingly fast. The same habits show up in:

asking a teacher why your pseudocode answer lost marks
posting on Stack Overflow
filing a GitHub issue for a broken project
asking for help in a company Slack channel
handing over a bug to another developer during a team project

That is why this is not just "how to ask nicely." It is part of technical work.

The three mistakes that waste the most time

Asking about the guess instead of the real problem

This is the classic XY problem.

The short version is simple: you want to solve X, you get stuck, you guess that Y might be the way to do it, then you ask for help with Y instead of explaining X. The person helping you sees a strange sideways question and has no idea what you are actually trying to achieve.

A student version of this sounds like:

"How do I make Python ignore line 14?"

Maybe line 14 is not the real issue. Maybe the real issue is that the student is trying to skip invalid input, or they misunderstood a loop condition, or they are patching around data that should have been cleaned earlier.

If you only ask about the guessed fix, people can spend ten minutes helping with the wrong thing.

I see this constantly when students jump straight to a supposed solution instead of describing the goal. They ask, "How do I stop this traceback from showing?" when the real question is, "Why is my file not opening?" They ask, "How do I force this variable to become an integer?" when the real question is, "Why is my comparison failing?"

If you remember one rule from this post, make it this one: explain the actual task before you explain your attempted fix.

Being too vague

"My code is wrong" is not a useful starting point.

Neither is "Please help asap" or "Why doesn't this work?"

The Stack Overflow help page on asking good questions still pushes the same basic idea it has pushed for years: search first, then ask a question that summarises the specific problem. That works because specific questions are answerable. Vague questions are not.

A vague question forces the helper to guess:

what language or tool you are using
what output you expected
what output you got
whether there was an error message
whether the bug happens every time
whether your code is complete enough to run

By the time all of that gets clarified, the conversation has already become slower and more irritating than it needed to be.

Hiding the context and the attempt

Students sometimes think showing failed attempts makes them look weak. In reality, hiding them makes the question harder to answer.

What you tried is part of the technical evidence.

If you already tested two different loops, changed the file path, and confirmed the CSV exists, that matters. It stops people suggesting the same dead ends again. It also proves you are not asking someone else to do the whole task for you.

The same goes for error messages. Do not paraphrase them into mush.

"Python had some syntax problem" is far less useful than pasting the actual traceback and saying which line you think it points to.

A simple framework for writing a good help request

When students ask me for a template, I give them four parts.

1. Context

Start with what you are trying to build or do.

Not your guessed fix. The real task.

Good:
"I'm writing a Python program for an IGCSE-style file handling task. It should read names and marks from a text file, then print the highest mark."

Bad:
"How do I make line 8 skip to line 12?"

The first version gives the helper a map. The second throws them into a random alley.

2. What you expected

Say what the program, query, script, or system should do.

For example:
"I expected it to print the highest mark in the file, which should be 87."

This sounds basic, but it matters. Debugging without a clear expected result turns into guesswork.

3. What actually happened

Now give the observed behaviour.

That could be:

the exact error message
the wrong output
no output
a crash
a hang
inconsistent behaviour between runs

Be literal. Paste the traceback. Quote the output. Name the line number if you have one.

4. What you already tried

Finish with the attempt.

For example:
"I checked whether the file path was correct, printed each line to confirm the file was reading, and changed highest = 0 to highest = int(lines[0]), but I still get a ValueError on the blank final line."

That sentence does two useful things. It shows effort, and it gives the helper a narrower search area.

Put those four parts together and the question becomes much easier to answer.

A minimal reproducible example saves time

On Stack Overflow, the standard advice is to provide a Minimal, Reproducible Example.

Minimal means you cut the code down to only the part that still shows the problem.

Complete means someone else has everything they need to run it.

Reproducible means you tested it yourself and confirmed the problem still happens.

It feels fiddly at first, but it pays off fast.

When students trim a 140-line program down to 18 lines and the bug disappears, they often solve the problem before they even send the question. The act of isolating the bug is already a debugging method.

It also makes helpers more willing to engage. Eighteen lines will get read far more often than a full coursework dump.

Bad question vs good question

Here is the kind of message that usually goes nowhere:

"My Python file handling code isn't working. Can someone fix it?"

That gives the helper almost nothing.

Now compare it with this:

"I'm writing a Python program that reads student names and marks from a text file, then prints the highest mark. I expected it to print 87, but instead I get ValueError: invalid literal for int() with base 10: '' on line 12. I tested the file path and printed each line, and I think the problem is the blank line at the end of the file. Here's the 14-line version that still causes the error."

That second version is just structured.

And structure is the whole game here.

I would rather read a blunt, slightly messy question like that than a polished message that hides the real issue.

What this looks like in a professional setting

Students sometimes think this advice only applies to forums. It does not.

In software work, asking for help usually becomes one of these:

a bug report
a GitHub issue
a pull request comment
a handover note
a message in a team chat

GitHub's own issue flow is built around the same basics: write a title, then describe the issue in the body. That is not bureaucracy. It is an attempt to make problems legible.

A strong junior developer still gets stuck.

A strong junior developer is someone who can say:

what they were trying to do
what environment they were using
what steps reproduce the bug
what they expected
what they saw instead
what they already checked

That person is easier to help, easier to trust, and easier to work with.

This is one reason I keep pushing technical communication in CS classes. Industry does not reward silent confusion. It rewards people who can surface a problem clearly enough for a team to act on it.

A checklist students can actually use

Before you ask for help, check whether your message includes these points:

What are you trying to do?
What language, tool, or platform are you using?
What did you expect to happen?
What actually happened?
What is the exact error message?
What have you already tried?
Can you shrink it to a minimal reproducible example?
Are you asking about the real problem, or just your guessed fix?

If two or three of those are missing, stop and rewrite the question.

That rewrite is not wasted time. It is often the moment the bug becomes obvious.

If you want practice reading error messages before you ask for help, my guide on https://www.techiemike.com/debugging-python-for-a-level-cs-reading-tracebacks-and-finding-bugs/ is a good place to start. If you need a more structured approach to catching problems earlier, I also wrote about https://www.techiemike.com/how-to-set-up-a-test-pipeline-that-actually-catches-bugs/. And if you keep losing useful debugging context across chats and tabs, https://www.techiemike.com/the-chat-graveyard-how-to-export-search-and-learn-from-your-ai-conversations/ is worth bookmarking.

The habit that saves the most time

The strongest students I teach are not always the fastest coders.

They are usually the ones who stop, gather the evidence, and explain the bug properly.

That sounds almost too simple, but it changes everything. Better questions lead to better answers. Better answers lead to faster debugging. Faster debugging leaves more time for the work that actually matters.

So the next time your instinct is to type, "It doesn't work," do one more pass.

State the task. Show the evidence. Explain what you tried. Ask the real question.

That is not just asking for help.

That is technical communication, and it is one of the most practical skills a CS student can build.

Linux Pipes and Redirection: The Missing CS Lesson That Powers Real-World Automation

Mike — Wed, 08 Jul 2026 02:01:16 +0000

Linux Pipes and Redirection: The Missing CS Lesson That Powers Real-World Automation

A few weeks ago I was debugging why one of my Docker containers kept crashing. The logs were enormous — thousands of lines. I needed to find error messages, count how often they appeared, and figure out which service was the culprit, preferably sorted by frequency. What would have been 15 minutes of scrolling became this:

docker logs my-app 2&gt;&amp;1 | grep -i error | cut -d' ' -f3- | sort | uniq -c | sort -rn | head -10

One line. Seven commands chained together. The result was on my screen in under a second.

If you're running Docker, understanding how containers actually work makes these pipelines more powerful — the same Linux primitives that power containers also power everything covered here.

I teach Cambridge IGCSE and A-Level Computer Science. Chapter 4 of the IGCSE syllabus covers operating systems, including their role in providing an interface between users and hardware. The syllabus mentions that OSes provide an interface — in my classroom, we expand that into the CLI vs. GUI distinction. What students don't learn is how — the mechanism that makes the CLI more than a slower, uglier version of a GUI.

That mechanism is pipes and redirection. It's the thing that transforms a terminal from a historical curiosity into an automation engine. And it's missing from every CS syllabus I've taught.

File Descriptors: The Invisible Plumbing

Before pipes make sense, you need to understand where a command's output actually goes.

Every normal process started from a shell usually begins with three standard streams open:

FD	Name	Purpose
0	stdin	Input — what the process reads
1	stdout	Output — normal results
2	stderr	Error output — diagnostic messages

When you run ls, the list of files goes to stdout (FD 1). If ls can't find a directory, the error message goes to stderr (FD 2). Both land in your terminal by default, but they're separate streams.

This distinction matters. Without it, you couldn't separate errors from results. You couldn't log errors while processing output. Every automation trick in the rest of this post depends on understanding that stdout and stderr are two different pipes.

The numbers are not arbitrary. They're hardcoded in the POSIX standard — every Unix-like system since the 1970s uses 0, 1, and 2 for these three streams. On Linux, you can see them yourself:

ls -l /proc/$$/fd

That shows the file descriptors for your current shell process. You'll typically see something like 0 -> /dev/pts/0, 1 -> /dev/pts/0, 2 -> /dev/pts/0 — each pointing at your terminal device. This is why output and errors both appear on screen: they're sent to the same place.

The Pipe: One Command's Output, Another Command's Input

The pipe is usually credited to Douglas McIlroy at Bell Labs, who proposed the idea in a 1964 memo. Ken Thompson implemented it in 1973 — "in one feverish night," McIlroy later wrote — adding the pipe() system call and the | syntax to Unix. The next day, McIlroy recalled, "saw an unforgettable orgy of one-liners as everybody joined in the excitement of plumbing."

The pipe operator | takes stdout from the left command and feeds it to stdin of the right command. No intermediate file. No extra temporary file on disk. Just a kernel buffer connecting two processes.

# Without pipes: two steps, a temp file
ls -l &gt; /tmp/files.txt
wc -l &lt; /tmp/files.txt
rm /tmp/files.txt

# With pipes: one step, no cleanup
ls -l | wc -l

Pipes chain. The output of wc -l can feed into another pipe, and another. There's no practical limit on a modern system — I've used chains of 12+ commands in log analysis scripts and they run just fine. Each stage in a pipeline runs as a separate process; shell built-ins in a pipeline often run in a subshell environment, so very long chains do create process overhead, but for the kind of automation you're doing in a terminal or script, you won't hit it.

A pipe only carries stdout. Stderr still goes to your terminal. This is a feature — you can see error messages while data flows silently through the pipeline.

Redirection: The Six Operators

Redirection sends output to files instead of the terminal, or reads input from files instead of the keyboard. Six operators cover everything you'll need.

`>` — Write stdout to a file (overwrite)

echo "server online" &gt; status.txt

Creates the file if it doesn't exist. Overwrites it if it does. Use set -o noclobber (or set -C) in your shell to prevent accidental overwrites — then >| forces overwrite when you mean it.

`>>` — Append stdout to a file

echo "backup completed at $(date)" &gt;&gt; backup.log

Adds to the end. Doesn't touch existing content. This is the one you want for log files.

`<` — Read stdin from a file

wc -l &lt; access.log

The command reads the file as its stdin. Not the same as passing a filename as an argument — wc -l access.log prints the filename alongside the count; wc -l < access.log only prints the number. This matters in pipelines where you want clean data, not filenames mixed in.

`2>` — Write stderr to a file

find / -name "*.conf" 2&gt; errors.txt

Only stderr goes to the file. Stdout still appears on your terminal. This is how you collect errors without losing your results.

`2>&1` — Merge stderr into stdout

docker logs my-app 2&gt;&amp;1 | grep error

Read right to left: redirect FD 2 (stderr) to wherever FD 1 (stdout) is pointing. After this, both streams go to the same place. The order matters. 2>&1 > file does NOT do what you think — it redirects stderr to whatever stdout was pointing at when that operator was evaluated (your terminal), then redirects stdout to the file. You want > file 2>&1 — redirect stdout first, then point stderr at the same destination. I still get this wrong sometimes and have to test it.

`&>` — Redirect both stdout and stderr to a file (Bash shorthand)

make all &amp;&gt; build.log

Equivalent to > build.log 2>&1. Cleaner to type. Works in Bash and Zsh but not in plain /bin/sh — if you're writing scripts for maximum portability, use the long form. In practice, most of us are in Bash anyway.

tee: Capturing Mid-Stream

Sometimes you want to see output on screen AND write it to a file. That's tee — named after the T-junction in plumbing.

./long-script.sh | tee output.log

The script's output appears in your terminal and gets written to output.log simultaneously. If you want to append instead of overwrite: tee -a.

Where tee really earns its place is in pipelines with sudo:

echo "new config line" | sudo tee /etc/app/config.conf &gt; /dev/null

sudo echo > file doesn't work because the redirection happens in your shell, before sudo runs. tee runs with elevated privileges and writes the file itself. This is one of those patterns you use once and then keep in your back pocket forever.

xargs: When Pipes Aren't Enough

A pipe feeds stdin. Not all commands read from stdin — many expect arguments. rm, mkdir, mv, cp, docker stop — they take filenames or IDs as arguments, not on stdin.

That's where xargs bridges the gap. It reads stdin and turns each line into an argument for another command.

# Find all .log files and delete them
find . -name "*.log" -print0 | xargs -0r rm

# Stop all Docker containers whose image name contains 'old-'
docker ps --format '{{.ID}} {{.Image}}' | grep 'old-' | awk '{print $1}' | xargs -r docker stop

Without xargs, you'd need a while read loop. With it, you get the same result in one clean pipeline.

If filenames or arguments contain spaces, use xargs -0 with null-delimited input:

find . -name "*.log" -print0 | xargs -0 rm

The -print0 and -0 flags use the null character as a delimiter instead of newlines. Spaces in filenames won't break your pipeline. I learned this the hard way after deleting the wrong file in 2024 — now -print0 | xargs -0 is muscle memory.

Process Substitution: When Two Inputs Collide

diff compares two files. But what if you want to compare the output of two commands — say, ls from two different directories?

diff &lt;(ls /dir1) &lt;(ls /dir2)

<(command) runs the command in a subshell and presents its output as if it were a file. On many Linux systems, the <(...) gets replaced with a path like /dev/fd/63, which diff reads like any other file. Both commands in the example run in separate subshells, simultaneously.

The reverse also works. >(command) lets you send output to a command as if it were a file:

tar czf &gt;(ssh user@remote "cat &gt; backup.tgz") /home/mike/docs

This creates a tar archive and pipes it over SSH — no temporary file on disk. Not something you use daily, but when you need it, nothing else does the job.

Why This Isn't in the CS Syllabus (And Why It Should Be)

In my IGCSE classroom, we go beyond the syllabus — which covers OS interfaces in broad terms — to teach the CLI vs. GUI distinction. Students learn that a CLI exists. They learn it's faster for automation and preferred by technical users.

What they don't learn is the mechanism. Classroom coverage stays at the what — command line interfaces let you type commands — but stops short of the how: the Unix philosophy of small, composable programs connected by pipes.

This matters because pipes and redirection aren't just terminal tricks. They're the embodiment of a design principle that shows up everywhere in computing: composition over monoliths. Microservices pass data through APIs. React components pass props. CI/CD pipelines chain build steps. The pipe operator from 1973 is the same idea, at the operating system level.

When a student understands pipes, they understand why grep, sort, wc, and head are separate programs instead of one giant "log-analyser." Each does one thing. Pipes let you combine them into whatever tool you need, on the fly. No configuration file. No GUI. Just composable building blocks.

Real Automation: What This Actually Looks Like

Theory is fine. Here's what pipes look like in my daily work running a homelab — the same patterns I use across the services running on my Proxmox mini PC.

Finding what's eating disk space:

du -sh /* 2&gt;/dev/null | sort -rh | head -5

Checking Docker container health at a glance:

docker ps --format '{{.Names}} {{.Status}}' | grep -v 'Up' | tee /tmp/unhealthy.txt

Extracting unique IPs from an nginx access log:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Monitoring memory usage across services:

ps -eo pmem,comm --sort=-pmem | head -10

Each of these is a sentence. Subject, verb, object. The pipe is the verb — it connects, filters, sorts. Once you think in pipes, you stop reaching for Python scripts for one-off tasks. The terminal becomes fast enough that the answer is already on your screen by the time you'd have opened an editor.

The Unix Philosophy, in One Keystroke

McIlroy's 1964 memo described a system where programs would be "coupl[ed]... like garden hose — screw in another segment when it becomes necessary to massage data in another way." He was describing the pipe, but he was also describing an approach to software that's outlasted every GUI framework and programming paradigm that's come along since.

The next time you chain five commands with | and get an answer in seconds, you're not just being efficient. You're using a design pattern from 1973 that modern distributed systems are still rediscovering.

And if you're a CS student who just learned what a CLI is, know this: the CLI itself isn't what makes the terminal powerful. It's the pipes. It was always the pipes.

Homelab Network Design: Building Your Own Miniature Data Centre at Home

Mike — Tue, 07 Jul 2026 02:01:14 +0000

Homelab Network Design: Building Your Own Miniature Data Centre at Home

My homelab started flat. One subnet. Every device — the Proxmox host, the Docker containers, the media server, the WiFi light bulbs — all splashing around in the same 192.168.1.0/24 pool. It worked. Until it didn't.

The moment things shifted was when I stood up a second physical node. I had the BMAX Pro 8 running Proxmox as my main workhorse, and the CHUWI MiniBook X joined the rack as a secondary compute node. Suddenly I had services that needed to talk to each other across machines, services that should never see each other, and a growing list of Docker networks that had no business being on the same broadcast domain as my workstation.

Flat networks are the path of least resistance. And for a homelab running a single project, they're the correct design. Don't over-engineer before you need to. But once you cross the threshold with multiple physical nodes, tenant-like isolation between services, or anything internet-facing sharing a wire with your NAS, the flat design stops being simple and starts being a liability.

This is the network design I landed on — why each decision matters, and the configs that hold it together.

The Flat Network Trap

Before the refactor, my layout looked like this:

ISP router (192.168.1.1)
  └── unmanaged switch
        ├── BMAX Pro 8 (Proxmox host, 192.168.1.50)
        │     ├── Docker containers (bridge network, 172.17.0.0/16)
        │     └── VMs (bridged, all on 192.168.1.0/24)
        ├── CHUWI MiniBook X (secondary, 192.168.1.51)
        ├── NAS (192.168.1.30)
        └── Workstation (192.168.1.10)

Everything reachable from everything. Docker containers on the default bridge network. VMs bridged directly to the LAN. Broadcast traffic and service discovery noise had nowhere else to go.

That design can't answer three questions:

How do you write different firewall rules for Home Assistant and Jellyfin when they share an IP range?
If someone compromises a container, what stops them from scanning every device on your LAN?
When something is saturating the network, which service is it?

The operational tell is the last one. When "what's chatty on the wire right now?" becomes a question you can't answer from a switchport counter, the design has outgrown its problem.

Enterprise networks solved this decades ago with segmentation. The same patterns scale down.

Think Miniature Data Centre, Not Home Network

Commercial data centres isolate workloads into dedicated network segments. Each gets its own VLAN, its own subnet, its own firewall posture, its own blast radius. When something goes wrong in one segment, the fault is bounded. When a service needs a different security posture, it gets one without dragging the rest of the rack along.

That's the model. Scaled down to a homelab, it looks like this:

Every project gets:

Its own VLAN
Its own subnet
Explicit firewall rules at the routing boundary
No default trust with any other VLAN

The hypervisor stays on a management network. Workloads live on their own segments. Ops access is explicit. No implicit reachability just because you're on the same switch.

This isn't over-engineering. It's the difference between a network that tolerates growth and one that needs to be torn down and rebuilt every time you add a service.

The Physical Layer

The physical topology constrains the logical design. Here's what's actually plugged in:

My setup:

Device	Role	Interface
BMAX Pro 8 (i7-1260P)	Primary Proxmox host	2× 2.5Gb Ethernet
CHUWI MiniBook X (N150)	Secondary node / portable	1× USB-C Ethernet dongle
TP-Link TL-SG108E	Managed switch (8-port, VLAN-capable)	—
ISP Router	DHCP + internet gateway	1× 1Gb

The key piece is the managed switch. An unmanaged switch cannot create or manage VLAN membership. Some may pass tagged frames through, but they cannot assign access ports, define trunks, or enforce segmentation. If you want network segmentation, you need a switch that understands 802.1Q VLAN tagging. You don't need a Cisco Nexus. An entry-level TP-Link or Netgear managed switch with VLAN support is enough to get started. I use the BMAX Pro 8 for most services and the CHUWI MiniBook X as a secondary Proxmox node for lighter workloads.

The ISP router stays as the internet gateway but does not handle inter-VLAN routing. A router, firewall VM, or L3 switch has to do that job. With an entry-level L2 managed switch like the TL-SG108E, VLANs give you separation, but routing between them still needs something like OPNsense, pfSense, or a router that supports VLAN interfaces.

VLANs and Network Segmentation

The logical layout:

VLAN 1  (Management):  192.168.1.0/24    — Proxmox host, switch management, workstation
VLAN 10 (Services):    10.0.10.0/24      — Docker hosts, web services, reverse proxy
VLAN 20 (Media):       10.0.20.0/24      — Jellyfin, NAS, media-related containers
VLAN 30 (IoT):         10.0.30.0/24      — Home Assistant, ESPHome devices, Zigbee bridge
VLAN 40 (Lab):         10.0.40.0/24      — Throwaway VMs, pen-test targets, experiments

The exact VLAN numbers do not matter — consistency and documentation matter more than copying someone else's numbering scheme.

Three design rules:

The hypervisor stays on management, VMs live on workload VLANs. The Proxmox host isn't a workload. It's the platform. If a workload VLAN's routing breaks, you still need console access to the host for recovery. Keeping it on the management VLAN means backups continue, snapshots run, and you can SSH in regardless of what's happening on VLAN 10.

One subnet per function, gateway at the switch or firewall. The routing boundary between VLANs is where policy lives. Every packet crossing from VLAN 10 to VLAN 30 hits the gateway, and that's where you write the rules.

No VLAN trusts another by default. Inter-VLAN traffic is denied. ACLs grant the exceptions. If Jellyfin on VLAN 20 needs to reach the NAS, that's a deliberate permit rule, not a side effect of sharing a broadcast domain.

VLAN Configuration on a Managed Switch

On a TP-Link TL-SG108E (or similar entry-level managed switch):

VLAN ID: 10
Name: Services
Port Members: 1 (tagged), 3 (untagged)

Port 1 is the trunk to the Proxmox host, tagged so it carries multiple VLANs. Port 3 might be a physical device that only speaks untagged traffic.

The switch's 802.1Q config page is where you map VLAN IDs to ports. Tagged ports carry traffic for multiple VLANs (each frame gets a VLAN tag), untagged ports belong to a single VLAN. The Proxmox trunk port should carry every VLAN your VMs need. Tag them all and let Proxmox sort out which VM gets which.

Proxmox Networking

Proxmox bridges are the glue between the physical switch VLANs and your VMs. The config lives in /etc/network/interfaces. If you haven't set up Proxmox yet, start with the Proxmox Homelab Setup on a Mini PC guide first — it covers the base install before you add VLANs.

A VLAN-aware bridge setup:

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.50/24
    gateway 192.168.1.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

bridge-vlan-aware yes is the important flag. Without VLAN awareness, Proxmox will not handle multiple VLAN-tagged guest interfaces cleanly on that bridge. You can still build VLAN setups in other ways, but a VLAN-aware bridge is the cleanest Proxmox approach when one trunk carries several VM VLANs.

When creating a VM, set the network interface VLAN tag to 10, and that VM lands in the Services VLAN. No DHCP server on VLAN 10? Assign a static IP or run a DHCP server inside that VLAN: a container running dnsmasq, or your router if it supports multiple DHCP scopes.

For containers (LXC), the network config in /etc/pve/lxc/.conf:

net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=AA:BB:CC:DD:EE:FF,tag=10,type=veth

The tag=10 puts the container on VLAN 10. Adding firewall=1 enables the Proxmox firewall for that interface, useful as a second layer of filtering before traffic even hits the switch.

The Management Network Rule

Proxmox's web UI and SSH live on the management bridge (VLAN 1, untagged). Never put the management interface on a workload VLAN. If you lose routing to VLAN 10, you don't want to lose access to the host. The management network should stay reachable even when every workload VLAN is on fire.

Docker Networking

Docker adds a third networking layer on top of the physical switch and Proxmox bridges. Containers on the same Docker network can reach each other by service name. Containers on different Docker networks are isolated unless you explicitly connect them.

The default bridge network (docker0, 172.17.0.0/16) is fine for a single-container experiment. For anything that runs multiple services, create dedicated networks. (New to Docker? Learning Docker by Building a Container Engine From Scratch walks through the fundamentals.)

# docker-compose.yml
networks:
  backend:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/24
  frontend:
    driver: bridge
    ipam:
      config:
        - subnet: 172.21.0.0/24

services:
  app:
    networks:
      - backend
      - frontend
  db:
    networks:
      - backend
  proxy:
    networks:
      - frontend

The app container sits on both networks. It can talk to the database on backend and receive traffic from the reverse proxy on frontend. The database is on backend only, with no direct exposure to the proxy network. This is a miniature three-tier web architecture.

How Docker Networks Map to VLANs

Docker networks live inside the Proxmox host. They don't automatically map to physical VLANs. A container on a Docker bridge network can talk to other containers on the same bridge, but it can't reach a VM on VLAN 20 without a route.

For containers that need physical VLAN access, use the macvlan driver:

networks:
  media-vlan:
    driver: macvlan
    driver_opts:
      parent: eth0.20
    ipam:
      config:
        - subnet: 10.0.20.0/24
          gateway: 10.0.20.1

The parent value must match the interface visible inside the Docker host, not necessarily the Proxmox physical NIC. On a Docker VM this might be eth0; on a bare-metal Docker host it might be enp1s0.20; on a Proxmox-hosted setup it depends on whether VLAN tagging is handled by Proxmox, the guest, or a dedicated bridge. The warning that macvlan containers often cannot communicate directly with the Docker host is correct — Docker's macvlan behaviour commonly isolates host/container communication by design.

The trade-off: macvlan containers bypass the host's network stack, so the host itself can't communicate with them on that interface. For most homelab services, stick with bridge networks and use the reverse proxy as the routing layer between Docker and the rest of the network.

# Inspect Docker networks
docker network ls
docker network inspect backend

# See which containers are on which networks
docker inspect --format='{{range $k,$v := .NetworkSettings.Networks}}{{$k}} {{end}}'

For networks that should never reach the internet, Docker's internal: true flag creates an externally isolated network — containers on that network cannot use Docker's normal bridge path to reach external networks. Databases and internal services that only talk to other containers are good candidates.

Reverse Proxy: The Front Door

Every service that needs external access routes through a reverse proxy. I use Caddy because it handles TLS certificates automatically and the config is five lines. nginx and Traefik are equally solid choices.

# Caddyfile
jellyfin.techie.local {
    reverse_proxy 10.0.20.10:8096
}

homeassistant.techie.local {
    reverse_proxy 10.0.30.12:8123
}

portainer.techie.local {
    reverse_proxy 172.20.0.5:9443
}

The reverse proxy sits on the Services VLAN with an interface in the Docker bridge network. From there it reaches Jellyfin on VLAN 20 (via the gateway's inter-VLAN routing), Home Assistant on VLAN 30, and Portainer inside Docker, all through a single TLS-terminated entry point.

Access control happens at the proxy layer. If a service doesn't need internet exposure, don't put it in the Caddyfile. Internal services like databases stay on isolated Docker networks and are reachable only by the containers that need them.

Getting a Let's Encrypt Certificate for Internal Services

Caddy handles this automatically for public domains. For internal-only services (.local or .home.arpa domains), use a DNS challenge with your domain provider's API token:

jellyfin.internal.techie.systems {
    tls {
        dns cloudflare {env.CF_API_TOKEN}
    }
    reverse_proxy 10.0.20.10:8096
}

This gets you a valid certificate for an internal IP without opening port 80 to the internet. The DNS challenge proves you control the domain, and Caddy handles renewal.

Note: the Cloudflare DNS provider is not included in the default Caddy build. Install a Caddy build that includes dns.providers.cloudflare, or build it with xcaddy.

Firewall Rules Between Segments

VLAN segmentation isolates broadcast domains. It doesn't block traffic by default. Two VLANs on the same switch, both trunked to the same Proxmox host, can absolutely talk to each other as soon as there's a route between them. Firewall rules at the routing boundary are what enforce isolation.

On a router or firewall VM (OPNsense, pfSense, or even iptables on the Proxmox host), the rule pattern for a workload VLAN:

# Services VLAN (10.0.10.0/24) rules
allow from 10.0.10.0/24 to 10.0.20.10:8096    # Jellyfin access
allow from 192.168.1.10/32 to 10.0.10.0/24    # Workstation management
block from 10.0.10.0/24 to 10.0.0.0/8         # Block all other inter-VLAN
allow from 10.0.10.0/24 to any                 # Internet outbound

Rule order matters. The default deny catches everything not explicitly permitted. Internet outbound is the last rule. Everything else is inter-VLAN and gets evaluated first.

For Docker containers with iptables:

# Allow a container to reach Jellyfin on the Media VLAN
iptables -A DOCKER-USER -s 172.20.0.5 -d 10.0.20.10 -p tcp --dport 8096 -j ACCEPT

# Block that container from reaching anything else
iptables -A DOCKER-USER -s 172.20.0.5 -j DROP

The DOCKER-USER chain is the right place for custom Docker firewall rules. Docker inserts its own rules in the DOCKER chain, and DOCKER-USER is evaluated first.

Be careful with broad DROP rules in DOCKER-USER. Add required DNS, gateway, update-server, and established-connection rules first, or you may cut the container off from more than intended.

Commands That Actually Tell You What's Happening

Theory is fine. These are the commands I run when I'm debugging the network:

# What networks exist on this Docker host?
docker network ls

# Which containers are on which network?
docker network inspect backend | jq '.[].Containers | to_entries[] | {name: .value.Name, ip: .value.IPv4Address}'

# What routes does this machine have?
ip route show

# Which VLAN-tagged interfaces exist?
ip -d link show | grep -i vlan

# What's listening on which ports?
ss -tlnp

# Trace the route a packet takes to a service
traceroute 10.0.20.10

# Is the firewall blocking this?
iptables -L DOCKER-USER -n -v

The docker network inspect command is the one I reach for most. It shows you exactly which containers are on a network, their IPs, and their MAC addresses. Invaluable when you're trying to figure out why service A can't reach service B.

What I'd Do Differently

I built this incrementally. If I were starting from scratch, I'd do four things differently:

Start with a Managed Switch

I spent months on an unmanaged switch, working around the lack of VLANs with separate physical interfaces and USB Ethernet dongles. A managed switch would have saved me a dozen evenings of network gymnastics.

One VLAN per Function, Not per Project

I initially created a VLAN per application (Jellyfin VLAN, Home Assistant VLAN, etc.). That's too granular for a homelab. Three or four functional VLANs (management, services, media, lab) cover everything without turning your switch config into a part-time job.

Document the IP Scheme Before You Need It

When you're troubleshooting at midnight, a text file with every static IP, VLAN assignment, and port mapping is worth its weight in sleep. I keep mine in Obsidian, but a markdown file in the repo works fine.

Don't VLAN-Tag Your Workstation Port

Tag it wrong and you lose access to the switch management interface. Keep one untagged management port as a recovery path.

The CS Angle — Why This Matters for Students

If you're studying Cambridge IGCSE or A-Level Computer Science, a homelab network is the most practical way to internalise the networking syllabus. Subnetting, network segmentation, and subnetwork models are in the A-Level spec (9618) — and VLANs are how those concepts play out on real hardware. Subnet masks, CIDR notation, the role of routers and switches — it's all there.

But textbooks teach these concepts in isolation. A VLAN is a paragraph. A subnet mask is a slide. A homelab makes them real: you type ip route show, you see the routing table. You configure a VLAN on a switch, you watch tagged frames hit the port. You misconfigure a subnet mask and suddenly two devices can't talk, and you understand why in a way no exam question can replicate.

Even the security concepts click differently. "Defence in depth" is an abstract principle until you're writing iptables rules that block a compromised container from pivoting to your NAS. Then it's not theory anymore. It's your data.

Getting Started — The Quick-Start Template

A minimal setup you can stand up in an afternoon:

Buy a managed switch. TP-Link TL-SG108E or similar entry-level managed switch. 8 ports, VLAN support, web-managed. Plug it in between your ISP router and your Proxmox host.
Create three VLANs on the switch. Management (VLAN 1, untagged), Services (VLAN 10, tagged), Lab (VLAN 40, tagged). Tag the port that connects to your Proxmox host. Before changing anything, make sure you have one untagged management port left as a recovery path.
Enable VLAN-aware bridge on Proxmox. Add bridge-vlan-aware yes to /etc/network/interfaces on your bridge. Assign VM network interfaces to VLAN 10 or 40 with the tag parameter.
Create dedicated Docker networks. Stop using the default bridge. Define backend and frontend networks in your Docker Compose files. Put databases on backend only.
Set up a reverse proxy. Install Caddy or nginx on a VM or container in the Services VLAN. Add proxy entries for the services you want to access externally.

That's the skeleton. Everything else (firewall rules, inter-VLAN routing, macvlan for specific use cases) you add as the homelab grows.

Start flat. But when the flat network stops working (and it will), you'll know which pieces to reach for.

Self-Hosted AI Security: What Every Ollama User Should Know

Mike — Mon, 06 Jul 2026 09:01:12 +0000

Self-Hosted AI Security: What Every Ollama User Should Know

Last week, a researcher publicly disclosed five Ollama and LiteLLM issues after a 90-day responsible disclosure window: two affecting Ollama directly and three affecting LiteLLM.

That is not the same as "instant remote code execution on every homelab Ollama server", but it is still a warning sign. Self-hosted AI tools are now being researched, fingerprinted, and probed like any other internet-facing service.

For most self-hosted AI setups, these are the kind of bugs that sit in the background until someone actually exploits them. And the thing about homelabs is that "someone" doesn't have to be a nation-state. It can be a scanner bot that found port 11434 on Shodan.

I've been running Docker, Ollama, and Open WebUI on my homelab for months. The setup works well: local models, no API bills, no rate limits. But security was an afterthought when I first set it up, and I suspect that's true for most people. I've tightened up my own setup since reading the disclosures, and there are five things every Ollama user should do right now.

What got disclosed

The recent disclosure covered five Ollama and LiteLLM issues:

Ollama GGUF string length panic — a crafted model file could trigger a crash, causing denial of service.
Ollama unbounded vocab_size resource exhaustion — a malicious model could consume excessive CPU or memory.
LiteLLM pass-the-hash authentication bypass — a weakness in authentication handling could allow access under specific conditions.
LiteLLM SSRF through custom guardrails — an attacker could make the server reach internal or unintended services.
LiteLLM Unicode normalization issue — a parsing or sandboxing weakness that could contribute to sandbox escape scenarios.

None of these should be described as "instant remote code execution on every homelab Ollama server". The practical lesson is simpler: if your AI stack is exposed without authentication, every parser bug, model-loading bug, and proxy bug becomes much more dangerous.

Ollama has also had other recent security issues. CVE-2026-5530 (GitHub advisory) is reported as an SSRF flaw in the Model Pull API, and CVE-2026-7482 (CVE.org) is a heap out-of-bounds read in the GGUF model loader that could disclose server process memory. Those are separate from the five-issue Ollama/LiteLLM disclosure, but they reinforce the same point: exposed local AI services are now part of the attack surface.

Why your homelab is exposed

The Ollama service itself is designed as a local API, but Docker port publishing can easily expose it. In Compose, 11434:11434 publishes the container port on all host interfaces, which means LAN access — and possibly internet access if your firewall or router allows it.

If you followed a typical setup guide, you probably have this in your docker-compose.yml:

ollama:
  image: ollama/ollama:latest
  container_name: ollama
  ports:
    - "11434:11434"

That "11434:11434" is the problem. It binds to 0.0.0.0:11434 on the host. Every device on your network can reach your Ollama API. If you've forwarded ports on your router (which most homelab users do for services like Plex or Nextcloud), then anyone on the internet can reach it too.

I checked my own setup while researching this post. I had the Docker Compose configuration from my Ollama guide with 127.0.0.1:11434:11434 (binding to localhost only) in the standalone docker run command, but the Compose version had the default 11434:11434. I'd fixed it in one place and not the other. This is exactly the kind of inconsistency that creates security gaps.

Five things to do today

1. Bind Ollama to localhost

The simplest fix, and the one that eliminates the largest attack surface:

ollama:
  image: ollama/ollama:latest
  container_name: ollama
  ports:
    - "127.0.0.1:11434:11434"

That 127.0.0.1: prefix means Ollama only listens on localhost. Services running on the same machine can still reach it: Open WebUI, n8n, anything that talks to http://ollama:11434 inside the Docker network. But nothing outside the host can touch it.

If you're using the standalone docker run command:

docker run -d \
  --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama_data:/root/.ollama \
  ollama/ollama

Verify it worked:

# Should show 127.0.0.1:11434, not 0.0.0.0:11434
docker port ollama

2. Put a reverse proxy with authentication in front

Binding to localhost is good, but if you want to access Ollama from other devices on your network or remotely, you need a middle layer. A reverse proxy with authentication (Nginx, Caddy, or Traefik) sits between the outside world and Ollama.

The simplest approach: if you already use Cloudflare for your domain (I do for techiemike.com), add Cloudflare Access in front of your Ollama endpoint. It's free for up to 50 users, adds an email-based authentication gate, and you can set it up in about ten minutes. (I wrote about Cloudflare's new self-managed OAuth recently — it's worth reading if you're building anything that talks to the Cloudflare API from your homelab.)

If you want a self-hosted auth solution, Authentik or Authelia work well with Nginx. Here's the Nginx config pattern:

server {
    listen 443 ssl;
    server_name ollama.yourdomain.com;

    location / {
        auth_request /auth;
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
    }

    location = /auth {
        proxy_pass http://127.0.0.1:9091/api/verify;  # Authentik
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
    }
}

Even basic auth (a username and password) is better than an open API endpoint. But Cloudflare Access or Authentik with SSO is the proper solution.

3. Isolate Ollama on its own Docker network

Ollama doesn't need to be on the default bridge network with all your other containers. Put it on a dedicated network so that even if someone compromises it, they can't pivot to your other services:

networks:
  ai_network:
    driver: bridge
    internal: true  # No outbound internet from this network

services:
  ollama:
    networks:
      - ai_network
    # ... rest of config

  open-webui:
    networks:
      - ai_network
      - proxy_network  # Only Open WebUI can reach the reverse proxy

The internal: true flag on the AI network means containers on it can talk to each other but can't reach the internet. Ollama doesn't need internet access after you've pulled your models. If someone exploits an SSRF vulnerability, the network layer stops the request before it leaves the Docker host.

The trade-off: you can't pull new models while the network is internal. When you need to pull a model, temporarily switch internal to false, pull the model, then switch it back. It's a minor inconvenience for a significant security gain.

4. Run Ollama as a non-root user

The official Ollama Docker image runs as root by default. If someone finds a container escape vulnerability, they land as root on your host. Running as a non-root user limits the damage:

ollama:
  image: ollama/ollama:latest
  container_name: ollama
  user: "1000:1000"
  ports:
    - "127.0.0.1:11434:11434"
  volumes:
    - ollama_data:/home/user/.ollama  # Non-root home directory

You'll need to adjust the volume path since the default /root/.ollama won't be writable by user 1000. Ollama supports the OLLAMA_MODELS environment variable for this:

ollama:
  image: ollama/ollama:latest
  container_name: ollama
  user: "1000:1000"
  environment:
    - OLLAMA_MODELS=/home/user/.ollama/models
  ports:
    - "127.0.0.1:11434:11434"
  volumes:
    - ollama_data:/home/user/.ollama

If you're on a single-user homelab where you're the only person with SSH access, the risk of container escape is low. But it costs a few extra lines of config and follows a security principle that every CS student should learn: least privilege. Don't give a process more access than it needs.

5. Monitor API usage and set rate limits

You can't secure what you can't see. Ollama doesn't have built-in access logging beyond stdout, but you can add it at the reverse proxy layer.

With Nginx, add a log format that captures the request body size, user agent, and response time:

log_format ollama_log '$remote_addr - $remote_user [$time_local] '
                      '"$request" $status $body_bytes_sent '
                      '"$http_user_agent" $request_time';

server {
    access_log /var/log/nginx/ollama_access.log ollama_log;
    # ... rest of config
}

Then set up rate limiting. No legitimate user needs to fire hundreds of requests per second at a local model:

limit_req_zone $binary_remote_addr zone=ollama_limit:10m rate=10r/s;

server {
    location / {
        limit_req zone=ollama_limit burst=20 nodelay;
        # ... proxy config
    }
}

For homelab use, 10 requests per second with a burst of 20 is generous. You can tighten it if you're the only user.

What this teaches about security

Every one of these issues follows a pattern that shows up in CS syllabi worldwide. And every one of them was preventable with basic security hygiene.

The SSRF vulnerability exists because the code trusts user input (a URL in a guardrail config) and requests whatever it points to. The Ollama GGUF parsing bugs exist because the code doesn't validate model file headers before processing them. The auth bypass exists because the middleware checks one header but the application logic reads another.

These aren't exotic zero-days. They're the same class of bug that's been appearing in web applications for twenty years. What's new is the context: self-hosted AI tools are being deployed by people who aren't security engineers, in environments that weren't designed for the threat model they're now facing.

If you're a CS student reading this (and a chunk of my readers are), these disclosures are a better education than any textbook. Look up the actual reports on Huntr. Read the patch diffs on the Ollama GitHub. You'll learn more about real-world security from one vulnerability analysis than from a semester of theory.

The bigger picture

Ollama isn't uniquely dangerous. It's the same story we've seen with every self-hosted service: people deploy it, it works, and security gets deferred. I did it myself. My Docker + Ollama setup guide has been one of the most popular posts on this site, and I originally wrote it with the 127.0.0.1 binding in one code block but not the Compose version. I only noticed the gap while researching this post.

The difference with self-hosted AI is the data. Your conversations with a local model might include code from private repos, personal documents you're summarising, or API keys you're debugging. That data lives in your request logs, your model outputs, and potentially in whatever an attacker exfiltrates. It's not just compute you're protecting. It's context.

I wrote recently about why running AI on your own hardware matters: the privacy, the cost, the independence from cloud platforms. All of that is still true. But independence comes with responsibility. When you're the cloud, you're also the security team.

The five steps above take about twenty minutes to implement. They close the most common attack vectors without breaking anything. Do them today, before someone else's scanner bot finds your Ollama instance before you do.

DEV Community: Mike

GitLost: How AI Agents Can Leak Your Code Through a Single GitHub Issue

GitLost: How AI Agents Can Leak Your Code Through a Single GitHub Issue

What GitLost actually showed

The attack is simple because the system is over-trusted

Why this matters even if you do not use GitHub's exact setup

The real mistake: one agent, too many powers

Five changes that reduce this risk fast

1. Scope each agent to one repository whenever possible

2. Split public-writing steps away from private-reading steps

3. Treat issues, pull requests, and comments as untrusted input

4. Use narrower tokens and installation scopes

5. Log the agent's tool calls like you would log an admin session

What GitLost teaches CS students

Authentication is not authorization

Public input can change private outcomes

Security is a property of the whole system

My bottom line on agent workflows

References

Linux Signals Explained — SIGTERM, SIGKILL and Process Control

Linux Signals Explained — SIGTERM, SIGKILL and Process Control

Ctrl+C is SIGINT, not magic

SIGTERM is the polite knock

SIGKILL is the last resort

The signals students meet without realising it

SIGPIPE: why yes | head -5 stops

SIGHUP: why a remote job dies when SSH drops

SIGSTOP and SIGCONT: pausing a process without killing it

Segmentation faults are signals too

The Cambridge connection: signals and interrupt handling

What students should remember

Proxmox VE in Production — What Running It 24/7 for Over a Year Actually Teaches You

Proxmox VE in Production — What Running It 24/7 for Over a Year Actually Teaches You

Production in a homelab still means consequences

Lesson 1: Storage migrations are where confidence goes to die

Lesson 2: Backups do not mature by themselves

Lesson 3: The network is the part you forget until it bites

The practical rules I would write down on day one

What 400 days actually teaches you

The CISA GitHub Leak: What It Should Teach Homelab Owners

The CISA GitHub Leak: Homelab Security Lessons for Self-Hosters

Keep secrets out of repositories

Audit what is actually exposed

Put authentication in front of selected services

Segment the network properly

Add brute-force protection and rate limits

Patch deliberately and on schedule

Start where the risk drops fastest

Homelab Burnout: Sustainable Self-Hosting When the Hobby Starts Feeling Like Work

Homelab Burnout: Sustainable Self-Hosting When the Hobby Starts Feeling Like Work

The homelab burnout escalation trap is real

Automation should remove toil, not create clever new failure modes

Boundaries matter more than enthusiasm

Documentation is what saves you at 2 AM

The economics are not just about money

A quick homelab sustainability audit

My rule now

Six arguing AI agents: what multi-agent debate teaches CS students about AI architecture

Six arguing AI agents: what multi-agent debate teaches CS students about AI architecture

What multi-agent debate actually is

What debate reveals about LLM architecture

The useful lesson is not "AI thinks better in groups"

Why CS students should care

1. It teaches decomposition

2. It teaches evaluation

3. It teaches observability

4. It teaches trade-offs

Three debate frameworks students can try

The two-agent critic loop

The three-agent committee

The evidence-first debate

Where the hype gets ahead of reality

What I would want students to remember

TLS Certificates for Internal Services: HTTPS Inside Your Homelab

TLS Certificates for Internal Services: HTTPS Inside Your Homelab

Where plain HTTP sneaks back in

The three approaches that actually make sense

1. Local CA for quick wins

2. Let's Encrypt with DNS-01 for services under your real domain

3. Private ACME with step-ca when the lab stops being small

SIGPIPE: why `yes | head -5` stops

`>` — Write stdout to a file (overwrite)

`>>` — Append stdout to a file

`<` — Read stdin from a file

`2>` — Write stderr to a file

`2>&1` — Merge stderr into stdout

`&>` — Redirect both stdout and stderr to a file (Bash shorthand)