I addressed that in a few ways:

1. I bought a quality SD card to start with. A 1 TB card is a lot of eggs in one basket so I wasn't about to cheap out on that part.
2. The board has 32 GB of eMMC which is where the OS is installed
3. There are very few writes to the SD card during normal operation (after initially loading content onto it). Running data (DBs, caches, log dirs, etc) for most applications is stored on the eMMC rather than the SD card or in some cases written to tmpfs (logs).
4. The subset of content I loaded onto this from my main media server was all chosen because it has the most re-watch potential, so re-loading close to a TB of media isn't something that's going to happen too often. The largest write it sees is the semi-annual refresh of the full ~130 GB Wikipedia ZIM dump, but I may push that back to once a year. I've only updated it twice so far.
5. Armbian assumes it's going to run from SD card and does a pretty good job about minimizing the number of writes. Logs are all written to zram and only occasionally written to disk, it has no swap file, etc. If those are good enough to keep an SD card happy, they should keep an eMMC even happier.

Basically, I tried my best to configure the SD card so that in day to day use it's WORM (write once, read many) without actually going so far as mounting it read only. The data that gets synced daily from my main servers is incremental and usually has few changes.

I've had PIs running for years without issue with the SD card mounted read only and retired them from service before the SD cards ever started showing issues. My Meshtastic EAS Alerter project is using one of those Pi Zero W2's I retired from an older project and its 6 year old SD card.

This is actually the second iteration. Originally I attached a 1 TB SSD via a USB->NVMe enclosure. That worked, but also made the unit sprawl which was something I wanted to trim down in the final version. It worked but had random glitches and instability that I initially chalked up to the board and/or Armbian. I didn't realize it was EMI from the Wi-Fi coming in through the USB cable until after I switched to the 1 TB SD card. That's why I added some ghetto shielding to the power cable for lack of having ferrite beads on hand lol.

Should the SD card prove problematic over time, I can always go back to the USB->NVMe solution and lose its "keychain" form factor.

   /_\  _ _ _ __ | |__(_)__ _ _ _  
  / _ \| '_| '  \| '_ \ / _` | ' \ 
 /_/ \_\_| |_|_|_|_.__/_\__,_|_||_|
                                   
 v25.11.2 for BananaPi BPI-M4-Zero running Armbian Linux 6.12.58-current-sunxi64

 Packages:     Ubuntu stable (noble)
 Updates:      Kernel upgrade enabled and 52 packages available for upgrade 
 WiFi AP:      SSID: (BananaAP), channel 6 (2437 MHz), width: 20 MHz, center1: 2437 MHz
 IPv4:         (LAN) 192.168.5.1, 10.10.10.15 (WAN) 192.168.1.12
 Containers:   postgres_postgres_1

 Performance:  

 Load:         4%           	 Uptime:       18 weeks, 22 hours, 49 minutes	 Local users:  2           	
 Memory usage: 45% of 3.83G  	 Zram usage:    74% of 1.91G  	
 CPU temp:     63°C           	 Usage of /:   35% of 29G    	
 RX today:     6 GiB  

It's kind of a mix of things duct-taped together, but here's the gist of what controls what. If you want to see any specific configs, let me know.

Network Manager controls the "static" interfaces. I've got some udev rules for my known hardware (USB wifi/ethernet adapters) so that they get friendly names as opposed to ugly "predictable" names.

The interfaces managed by NetworkManager are:

• STA mode Wi-Fi (internet uplink)
• LAN Bridge
• Wired Ethernet (internet uplink)

Connecting a USB-tethered smartphone is pretty plug and play. It automatically gets picked up as a USB ethernet interface, receives its IP address from DHCP, and gets set as the default gateway. So there's nothing that needs to be configured when using that as the internet uplink other than making sure there's no other active gateway that might interfere.

The LAN segment is a generic Linux bridge called br-lan (I'm borrowing OpenWRT's naming convention). In normal operation, it has wlan1 and usb0 as members (AP and USB ethernet gadget, respectively). If I need a wired ethernet port on the LAN side, I just plug a USB ethernet adapter in and add it with brctl addif br-lan eth{XXX}

The usb0 ethernet gadget interface is brought up using a script that runs at boot via systemd to configure a libcomposite ethernet gadget before the network target. This ensures it's available when the network comes up so it can be successfully added to the LAN bridge.

