Caddy and NetBird, Chrome on ARM64, and AI Coding Harnesses

Homelab Highlights for 2026-07-27: self-hosting and homelab notes worth knowing.

[Audio embed placeholder]

The Lead: How to Access Caddy Reverse-Proxied Services Over NetBird Without Exposing Them

A community discussion tackles the challenge of accessing homelab services behind a Caddy reverse proxy via a NetBird VPN, without exposing anything to the public internet. The goal is to use the same domain names seamlessly from both the local network and the VPN.

Why it matters: This solves a common integration puzzle for secure remote access, offering clean solutions using NetBird’s routing or DNS features to maintain a single, secure entry point through Caddy for consistent logging and access control.

Source: service.example.com

The Feed

Google Chrome Arrives on ARM64 Linux, Widevine DRM Included

Google Chrome is now officially available as a native build for ARM64 Linux, including Widevine DRM support. The .deb package is available directly from Google’s repositories.

Why it matters: For homelabs on ARM hardware like Raspberry Pis, this provides a fully-featured browser for remote management or media streaming without compatibility workarounds, offering better performance than emulation.

Source: OMG Ubuntu

Modern email can be built from borrowed parts

A blog post argues for a pragmatic, federated approach to self-hosted email, mixing your own domain and receiving infrastructure with reliable external services for sending and spam filtering.

Why it matters: It outlines a practical path to owning your email identity and data while offloading the hardest parts of deliverability and reputation management to established providers.

Source: Andros.dev

Minecraft Java Edition has raised its recommended system memory to 16 gigabytes ahead of a planned transition to the Vulkan graphics API for better performance and mod support.

Why it matters: For homelabbers hosting game servers, this is a heads-up to check hardware and Java arguments, as modded servers and newer clients will have higher memory demands.

Source: VideoCardz

Should you wash your solar panels?

A year-long personal experiment found that washing solar panels in a relatively clean environment yielded less than a 1% gain in annual output, suggesting the effort often isn’t worth the tiny benefit.

Why it matters: It’s a homelab-style reminder to measure before optimizing, applying empirical testing to decide if an intervention—whether for power or servers—provides meaningful returns.

Source: Incoherency Blog

One Thing to Try

Based on a user’s extensive testing, pairing the Hermes coding harness with the Aphrodite LLM serving system can provide a stable, project-aware AI assistant for medium to large coding projects, especially if you find default setups prone to stalling.

Sources

Transcript

Host A: Welcome to Homelab Highlights, the show that surfaces practical homelab wins and useful self-hosted tools.

Host A: Let’s kick off with some news. OMG Ubuntu is reporting that Google Chrome is now officially available for ARM64 Linux. This is a native build, not emulation, and it includes Widevine DRM support right out of the box. The .deb package is available directly from Google’s repositories, which is a big shift from the workarounds people used to need. For anyone running homelab services on ARM hardware—Raspberry Pis, newer mini PCs—this is genuinely useful. You can now run a fully-featured Chrome browser for remote desktop sessions or web-based management consoles without relying on Chromium or Firefox, which sometimes have compatibility issues with streaming services or web apps that need specific DRM. The native build should also mean better performance and battery life on portable ARM devices compared to emulation layers or older compatibility shims.

Host B: There’s an interesting take on email floating around. A blog post titled ‘Modern email can be built from borrowed parts’ by Andros argues you don’t need a monolithic stack to run your own email anymore. Instead, you piece together services like Fastmail for sending, iCloud for contacts, and your own domain for receiving, using open protocols to tie it all together. He walks through the technical setup using IMAP and SMTP to bridge these services, creating what he calls a ‘federated’ personal email system. It’s a pragmatic approach to self-hosting email—he acknowledges the headaches of reputation management and spam filtering, but shows how you can still own your data and identity by mixing reliable external services with your own infrastructure. The post specifically mentions using a simple Postfix setup on a VPS just for receiving, while offloading the hard parts of sending and spam filtering to established providers that have the reputation and infrastructure to handle it reliably. So you’re not wrestling with deliverability issues or maintaining a pristine IP reputation, but your mail still flows through your domain and your infrastructure handles the inbound side.

