A Raspberry Pi Zero makes a surprisingly good home lab subnet router

Every home lab eventually collides with the same wall: you want to reach your machines from outside, and your ISP won’t let you. Carrier-grade NAT — increasingly common on consumer and NBN connections — means there’s no public IPv4 address and no port forwarding, so the classic “expose a service on the router” playbook simply doesn’t exist. A writer at XDA Developers recently documented their solution, and it’s a lovely piece of lateral thinking: they gave the oldest, weakest board in the drawer — an original Raspberry Pi Zero — the most important job in the lab.

The ingredient that makes it work is a mesh VPN such as Tailscale. Instead of opening ports, every device you care about joins a private overlay network and talks to its peers over encrypted WireGuard tunnels, using UDP hole-punching to sneak through NAT. No inbound ports, no cloud server rental, and the free tier is generous enough for home and small-office use. It’s the answer to CGNAT that doesn’t involve calling your ISP or paying for a static IP you can’t get.

The clever part is how little of it you actually need to install. Installing the VPN client on every server, VM and container gets old fast — especially if you rebuild nodes regularly for experiments. The fix is a subnet router: one device joins the mesh and advertises your local subnet as a route. From that moment, anything connected to the VPN can reach everything on your LAN — servers, printers, smart gadgets, the lot — with no client installed anywhere else. One board, one configuration, whole-network coverage.

And that’s where the Pi Zero earns its keep. Routing packets between a VPN tunnel and your LAN is almost no work at all for a modern CPU, let alone a humble ARM11. The XDA author paired theirs with DietPi to strip the OS down to essentials, enabled IP forwarding, and enabled route advertisement with a single command:

tailscale set --advertise-routes=192.168.0.0/24

Approve the route once in the admin console and you’re done. That $15 board everyone wrote off is now the front door to your entire network.

A few practical notes before you raid the parts drawer:

  • Connect it wired if you can. The original Zero has no Ethernet port, and subnet routing over Wi-Fi is fine for SSH and dashboards but will bottleneck big file transfers. A USB Ethernet adapter helps; a Pi Zero 2 W (or any spare Pi) is better again if you have one.
  • Keep a fallback path. A subnet router is a single point of failure. If remote access matters to you, a second device advertising the same route elsewhere on the LAN gives you failover — or at least a way in when you unplug the wrong cable.
  • Lock the tailnet down. Turn on device approval, use Tailscale’s ACLs to limit which devices can reach which subnets, and consider an exit node so roaming laptops can keep lab access off public Wi-Fi.
  • Mind the power supply. A flaky USB charger will brown out a Pi under network load and you’ll spend an evening debugging a problem that costs $10 to fix.

For small businesses the same pattern applies with a straight face: secure remote access to an office LAN without opening a single inbound port, without a VPN concentrator appliance, and with the audit trail of who connected sitting in one admin console. Not bad for the board at the bottom of the drawer — and a good reminder that in networking, the boring jobs are often the important ones.

Cutting AI model costs with OpenAI-compatible API gateways

AI APIs have quietly become a line item for a lot of small businesses. A customer-service assistant here, a document summariser there, and suddenly the monthly bill is measured in hundreds of dollars — most of it spent on frontier models doing work a cheaper model could handle. The good news is that this is one of the few areas in tech where switching costs are close to zero, and a new wave of services has grown up around exactly that.

The pattern looks like this: instead of holding separate accounts with OpenAI, Anthropic, Google and the rest, you point your code at a single gateway that speaks the OpenAI API dialect — the de facto industry standard. Behind that one endpoint, the service routes your requests to whichever provider and model you ask for, at prices that are often well below list. One recently launched example, CheaperInference, promises access to leading models through one OpenAI-compatible API with savings of up to 60% on inference costs. It is new enough that there is little independent coverage yet, so treat it as an example of the category rather than an endorsement — but the category itself is well established.