When changing out of the default configuration, I just go into network manager to enable/disable the correct interfaces. e.g. If I want to use wired ethernet for uplink and internal wifi for client AP, I enable the wired ethernet and disable the internal wifi's connection to the router. Then I swap hostapd conf files to use the one configured for the internal wifi instead of the USB one and update the members in the LAN bridge accordingly. e.g. brctl delif br-lan wlan1 ; brctl addif br-lan wlan0

To add a LAN-side wired ethernet, I just make sure it's not already configured for "WAN" in NetworkManager and add it to the LAN bridge. That, or setup a VLAN interface and use a single USB ethernet adapter for both (haven't done that on this device but I know it works from having done that in the past).

Thankfully, PiHole exposes the DHCP controls for its underlying dnsmasq and since I'm already running PiHole for ad blocking and DNS, it was natural to also use it for DHCP. It's configured to advertise addresses to the br-lan interface only.

Routing/NAT is all done directly with iptables. The VPNs dynamically update it as they connect/disconnect using their up and down hook scripts, and for the NAT used for client connections, it's basically just iptables -t nat -A POSTROUTING -s $SOURCE_CIDR -o $OUT_INTERFACE -j MASQUERADE where SOURCE_CIDR=192.168.5.0/24 is the LAN segment address range and OUT_INTERFACE=wlan0 is the uplink interface (in the default configuration).

I've got some ugly scripts to adjust the NAT rules depending on which interface is currently acting as the "WAN" interface.

So that's why your name is Picnic!

Yeah, I was surprised as well by how many things can run concurrently and why this project ballooned like it did. It was originally just going to be a travel router and PiHole but I decided to see how much I could cram in there. There's still room for more but I had to move on to other projects once winter was over. If/when I have time, I'd like to add a map tile server to the mix.

The only limit I've run into is when I'm running the NextJS dev server and Jellyfin at the same time. That's just a bit too much demand on the memory so one or the other crashes. So I can't watch JF while I work, but considering what's hosting these, I can forgive it.

Ha, yeah, that UPS board isn't going on any plane. I'd just use an approved power bank in that case.

The original intent of this was a travel router that VPN'd back to home as well as providing PiHole ad blocking, but it ballooned when I just wanted to see how much could run on this little board. I didn't have anything in mind when I made it other than if I could, so I had to invent reasons after the fact lol

SHTF Server

If shit ever hits the fan (evacuation order, natural disaster, house burns down, etc), this is something that's easy to grab, takes up almost no space, can be powered for days with a power bank, and has all my important docs on an encrypted volume. If I'm stuck in a temporary shelter or whatever, I can keep myself entertained as well as a handful of other people who can connect to it.

I've also got cron jobs to sync important files from my main servers to this one, so it stays up to date.

Power Outages

We don't maintain any permanent streaming subscriptions (only when there's something good on like a new season of Star Trek drops lol). So if the power goes out, and I can't run the main servers, this can (and has!) run from a power bank for about 36 hours. Everyone in the house can stream something different to their phone if they want.

Camping, Traveling, Etc.

Kinda covered under offline access, but can keep the kids entertained without cell service or racking up data overages.

I also made a couple of Snapcast receiver speakers with some old Pi Zero W's so we can have wireless speakers around the campsite. I was able to add an RTL-SDR dongle to it and pipe the FM audio to Snapcast, so if there's a game on, we can listen to that. I haven't used that in practice, but it worked on the bench.

Internet access isn't a given

I've had to travel places that have no or poor internet access and poor cell reception. Depends on where and why I have to travel and is always a crapshoot. This gives me a bare minimum environment that's always on hand.

Black Start

If my homelab ever goes totally down or has a major malfunction, I've got copies of documentation, console passwords (that are normally kept in Vaultwarden hosted on the stack that's unavailable in this scenario), and other resources to bring things back up. I host pretty much everything we use (including email) so when the lab is down (rare but does happen) it's nice to have a backup stack.

• MDN (HTML, CSS, JS): Yes - Had to manually crawl/scrape that one myself. Took almost 3 days since I had a pretty generous delay between pages.
• Tailwind: Yes (v3 anyway)

The Kiwix web interface has a search, and it's decent. AFAIK, unless you build your own somehow, that's all there is for that.