Host A: For anyone hosting game servers, Minecraft Java Edition has officially raised its recommended system memory to 16 gigabytes. Videocardz reports this comes ahead of a planned transition to the Vulkan graphics API, aimed at improving performance and mod support. If you’re running a server for friends, you might want to check your Java arguments and allocated RAM. The article notes this is specifically for the Java Edition client recommendations, but server operators should take note since modded servers, especially with newer versions and popular modpacks, have been creeping up in memory requirements for years anyway. The Vulkan shift is interesting because it’s a move away from OpenGL, which should unlock better performance on modern hardware and potentially make the game more friendly to alternative platforms and custom rendering pipelines. For homelabbers running Minecraft servers, this is a heads-up that your current hardware might need a refresh if you’re planning to support newer clients, or you’ll need to be more aggressive with your server-side optimization flags.

Host B: [curious] Finally, there’s a detailed personal experiment on whether you should wash your solar panels. James Stanley ran a year-long test comparing cleaned versus dirty panels and found that, in his relatively clean environment, washing made less than a 1% difference in total annual output. It’s a good reminder to measure before you optimize, whether it’s your power bill or your server’s resource usage. He used a Shelly Plug to monitor the output of individual strings, which is the kind of granular data collection that feels very homelab. The key takeaway was that in areas without heavy pollution or dust, the rain does most of the cleaning for you, and the effort and water cost of manual washing just isn’t worth the tiny gain. What’s interesting is his methodology—he actually isolated specific panels, tracked their output over months, and did the math on water usage and labor time. It’s the kind of empirical approach that applies to a lot of homelab decisions: sometimes the optimization you think you need just isn’t worth the effort once you actually measure it.

Host A: Let’s dive into our tool highlight, which comes straight from a community discussion about a very specific homelab challenge. A user posted looking for advice on how to access their Caddy reverse-proxied services over NetBird without exposing anything to the public internet. Their setup is pretty locked down: a domain managed by Cloudflare pointing to a LAN IP, Caddy as the sole listener on ports 80 and 443, and Docker services that don’t expose any ports to the host at all. The goal was to add NetBird for remote access while keeping everything funneled through Caddy and using the same hostnames, whether they’re on the local network or connected via the VPN. So essentially, they wanted one entry point, one set of hostnames, and one place to manage access control and logging, regardless of where the request originated.

Host B: The core problem was DNS. The domain resolved to a LAN IP, which isn’t reachable when you’re on the NetBird network. The community offered a couple of clean solutions. One approach is to use a NetBird routing peer to advertise your entire LAN subnet over the tunnel. Then, your existing DNS record just works, and traffic routes over the VPN. This method is straightforward if you want all your peers to have full access to your LAN, but it does mean routing all that traffic through your NetBird peer, which could be a consideration for bandwidth or if you have a complex internal network you don’t want fully exposed. The other popular method leverages NetBird’s built-in DNS management. You set up a private DNS zone inside NetBird that resolves your wildcard domain, like *.example.com, to your server’s NetBird IP address—that’s in the 100.64.x.x range. Any peer connected to the network then uses that resolution, hits Caddy on 443, and you’re done. The same hostname works everywhere because Caddy routes based on the Host header, not the IP it arrived on. This is a more surgical approach—only the services behind Caddy are accessible via the VPN, and your internal LAN remains separate unless you explicitly route it.

Host A: [with emphasis] A NetBird employee, vik_ftsky, also pointed to a specific integration tool: a GitHub project called ‘caddy-netbird’. It’s designed to streamline this exact setup, acting as a sidecar for Caddy to handle the NetBird-specific configuration. The tool essentially automates the process of updating Caddy’s configuration or certificates based on NetBird’s dynamic IP assignments, which is super useful because those 100.64.x.x addresses can change if a peer reconnects. A couple of important notes from the discussion: if you go the DNS route, your Caddy TLS certificates need to cover those hostnames, so using a DNS-01 challenge with a Cloudflare plugin is ideal. And you have to make sure Caddy is listening on 0.0.0.0, not just your LAN interface, or it won’t answer requests coming in on the NetBird virtual interface. One user in the thread mentioned they initially had Caddy bound to eth0, and it took them a while to figure out why VPN traffic was being dropped—it’s a classic ‘listen address’ gotcha that’s easy to miss when you’re thinking about network interfaces rather than socket bindings.

