One of the challenges I think that most of us have is simply keeping track of everything. It's easy to spin up a new VM, add another mini PC, connect an IoT device, or build out another VLAN. Before long you're wondering where that random IP address came from or what server is actually running a particular service. I have been there MANY times.

LAN Orangutan looks like it aims to solve that problem. Instead of just running a one-time network scan, it provides a lightweight inventory of your network with a clean web interface where discovered devices are stored and organized over time. It uses Nmap for discovery. So it definitely comes from good "stock" with its architecture for scanning.

Some of the features that caught my eye with this project includes:

• Automatic network discovery
• Multi-network scanning
• Device inventory with persistent records
• Device labels and notes
• Tailscale support
• Modern web dashboard
• CLI with JSON output
• Cross-platform support for Linux, Windows, and macOS
• Single binary deployment

The Tailscale support is especially interesting. I know quite a few of us have multiple home labs or remote sites connected with Tailscale. So this is super interesting being able to inventory devices across those networks.

I also like that the project doesn't appear to be trying to become an all-in-one monitoring platform. There are already plenty of tools in this space that can collect metrics, monitor uptime, or manage enterprise devices. LAN Orangutan is instead laser focused on that simple question of finding out "what devices are on my network?"

According to the roadmap, the developers are also planning features like scheduled scans, notifications, historical tracking, and an API, which could make it even more useful for automation and keeping home lab documentation up to date.

I'm curious how it compares with some of the other tools many of us already use, such as:

• NetBox
• NetAlertX
• LibreNMS
• Uptime Kuma
• Smokeping
• ArpWatch

LAN Orangutan looks like it could fill a nice niche as a lightweight discovery and inventory tool without bringing along a lot of additional complexity.

I'm planning to spin this up in my own lab and see how it performs across multiple VLANs and remote networks. If it works as well as it looks, I could see it becoming another useful utility to keep around alongside the rest of the home lab toolbox.

Check out the project on Github here: 291-Group/LAN-Orangutan: LAN Orangutan is a lightweight network scanner with persistent device labeling, multi-network support, and Tailscale integration. Built by 291 Group.

Has anyone here already tried it? I'd be interested to hear how well it performs and if

you've found any features that really stand out.

MINISFORUM MS-03 Workstation | Intel Core Ultra 9 386H | Fluent 35B Local LLMS – Minisforum

As most of you already know, I am currently running multiple MS-01 systems in my Proxmox cluster, and they've honestly been some of the best home lab purchases I've made. They've been rock solid, quiet, and incredibly capable for their size and have served me well now for 3 years or so (I had two original ones and bought 3 more for my Proxmox cluster). So, building on my good experiences with the MS-01, the MS-03 is very interesting.

From what I've been reading, this isn't just a CPU

refresh.

Some of the specs that stand out to me are the following:

• Intel Core Ultra 300 (Panther Lake) processor
• Support for up to 128 GB of DDR5-7200 memory
• Three M.2 NVMe slots
• PCIe x16 slot that can take a low profile GPU
• Dual USB4 ports
• 2x 10Gb SFP+ ports
• 1x 10Gb RJ45 port
• 1x 2.5Gb RJ45 port

That networking configuration is pretty crazy for a system this size. So if you are counting, that is (1) more 10 GbE connection than the MS-01 has. It has the (2) 10 gig SFP+ cages and then (2) 2.5 GbE ports. One of the things I already love about the MS-01 is not having to add external adapters just to get fast networking in the lab. So, it is great to see the MS-03 keeping with that strength and even adding to it. 

The support for a low profile PCIe GPU is still an option with the MS-03 as it has been with the MS-01. From everything I've read, it supports cards up to 75W, which opens up some interesting possibilities. Whether that's adding a small NVIDIA card for local LLMs, extra media transcoding, or just having GPU resources available inside a Proxmox host, it's nice to have the option.

I'm also glad to see support for 128 GB of RAM (althought who can afford that right now? LOL). Home lab workloads have a way of growing over time, and I don't know many people who have ever said, "I wish I had less memory." But, again, in all seriousness, this is going to be a hard number to max out in today's market.

One interesting design choice is the processor itself. Instead of going with the Panther Lake SKU that has the largest integrated GPU, Minisforum appears to have chosen the version that leaves enough PCIe lanes available for the expansion slot. Personally, for us in the home lab crowd, I think that's the right decision for a workstation or virtualization platform. I'd much rather have expansion options than a faster integrated GPU.

