The Case for Minimal Self-Hosting: What a Raspberry Pi Zero in RAM Teaches About Infrastructure Bloat

Thesis

For the past decade, the default approach to deploying any web service has been to reach for containerized orchestration, cloud load balancers, and virtual machines with orders of magnitude more resources than the workload requires, driven by a combination of convenience, vendor marketing, and a gradual loss of intuition for how little hardware is actually needed to serve static content over HTTP. The experiment documented at zero.btxx.org strips away these accretions, using a Raspberry Pi Zero v1.3 with 512MB of total RAM to serve a public website entirely from memory, with only ~40MB of that RAM consumed by the Alpine Linux diskless installation, leaving the vast majority of available memory for static site content and lightweight web server processes. The core argument of this setup is that infrastructure minimalism, enabled by purpose-built lightweight tooling and strategic offloading of resource-intensive tasks, can make even obsolete consumer hardware viable for public web services, a direct counter to the industry trend of scaling up resources for even trivial workloads.

Key Technical Choices and Their Rationale

The foundation of the experiment is Alpine Linux running in diskless mode, a configuration where the entire operating system loads into a RAM-based tmpfs filesystem at boot, using the microSD card only for initial boot and persistent configuration storage via the lbu (Alpine Local Backup) utility. Alpine is designed for minimalism, with a package manager (apk) that favors small, focused packages over monolithic installs, making it possible to fit a functional Linux system into ~40MB of RAM, a fraction of the 512MB total available on the Pi Zero. This diskless approach eliminates the SD card as a point of failure, as SD cards have limited write cycles and are prone to corruption in always-on setups, and reduces latency for filesystem operations, since RAM is orders of magnitude faster than even high-end SD cards. The author uses a 512MB microSD card specifically because the total RAM of the Pi Zero is 512MB, making full disk images trivial to back up via dd, as the entire boot media can be cloned in seconds over the network or by removing the card post-boot, since the system runs entirely in RAM and the SD card is only accessed at boot or when running lbu commit.

To avoid overburdening the Pi Zero's single-core 1GHz ARMv6 CPU, which lacks the AES instructions that speed up TLS handshakes on newer ARM chips, the author offloads TLS termination to a TierHive VPS, a low-cost provider with plans starting at ~$4 per year that include pre-configured HAProxy edge services for TLS termination and automatic SSL certificate renewal. The VPS runs socat to forward traffic to the Pi Zero's public IP (or a DDNS hostname via DuckDNS for home users with dynamic IPs) on a user-configured port, meaning the Pi only needs to handle unencrypted HTTP traffic. This traffic is served by darkhttpd, a single-binary static web server with no dependencies, designed to serve files with minimal memory footprint, or nginx for users requiring more complex configuration. Remote administration uses dropbear, an SSH server chosen over OpenSSH for its smaller size and lower resource overhead, ensuring that even SSH access does not consume excessive RAM.

Persistence in the diskless setup is handled by lbu, which writes changes to the FAT32 partition on the microSD card when the user runs lbu commit -d. The author configures lbu to include web server configuration, site files in /var/www, and any installed packages, ensuring that reboots or power outages only require a brief boot sequence to restore the full setup. Backups are similarly simplified: the entire microSD card can be imaged via dd over SSH, or removed and cloned directly once the Pi is fully booted, since the card is not actively used after startup.

Broader Implications for Self-Hosting and Infrastructure

This experiment serves as a useful corrective to the bloat that has become normalized in web infrastructure. A static site, which is all the Pi Zero is serving, requires only a few kilobytes of memory to serve even moderately complex pages, yet modern static site deployment often involves pushing to a CDN with edge nodes around the world, or deploying to a VPS with gigabytes of RAM and multiple CPUs, most of which sit idle. For personal projects, microsites, or low-traffic documentation, this level of overprovisioning is wasteful, both in terms of cost and energy consumption. The Pi Zero setup draws only a few watts of power, compared to the dozens of watts consumed by a typical home server or the shared resources of a cloud VPS, and the $4 per year VPS cost is a fraction of even the cheapest standard VPS plans.

It also extends the lifespan of older hardware: the Raspberry Pi Zero 1.3 is nearly a decade old, yet it remains perfectly capable of serving static content, pushing back against the cycle of planned obsolescence that drives consumers to discard functional hardware when it no longer meets the requirements of bloated modern operating systems and applications. More broadly, the setup demonstrates the value of decoupled infrastructure: rather than running a monolithic stack that handles TLS, web serving, and persistence all on the same device, splitting these functions across specialized components reduces the resource requirements of each individual component, making the entire system more resilient and easier to maintain. This approach aligns with the original ethos of the early web, where small, focused tools handled single tasks well, rather than the current trend of all-in-one platforms that bundle unnecessary features.

Limitations and Counter-Perspectives

It is important to be clear about what this setup is not: it is not a replacement for a production web server serving dynamic content, handling high traffic, or requiring server-side processing like databases or API endpoints. The Pi Zero's single-core CPU can handle only a tiny number of concurrent connections, and the 512MB RAM limit means even large static sites with hundreds of megabytes of images or assets would not fit in memory alongside the operating system. The dependence on a home internet connection means that any outage at the ISP level will take the site offline, and dynamic DNS adds a layer of complexity for users with non-static home IPs. The use of a third-party VPS for TLS termination also introduces a single point of failure: if TierHive experiences downtime, the site becomes inaccessible, and the user is reliant on the provider's HAProxy configuration and SSL renewal processes.

Additionally, the diskless mode requires strict discipline: forgetting to run lbu commit after making changes will result in lost work on reboot, a workflow that is less forgiving than traditional disk-based systems. For most use cases, a standard cloud VPS or static site host remains a more practical choice, but that is not the point of the experiment. It is a proof of concept for what is possible when we stop defaulting to overprovisioned infrastructure and start matching tools to workloads, rather than reaching for the most powerful option available regardless of need. In an industry where resource consumption grows faster than workload requirements, this kind of minimalist experimentation is a necessary reminder that smaller, older hardware still has value, and that sometimes, less infrastructure is more.