The world's least efficient datacenter: a guide

What you are building

Every guide on this site teaches you to do something correctly: the commands in order, what a correct result looks like, the failure modes named. This guide is different. Today, entirely hypothetically, we are going to design the least efficient datacenter that money, electricity, and hubris can produce.

We need a metric, so we will borrow the industry's own: PUE, Power Usage Effectiveness — total facility power divided by the power that actually reaches computing equipment. A hyperscale datacenter runs around 1.1: nearly every watt does useful work. A decent enterprise server room manages 1.5. Our target is 4.0 or higher, meaning that for every watt of computing, three more watts die for nothing. We will refer to this number often, the way serious guides refer to backups.

Site selection: heat is the point

Cooling is the single largest overhead in a real datacenter, which is why ours will fight thermodynamics on its home turf. The ideal location is an attic. South-facing. Ideally with a skylight positioned to shine directly onto the server, so that the machine receives both its own waste heat and the sun's, a collaboration between your electricity bill and a star.

In winter, cooling is handled by opening the window. Real datacenters do use outside air — the technique is called free cooling, and it is engineered, filtered, and humidity-controlled. We will use it accidentally, through a window that also admits rain, pollen, and at least one confused bird per quarter.

For true artistry, install an air conditioner, then place a space heater two feet from its thermostat, set two degrees warmer than the air conditioner's target. Both machines will now run continuously, forever, in perfect disagreement. The power company will send you a card at Christmas.

One server, large, beloved

Redundancy dilutes commitment. Our datacenter contains exactly one server, and it is enormous, because a single machine with 512 GB of RAM feels like infrastructure, whereas four small ones feel like a to-do list.

The server has a name. Not a hostname — a name. Gandalf, usually, or Odin. You cannot decommission Odin. Odin has been up for five years:

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 417.32, 409.18, 386.55

That number is a point of pride, which is why you screenshot it and post it, and why every attacker who sees the screenshot also finds it impressive: 1,847 days of uptime means 1,847 days of kernel vulnerabilities, patched by nobody. Rebooting is out of the question anyway — a reboot is how you discover which services were started by hand in 2021 and never written into a systemd unit. Nobody remembers which ones. The server is now load-bearing in the organizational chart.

Storage: speed, and other ways to lose data

The disks are configured in RAID 0, for performance. The zero refers to the number of disks that may fail. For maximum effect, stripe the array across storage of mixed provenance: two proper SSDs, one aging spinner, and a USB stick from a conference. The array is exactly as reliable as the conference stick, which is the design.

Backups are handled by a directory on the same array named backup_final_v2_REAL, which contains a tarball of the previous naming scheme. Off-site backups are represented by a sticky note reading "set up off-site backups," which is, technically, stored off-site when you take it home on your laptop lid.

A correct result looks like: df reporting 97% usage, and a plan to deal with it next sprint.

Networking: a single strand of everything

The DNS server runs on the machine itself, so that when the server goes down, it takes with it the DNS record you would use to find out why. This is called consolidation.

The firewall was disabled in 2021 — temporarily, to debug something. The debugging concluded; the firewall did not return. Every port on the router is forwarded to the server "to save time later," and the router's admin panel is reachable from the WAN side with its factory password, for convenient remote management. Yours, and others'.

The server has been running unusually warm lately, even by attic standards, and top shows the busiest process is something called xmrig. We assume this is the monitoring tool we are using. We did not install it — it appeared on its own shortly after the ports were forwarded, which we take as a sign that the ecosystem is thriving. It monitors around the clock.

Power arrives through a chain of consumer power strips whose combined length exceeds the walking distance to the breaker panel — which is efficient, in a sense, because you will be visiting the breaker panel often.

Redundancy through complexity

Having refused redundancy where it matters, we now add it where it does not. The company homepage — one static HTML file — is served by a twelve-node Kubernetes cluster. This achieves what engineers call resume-driven architecture: the page loads in the same forty milliseconds nginx would have delivered, but it can now fail in ways that require a consultant.

For isolation, the cluster itself runs inside a virtual machine inside a virtual machine inside a virtual machine, each layer adding security the way each layer of a turducken adds bird. The contact form is nine microservices. Two of them have never been invoked. One of them is load-bearing and nobody knows which.

Heating as a service

A modern server converts electricity into computation and heat, and we intend to maximize the second output. A media server with no GPU is the classic play: CPU-transcoding a single 4K stream will pin sixteen cores and warm a small bedroom, a space heater that also plays movies. The ambitious operator graduates to running a large language model on CPU — a 70-billion-parameter space heater with an API, producing tokens at a rate best measured seasonally.

The monitor watches itself

Observability matters, so we deploy a self-hosted uptime monitor — on the same server it monitors. When Odin dies, the monitor dies with it, and here is the elegant part: no alerts fire. No alerts means no incidents. No incidents means perfect uptime, as measured. The monthly report has never looked better.

Alert emails, for completeness, are relayed through a mail server that also runs on Odin. The alerting pipeline is thus fully self-contained, in the way a snake eating its own tail is fully fed.

The uncomfortable part

Here is the section I have been putting off. None of this is fiction. The beloved irreplaceable server, the RAID 0 with backups on the same volume, the firewall disabled "temporarily," the Kubernetes cluster serving one page, the monitor watching itself — I have seen every one of these in production. Some of them I have seen this year. One or two of them, in my early days, I built.

What actual efficiency looks like is boring, which is why it loses the argument in the moment and wins it over a decade: a PUE you never think about because someone else engineered it. Machines sized to their workload instead of to their owner's self-image. A blast radius, considered before the explosion. Backups that are tested by restoring them, on a schedule, with a calendar reminder and no heroism. Redundancy that is dull — two of the cheap thing beats one of the magnificent thing, every time, in every failure I have ever been paged for.

And the most efficient datacenter you can run is the one you do not run. A VPS hands the power, cooling, redundancy, and 3 a.m. hardware failures to people who do them at scale, boringly, which is the highest compliment infrastructure can earn — and it leaves you the genuinely fun part, which is running your own services on top of it, on a machine you can afford to lose, which is the only kind you should ever experiment on.

FAQ

Should I actually do any of this?

No. Every section of this guide is a documented anti-pattern with a body count of weekends. If your current setup resembles more than two sections, skip to the last question in this FAQ — in the order given, because the order is the triage.

What is a good PUE, actually?

Hyperscale datacenters run around 1.1, a well-run enterprise room manages 1.4 to 1.6, and an uncooled closet with a space heater feud can genuinely exceed 3. You cannot meaningfully compete with 1.1 at home, which is the quiet economic argument for renting compute from someone who can.

Is heating a building with servers a real thing?

Yes — done properly. District-heating projects in several countries capture datacenter waste heat through heat exchangers and pipe it into homes, by design, with engineering and contracts. The satire above is not that server heat can warm a room; it is doing it by accident and calling the accident a strategy.

My server already looks like this. What do I do first?

Backups, tonight, to somewhere that is not the server, and then a test restore — an untested backup is a rumor. Second, patches and the reboot you have been avoiding, in a planned window, so you learn what breaks while you are watching. Third, split the single point of failure: move DNS and monitoring off the box. Everything else can wait for a calmer week; those three cannot.