Host B: The whole thread is a great example of the community solving a real-world integration puzzle. It’s not just about whether two tools work, but how they work together in a secure, maintainable way. Whether you choose the routing peer method for simplicity or the DNS method for precision, you end up with a single point of entry through Caddy, which means one place for your access logs, security headers, and authentication middleware, whether the request comes from your couch or a coffee shop. And if you’re already running Caddy for your internal services, adding NetBird access is just a matter of DNS configuration and maybe a certificate update—you’re not adding a second reverse proxy or managing separate hostnames. That’s the kind of operational simplicity that makes a homelab actually sustainable.

Host A: For our community highlight, there’s a detailed post on r/AI_Agents from someone who’s been deep in the world of AI-assisted coding. They shared their experience after trying what they describe as ‘a lot’ of AI coding harnesses over the past six months. They listed both agnostic, open-source options like pi.dev CLI, OpenCode, Hermes, and Cline, as well as paid IDE integrations like Cursor, GitHub Copilot, and Blackbox. Their goal was to find a tool that could handle not just small scripts, but medium to large projects, including mobile apps with Flutter and full-stack work with C# and React. So they weren’t looking for a toy tool or something that works great for one-liners—they needed something that could understand project structure and make coherent changes across multiple files and languages.

Host B: [skeptical] What they settled on might surprise some people. They’ve been using Hermes, paired with the DeepSeek V4 Flash model. They note that Hermes often gets a bad rap for coding tasks, but in their hands-on experience, they found it to be ‘noticeably better than most other agnostic harnesses.’ They were specifically looking for something that could handle project-level context, not just file-by-file generation, and Hermes with its project-aware features fit that bill. They mentioned it was particularly good at understanding the structure of a Flutter project and making coherent changes across multiple Dart files. But here’s the crucial caveat: they aren’t running the default Hermes setup. They pair it with another tool called Aphrodite. They said the biggest difference was that the default Hermes would frequently ‘stall out and stop for no clear reason’ on their projects. With the Aphrodite pairing, they report it ‘never stalls—it just works.’ Aphrodite, for those who haven’t come across it, is an open-source, high-throughput serving system for LLMs, and the user’s setup suggests they’re using it to create a more robust inference backend for Hermes to talk to, which apparently solves the stability issues they encountered.

Host A: It’s a great example of a homelabber doing their own rigorous tool testing, moving beyond surface-level opinions to find a combination that actually fits their workflow. They even mentioned using this setup for hobby projects like cloning OpenRouter’s API with LiteLLM and the Elysia framework, which is a pretty technical undertaking. They provided some concrete examples, like Hermes-Aphrodite successfully generating the necessary configuration files and route handlers for the API clone, where other tools would get confused by the interdependencies or the specific structure of the Elysia project. The post is very clear that this is their personal experience—they’re not declaring Hermes the universal winner. They noted that for someone who lives entirely in VS Code, Cursor might be a better integrated experience, and Copilot is still the king of inline completions. But for their use case, which involved hopping between different projects and languages, an agnostic harness that they could run locally and point at any directory was the priority. The key takeaway is the value of the ‘harness plus backend’ combination; sometimes the out-of-the-box setup isn’t optimal, and a bit of extra integration work, the kind homelabbers are good at, can unlock significantly better performance and stability.

Host B: [conversational] Here’s a quick, practical tip pulled from today’s discussions. If you’re setting up a service behind a reverse proxy like Caddy or Traefik in Docker, consider not exposing the container’s port to the host at all. Instead, let the reverse proxy container reach the app container directly over the Docker network using the container name as the hostname. It’s one less port mapped, one less potential entry point, and it forces all traffic through your proxy for consistent logging and security rules. For example, in your Caddyfile, you’d point to http://app-container-name:3000 instead of http://localhost:8080. This pattern keeps your host’s network namespace clean and is a more container-native way to wire things together. You get better visibility into what’s actually exposed, simpler firewall rules, and a clearer mental model of your traffic flow. It’s a small shift in thinking, but it pays dividends as your homelab grows. Happy hosting!

Host A: That’s Homelab Highlights for Monday. Until next time, happy hosting!