I'm really curious to see a teardown once these start shipping. I'm wondering things like:

• How well does it cool under sustained load? There were some cooling problems noted with the MS-A2.
• Is the fan noise similar to the MS-01?
• Are there any compromises with the PCIe slot when all three NVMe drives are populated?
• Does Proxmox detect everything cleanly out of the box?
• How much power does it draw when it's sitting idle? Power consumption is also a big characteristic for running a system 24x7x365.

At this point I don't think Minisforum has announced pricing yet, so that's probably going to be one of the biggest questions with the unit. If they can keep it somewhere in the same ballpark as the MS-01, which will be hard to say if that is possible in today's market, I think these are going to end up in a lot of home labs.

I'm definitely going to be keeping an eye on this one. Is anyone else thinking about replacing an MS-01 with one of these, or would this be your first Minisforum system? I'd be interested to hear what you would use it for.

For years, if you wanted redundant Pi-hole instances you had a few different options, which have amounted to the following

• Point clients at two different Pi-hole servers and hope devices actually fail over correctly
• Use Gravity Sync (Pi-Hole v5) or Nebula Sync (Pi-Hole v6) to keep configurations synced
• Build your own keepalived or VRRP solution for a floating virtual IP
• Write custom scripts to enable and disable DHCP when a primary server failed

It worked, but it always felt like you were stitching together several different projects to accomplish this and I think that is why so many have been interested in Technitium lately.

This new project, Pi-hole HA, looks like a great project that might be able to solve this issue a little more elegantly it looks like.

Some of the highlights include:

• Automatic configuration sync between Pi-hole nodes
• Optional DHCP failover
• Virtual IP (VIP) support so clients can continue using a single DNS address
• Health monitoring between cluster members
• Native management page directly inside the Pi-hole web interface
• Works for both DHCP users and DNS-only deployments, automatically detecting which mode you're running during installation

What really caught my attention is that this doesn't appear to rely on SSH keys or external utilities you are running somewhere. The nodes communicate over HTTP and the project uses supported Pi-hole interfaces rather than patching Pi-hole itself. According to the author, everything is contained in a fairly clean installation with an uninstall option if you decide to remove it later.

As someone who has written quite a bit about home lab DNS redundancy, this feels like a much better solution even than the traditional Gravity Sync plus keepalived setup many of us have been using.

I also like that it supports a DNS-only mode. Many of us let our routers or firewalls handle DHCP and simply want redundant DNS with synchronized blocklists and settings. The installer apparently recognizes that config setup and doesn't try to take over DHCP automatically.

I haven't had a chance to deploy this in my lab yet, but it is definitely on my list to test. If it proves to be a reliable way to configure this over time, I could see this becoming the preferred way to build highly available Pi-hole deployments in home labs.

Has anyone here already installed it? I'm especially curious about:

• How reliable the failover has been
• Whether the VIP transitions are seamless
• How well it behaves on Docker deployments
• Any issues you've run into during upgrades

For anyone interested, here's the original announcement and documentation:

https://discourse.pi-hole.net/t/release-pi-hole-ha-automatic-dhcp-failover-vip-and-config-sync-for-a-pi-hole-cluster/86667

There is also a pretty good Reddit thread where the author looks to be very responsive: Made a tool for automatic DHCP failover + config sync across multiple Pi-holes (bare-metal or Docker) : r/pihole

I'm looking forward to hearing if anyone has seen this and tested it as of yet? This looks like it could simplify one of the more common "DIY" pieces of home lab infrastructure around DNS if ones are looking to run Pi-Hole.

Initially it’s pretty simple, but once you start stacking multiple services, things slowly shift. It’s not just about getting stuff running anymore, you start thinking more about how everything fits together, how services interact, and how to keep things from becoming messy.

I’ve also noticed that even small business-type applications start feeling very different when they’re running in a virtualized setup instead of just a single machine. It kind of forces you to think in a more structured way.

I’ve seen a few setups where people try to simulate small internal business environments in their labs just to test how different workflows behave under different conditions. Things like HR flows, reporting, and basic automation usually come up in that kind of setup.

I came across Vertex-HCM in that context as well, more like an example of something that fits into that kind of workflow-based system rather than a standalone app.

I’m just curious how others are handling this. Do you usually keep things separated in different VMs, or do you just group services together and manage isolation another way?

