The water bill nobody prints on a hosting invoice

A hosting invoice is denominated in dollars and gigabytes. It never mentions water. But a large share of data center cooling is evaporative. Warm air is pulled across wetted media or a cooling tower, and the heat leaves the building inside water that does not come back. On top of that, most of the electricity going into the racks was generated by something that also consumed water to make steam or to cool a plant. None of that appears on a line item, which is exactly why it is easy to never think about.

We started thinking about it. A fair amount of what we run now runs on Raspberry Pis instead, including a platform with real users on it.

This is not a reversal

We wrote a whole post about running no servers, on purpose, and that still stands. The helpdesk, the monitor, the CRM, the email pipeline and this blog are still Workers and D1, and they are staying there. A shared, multi-tenant edge platform is more efficient per request than a machine idling in a closet. Workers scale to zero between requests, and the hardware underneath is doing someone else's work in the gaps. Moving the helpdesk home would mean a box drawing power around the clock to serve a few thousand requests a day: a worse trade, environmentally and operationally.

The work that lives on small hardware is not work the edge was losing. It is work the edge cannot physically take: a persistent connection that has to stay open, a single SQLite file that one process writes to, a machine that has to render a PowerPoint or carry a video stream. Those things need a computer that stays on. The only question left is how big that computer has to be, and who is cooling it.

A whole platform on Pis

VerifyBlox is the clearest example. It is Roblox-to-Discord account verification: a dashboard, a REST API, a Discord bot, subscriptions and billing. Real users, real payments. It is served from Raspberry Pis.

Public traffic never touches them directly. Requests hit Cloudflare and reach the Pi through a tunnel that dials out, so there is no public IP, no port forwarding and no inbound firewall rule anywhere. The machines talk to each other over Tailscale.

The interesting part is what being stateful does to the architecture. The backend owns a local SQLite database and runs a single Discord bot, which means you cannot round-robin it across two nodes. That splits the database in half and gives you two bots answering the same commands. So the load balancer is deliberately active-passive: Caddy with lb_policy first, health-checking every 10 seconds, sending everything to one primary and touching the standby only when the primary stops returning 2xx.

That creates the obvious next problem: the load balancer becomes a new single point of failure. The fix costs nothing: run the same Cloudflare tunnel as two replicas, one on the LB host and one on the primary Pi itself. Cloudflare distributes requests to whichever replicas are connected and drops the ones that vanish. If the LB host dies, traffic quietly goes straight to the Pi. No load balancing product, no failover appliance, no second bill.

The rest of it

• SentinelVision camera nodes. Pis on-site, one per set of cameras, capturing and encoding continuously. Video was never going to leave the building, since that was the design, so the hardware was always going to be local.
• The inference host. One modest x86 machine on the tailnet runs the neural networks for every Pi that can reach it.
• Our CDN origin. Static assets come off a small self-hosted box behind a tunnel. The origin is not the CDN. Cloudflare's edge is. A cached asset never wakes the box up, so the origin only handles cache misses and uploads: a handful of requests, not a traffic curve. You do not need a real server to answer a question nobody asks.
• A Pi driving classroom displays, because rendering PowerPoint files and carrying live video are precisely the two things a Worker cannot do.

Small hardware has opinions

The romantic version of this is a silent cluster of tiny computers humming along. The real version came with a thermometer.

Running YOLO inference continuously on a Raspberry Pi 4 pinned it at its thermal limit. We measured 82.3 °C, hot enough that it throttled and then dropped off the network entirely. That is the failure mode nobody warns you about: not a crash, a disappearance. The fix was splitting the work: the Pis capture and encode, one machine with real CPU does inference for all of them, and each Pi keeps local models so it falls back to detecting on its own when the host is unreachable. The Pis now sit in the 50s.

Efficiency that takes your monitoring offline is not efficiency. Hot and working beats cool and blind.

The honest accounting

We are not going to publish a number of liters saved, because we would be making it up. Nobody meters the water attributable to one tenant's slice of a rack, and a Pi in our building still draws grid power that had a water cost upstream. What genuinely changes is narrower than the headline: the direct evaporative cooling draw for these workloads goes away, because a Pi is cooled by room air rather than by a tower, and the energy involved drops by an order of magnitude against a rented always-on server, which drags its share of the generation-side footprint down with it.

It is a small saving, honestly measured, on a small company's footprint. We would rather claim that than a rounder number we can't defend.

It is worth doing because the same reasoning scales down to the people we work for. It is a common thing to find on a small business network: a virtual server billed every month to do one job a device on someone's own desk could do, or one that quietly stopped doing any job at all and kept billing. Deciding what genuinely needs to run somewhere else, and what was only ever rented out of habit, is a normal part of what we look at when we take on a network.