Why does this work? Because the OpenAI API format became the lingua franca of the industry. Nearly every model provider and open-source framework speaks it, which means an aggregator only needs to translate at the edges. For you, that means the migration is a one-line change — swap the base URL and API key — and your existing code, SDKs and tooling keep working. That same property is your negotiating leverage: when a better price appears elsewhere, you can act on it in minutes, not weeks.

The real savings, though, come from pairing a gateway with some straightforward habits:

  • Route by task, not by default. Most workloads don’t need a frontier model. Classification, extraction, drafting and routing tasks run happily on smaller models that cost a tenth as much. Keep the expensive models for the genuinely hard requests.
  • Measure before and after. Run the same real-world prompts across two or three models and compare quality against cost. You will usually find one or two tasks where the premium model earns its price, and several where it does not.
  • Cache and batch. Identical requests don’t need to hit the API twice, and most providers offer half-price batch processing for work that isn’t time-critical.
  • Watch the context, not just the price. Long documents fed to a “cheap” model with a large context window can cost more than a smart model given a summary. Trim what you send.

There are caveats worth respecting. Your prompts and data pass through a third party, so check the privacy terms before sending anything sensitive — for regulated data, this may rule smaller aggregators out entirely. Latency can differ from going direct. And a very new service deserves a cautious rollout: start with internal, low-stakes workloads, keep an eye on uptime, and keep that one-line switch back to the direct provider ready.

For homelab tinkerers and small businesses alike, this is a rare win-win. The competitive market and the common API dialect mean the cost of experimentation is minutes of your time, and the payoff is a bill that scales with what your workload actually needs rather than what the default model charges. Services like CheaperInference are worth a look — the worst case is you learn where your money was going.

WordPress and Static websites on S3

WordPress and Static websites on S3 are two very distinct hosting solutions. WordPress is a Content Management System (CMS) that allows users to easily build and maintain dynamic, content-rich websites. On the other hand, Static websites on S3 are a more traditional hosting solution where HTML, CSS, and JavaScript are all hosted on Amazon’s Simple Storage Service (S3). Both solutions offer different benefits depending on the type of website you are building, so it is important to weigh the pros and cons of each before making a decision.

This website is hosted on Amazon Web Services’ Simple Storage Service (S3). The content management system (CMS) used to edit the website is WordPress.

This is achieved by running a WordPress installation on a local server. The website is then edited as any other WordPress website. A static site exporter is then used to convert the WordPress website into a set of static HTML, CSS, and images. Finally, Rclone is used to sync these files with an S3 bucket.

Once the static files have been synced to S3, they can be hosted as any other static website. This cycle of editing, exporting, and syncing can be repeated as often as necessary.

This method does have its limitations. Any pages that require dynamic content, such as an online store, will not be supported by a static export. However, for websites that can work within these constraints, hosting costs are greatly reduced and the website can be hosted on Amazon Web Services’ Content Delivery Network (CDN) for lightning-fast speeds from anywhere in the world.

HITS Stores

I recently launched two online stores that are built on WordPress/Woocommerce platforms. The first website, 800adventures.com.au, is targeted towards CF Moto 800MT owners. This website is hosted on AWS Lightsail and uses Lightsail’s Proxy CDN to cache images and static files with recommended settings for WordPress dynamic websites. It achieves a score of A on GTMetrix.

The second website, getpunnyshirts.com, offers both self-designed and reseller T-shirts. While this website currently has lower sales than 800 Adventures, it is hosted on my home network due to its lower traffic volume. To improve its performance, I am using a proxy on Lightsail with a public IP, which runs a dockerised installation of Nginx configured as a forward proxy with SSL certificates for the domain. The traffic is forwarded via a Zerotier VPN PtP network to my home Proxmox cluster that hosts the web server. Unfortunately, due to the time it takes to receive the first byte, the website only achieves an F on GTMetrix. However, the bandwidth is sufficient for low traffic.

Proxmox, clustering and high availability for the home lab