What’s been more stable in your experience?

The thing is, most mini PCs with dedicated GPUs seem to come from brands like Minisforum, Geekom, and Beelink, but they add a lot of cost and power consumption. On the other hand, newer iGPUs have gotten a lot better. I'm curious whether the performance trade-off is worth the savings, especially for someone just starting out with self-hosting.

Here's what I'm wondering: Have you found that a dedicated GPU actually makes a difference for home lab workloads, or does integrated graphics handle most virtualization and containerization tasks just fine?

I'd love to hear if anyone has real-world experience or suggestions on this setup, especially if you've tried both. What about power efficiency? does a GPU-equipped mini PC draw a lot more power during idle or light loads? And if you're running local LLMs, what hardware did you settle on and why?

Also, I'm curious if anyone has experience with upgrading RAM and NVMe storage on these compact little pcs. That seems like a smarter investment than GPU power for my use case, but I want to make sure I'm not missing something important. Share your thoughts and help me make the best decision i can...

Download the VMware OVA

Download the VMware OVA from Flatcar:

https://www.flatcar.org/releases/

Choose the VMware/vSphere OVA image.

Create your Butane configuration

Create your normal Butane configuration file (example here):

variant: flatcar
version: 1.0.0

passwd:
  users:
    - name: linuxadmin
      groups:
        - sudo

Save it as:

flatcar.bu

Convert Butane to Ignition

Generate the Ignition JSON:

butane --pretty --strict flatcar.bu > flatcar.ign

Verify the file starts with JSON:

head flatcar.ign

You should see something similar to:

{
  "ignition": {
    "version": "3.3.0"
  }
}

Base64 encode the Ignition file

Encode the generated Ignition file:

base64 -w0 flatcar.ign > flatcar.ign.b64

View the contents:

cat flatcar.ign.b64

Copy the entire output.

Deploy the OVA

Deploy the Flatcar OVA in vSphere.

You can either populate the Ignition fields during deployment or add the values later as Advanced Parameters before the VM is ever powered on. But populating values manually during the OVA install is tedious and doesn't scale very well. You can leave the following screen blank during the deployment:

Configure Ignition using Advanced Parameters

This is the part that you want to pay attention to the details. You need to create the following two advanced configuration parameters:

guestinfo.ignition.config.data
guestinfo.ignition.config.data.encoding 

With the VM powered off:

VM Settings > VM Options > Advanced Parameters

Add:

Both parameters are needed. If you forget to add the base64 advanced setting for the encoding value, you will see errors when it tries to load the config, like this:

Without the encoding parameter, Flatcar will attempt to parse the base64 string as JSON and fail with errors similar to:

error at line 1 col 2: invalid character 'e'

VMware network interface naming

One difference I found out between Proxmox and VMware is interface naming.

In my environment VMware name the NIC as:

ens192

Make sure of the the interface name before building static network configuration.

Example:

Name=ens192


Address=10.1.149.20/24
Gateway=10.1.149.1
DNS=10.1.149.10
Domains=cloud.local

Be careful with Ignition file downloads

My Ignition file contained:

contents:
  source: https://extensions.flatcar.org/extensions/docker-compose.conf

and similar remote downloads.

These worked in my Proxmox deployment but failed during VMware deployment because Ignition attempted to fetch them before networking and DNS were fully available.

The symptom looked like:

lookup extensions.flatcar.org on :53

If you encounter this, deploy without the remote contents.source entries first and move those downloads to a systemd service that runs after:

network-online.target

Verify Ignition

After booting:

journalctl -u ignition-fetch-offline.service -b

or

journalctl -b | grep -i ignition

Successful processing should show:

using OVF environment from guestinfo
config successfully fetched

Hopefully, this forum post will help any who might be looking for information on how to deploy Flatcar in VMware vSphere. It is definitely doable but the process differs quite a bit from Proxmox.

I'm curious about the pain points you're facing in your home lab infrastructure. I am wondering if others are struggling with the following things that I have seen as possible challenges for me:

• VLAN segmentation and inter-VLAN routin
• DNS/DHCP management across multiple subnets
• connectivity decisions (10GbE vs 25GbE vs staying with 1GbE)
• Firewall rules
• WiFi coverage and performance tuning
• Network monitoring and visibility tools
• Balancing performance with power consumption

One thing I've learned is that home labs are pretty customized to each person and what they are doing. While someone else needs enterprise-grade features others may not. The design choices we make often come down to each specific use case. Man, budgets are also a common worry as well especially these days.

I'd love to hear about your setup, the design decisions that worked well, and what you might want to wait and do differently if you started today? Did you go with managed switches for better control, or stick with simpler unmanaged solutions? Are you using WireGuard for remote access, or did you choose a different VPN approach? 

Sorry for all the questions, but just wanted to put this out there for the community to weigh in on.

A few of the highlights in the 9.1:

• Based on Debian 13.5

• Linux kernel 7.0

• SpamAssassin 4.0.2

• ClamAV 1.4.4

• PostgreSQL 17

• ZFS 2.4

• Improved spam quarantine management

• Encrypted backup support

This doesn't look like a huge feature release to me, but seems like a solid platform update that keeps the underlying components current with a few quality-of-life improvements.

The spam quarantine enhancements are probably the feature that will be most noticeable to day-to-day users and administrators. Anything that makes reviewing and releasing quarantined messages easier is probably a good change. It looks like it also adds encrypted backups which is nice to see, especially for orgs that need more protection for configuration and messaging-related data.

One thing I've always found interesting is that Proxmox Mail Gateway doesn't seem to get nearly as much attention as Proxmox VE. Even though I think it is a really mature product that has been around for quite a while. Most of the discussion in the home lab and self-hosting communities naturally centers around virtualization, containers, and storage, but email security is still critical service for many organizations.

For anyone already running PMG, this looks like a worthwhile update. Is anyone here currently running Proxmox Mail Gateway in production or in a home lab? If so, what mail platform are you protecting with it, and how has your experience been compared to solutions like Mimecast, Proofpoint, Barracuda, or Microsoft Defender for Office 365?

Today, many of us running containers on Windows use tools such as Docker Desktop, Podman Desktop, or Rancher Desktop. Microsoft is now building container functionality directly into WSL with a new command-line utility called wslc.exe.

According to Microsoft, WSL Containers will provide:

• Native Linux container support in Windows
• A new wslc.exe CLI for building and running containers
• An API that allows Windows applications to launch and interact with Linux containers
• Enterprise policy for image sources and management
• Support for AI, development, testing, and containerized workloads directly through WSL

What caught my attention is that Microsoft says the command syntax is intentionally familiar to the well known Docker commands we know:

wslc run -it --rm -d -p 8080:80 --name web nginx

looks very similar to:

docker run -it --rm -d -p 8080:80 --name web nginx

The goal seems to be helping to get rid of the dependency on third-party container runtimes while making Linux containers feel like a native Windows capability. Behind the scenes, Microsoft is using a lightweight Hyper-V utility VM that is managed directly by WSL rather than requiring a separate Docker Desktop stack.

As a home labber, I think this is interesting for a few reasons:

• Easier container setup on Windows machines
• Potentially less overhead than running Docker Desktop (which we all know can be tempermental)
• Better integration between Windows and Linux workloads
• Simpler development environments for people who already use WSL
• Another reason to keep Windows as a viable development workstation instead of dual-booting Linux

Microsoft also announced several other developer-focused improvements that included news of native Linux Coreutils support on Windows and a new Intelligent Terminal experience, but WSL Containers was the standout announcement for me.

The feature is still in development and expected to arrive in public preview through a future WSL update.

What do you think?

If WSL Containers delivers good performance and compatibility, would you replace Docker Desktop on your Windows systems, or do you prefer sticking with traditional Docker and Linux VMs?

Here's what I'm weighing on purchasing. Either a Minisforum, Beelink, or Geekom mini PC with a Ryzen 7 or high-end Intel processor. I want something that could handle Proxmox, Docker, and Kubernetes for self-hosting projects. I'm wondering about practical limitations. Has anyone pushed a mini PC to its limits with heavy virtualization? Are there thermal throttling issues when running sustained workloads? How does NVMe storage expansion work on these devices, and is it truly user-friendly?

I'm also curious about the GPU angle. Some of these mini PCs support external GPUs or have integrated graphics capable enough for local LLM inference. Are any of you running AI workloads or experimenting with local language models on mini PC hardware? What's your experience been with stability and performance?

The other consideration is memory upgrades. Most mini PCs max out at 32GB or 64GB depending on the model. Is that enough for a serious home lab setup, or are you finding yourselves limited? What's your sweet spot for RAM when running multiple services?