To enable HA in Proxmox you need a way to allow Proxmox to move VMs between systems without having to move the associated disks of the VM.

This is achieved by using a shared disk system between the cluster nodes.

Options I have tried include:

NFS to a (very old) Dlink NAS

Using a DNS-345 with 4x 500gb in Raid 5 and a single 1Gb network connection.

I enabled NFS and allowed the cluster access. After adding the share to the cluster I was able to use it to store VM and CT disks.

I was able to run about 20 Windows and Linux based systems as long as they didn’t need heavy disk IO. Any actions that did required patience to complete.

Monitoring the DNS-345 it became apparent the limitation seemed to be the network connection. CPU and disk IO on the NAS itself was minimal.

The NAS itself is not upgradeable.

NFS to Unraid

Similar to the DNS-345 but with a more powerful system.

A bit of background if you are not familiar, Unraid is not aimed at this sort of task and is more suited to home usage as a media and file storage system. It worked well but I also like the feature in Unraid where it shuts down disks during quiet times. This is achieved by the ability to read data from a single drive (unlike ‘proper’ RAID where reads are spread out across disks). Running VMs meant there was going to be disk access to any disks hosting a VM. I could limit usage of disks in Unraid’s share settings.

I also went through upgrades on this server including:

  • Change CPU from Ryzen3 to Xeon. The Ryzen worked well but the associated motherboards in the price range I was in lacked certain features (PCI-e slots or ECC memory) that were better served by a server style board.
  • SATA add on cards where changed to SAS to allow use of SAS drives. Enterprise style drives are surprisingly cheap on ebay.
  • Emulex cards allowed 10gb fibre connections via IP for Unraid

To cut a long story short, I felt a more dedicated storage system would work better than Unraid.

iSCSI to Unraid

While looking over options I had a look into the iSCSI plugin available on Unraid. This was a great way to learn about iSCSI as it leads you through the process. I was able to make this available to the Proxmox cluster just as you would any iSCSI drives. Along with the 10gb fiber IP network this allowed for quite a quick disk backend.

iSCSI to ESOS

After acquiring more dedicated hardware which included a rack mount server with SAS 10k drives and (lowend) hardware RAID cards I went looking for appropriate software to allow Proxmox access.

I settled on Enterprise Storage Systems. This is designed to boot off a USB stick, is Linux based and is dedicated to being a storage system. Unlike FreeNAS and its various versions it has little features outside those required. It does have a text based user interface for configuration and some statistics on connections & usage.

I initially ran with Qlogic fiber cards but these will not work with Unraid, and I didnt want to run two seperate fiber networks. I went with Emulex and iSCSI to share the disks with the Proxmox cluster.

This is easily the best disk IO out of the options I had tried in my low budget home lab.

Proxmox for the home lab

Proxmox is a great option for a home lab. It has features enabled that others have only in their paid tiers.

It wouldnt see that way as every time you login, you are reminded you are not using the Enterprise supported version. This is completely fair as the work certainly deservers its price tag.

For those of use who run a small home lab to learn and get familiar with the running of enterprise systems Proxmox has the option of a ‘free’ upgrade system.

This will remove the enterprise repository and add the no-subscription repository.

Execute the following to change over each of your Proxmox installs:

rm /etc/apt/sources.list.d/pve-enterprise.list && \
echo "deb http://download.proxmox.com/debian/pve buster pve-no-subscription" > /etc/apt/sources.list.d/pve-no-subscription.list && \
apt update -y && \
apt full-upgrade -y

Linux shell – Disk space commands

Find all files 100Mb and greater in root

find / -xdev -type f -size +100M

Show current directory disk space usage, this filesystem only, and only at one level (but counts all files in the subfolders)

du -hx --max-depth=1

As above, but sort largest folders/files to the bottom of the list

du -hx --max-depth=1 | sort -h
WordPress Appliance - Powered by TurnKey Linux