The Case for Colocating Old Laptops: Power Math, Missing IPMI, and Why It Works Anyway

There is a recurring post format on Hacker News where someone does something technically unconventional, it works, and the comments explode with a mixture of people who have done the same thing quietly for years and people who think it is a terrible idea. Using old laptops in a colocation facility as low-cost servers is exactly that kind of post, and the 366 points and 218 comments it attracted suggest the idea lands somewhere real.

The premise is straightforward: old laptops are cheap on the secondhand market, they consume very little power, they fit on a 1U shelf alongside other equipment, and their built-in batteries provide a natural buffer against brief power interruptions. Colocating one costs a fraction of what a comparable VPS would run you for sustained workloads. The setup is unglamorous and comes with real tradeoffs, but the economics hold up more than you might expect.

The Power Arithmetic

Colocation pricing varies by facility, but the core variables are rack space (measured in rack units), power draw (measured in amps or kilowatts), and bandwidth. Power is where laptops win decisively.

A typical 1U rackmount server from the previous decade, something like a Dell PowerEdge R620 or an HP ProLiant DL360 Gen8, draws somewhere between 80W and 300W at idle depending on configuration. Under load that can climb to 400W or more. A used ThinkPad T480 or Dell Latitude E7470, by contrast, idles at 8 to 15 watts and peaks around 45W under full CPU load.

At a colo that charges $150 per kilowatt per month (a rough industry midpoint), the math looks like this:

• A server idling at 150W: ~$22.50/month in power alone
• A laptop idling at 12W: ~$1.80/month in power alone

At $0.10/kWh (lower end of retail electricity, which many colos approximate for billing):

• 150W continuous: 150W × 24h × 30d = 108 kWh = $10.80/month
• 12W continuous: 8.64 kWh = $0.86/month

That gap compounds. If you are running several machines, the difference between colocating five laptops and colocating five 1U servers can easily be $40 to $80 per month in power costs alone, before accounting for the cost of the hardware itself.

A used ThinkPad T480 with 16GB RAM, an NVMe SSD, and a decent Intel Core i5-8250U costs roughly $150 to $250 on eBay as of 2025. A comparable 1U server with similar single-threaded performance is often cheaper in raw compute terms but costs you in power every month thereafter. For workloads that need to run continuously at low utilization, laptops on secondhand markets represent a peculiar form of capital efficiency.

What You Give Up

The most significant omission in laptop-as-server setups is out-of-band management. Enterprise rackmount hardware ships with dedicated management interfaces: Dell’s iDRAC, HP’s iLO, Supermicro’s IPMI. These give you a remote console that works even when the OS has crashed, lets you power cycle the machine, mount ISO images for reinstallation, and monitor hardware health, all over a separate network interface that runs independently of the main system.

Laptops have none of this. If the machine kernel panics during a kernel upgrade, or if you accidentally brick your bootloader, you are looking at a physical trip to the colocation facility or a call to remote hands. Remote hands at a colo typically cost $50 to $150 per incident, and that changes the risk calculus significantly.

People solve this in a few ways. The most robust is attaching a PiKVM or similar KVM-over-IP device to the laptop via USB and HDMI. A PiKVM v4 Mini runs around $130 and gives you full keyboard, video, and mouse control over the network, along with the ability to mount virtual drives. It does not solve the power cycling problem unless you add a smart PDU or a controllable relay, but it covers the majority of recovery scenarios. TinyPilot is a commercial alternative with a more polished interface.

Wake-on-LAN can sometimes be configured through a colocation facility’s managed switch, but this requires colo support and is not universally available. Some people use a second very small device, a Raspberry Pi Zero or similar, wired to the laptop’s power button header via a GPIO pin, giving them a software-controlled power switch. This is more involved but it essentially replicates the key functionality of IPMI at the cost of some wiring and a $15 microcontroller.

The other gap is storage. Laptop drives are not hot-swappable. If an SSD fails, someone has to open the machine. For redundancy-critical applications, this matters. For personal projects and low-stakes workloads, most people running this setup accept the risk.

The Battery as Infrastructure

One underappreciated feature of laptops-as-servers is the built-in battery. Most colocation facilities provide UPS infrastructure for the entire facility, so in theory this is redundant. In practice, brief power interruptions during maintenance windows, PDU transfers, or circuit work can cause unmanaged equipment to lose power for a few seconds. A laptop with a functional battery absorbs these without so much as a hiccup.

A typical laptop battery provides 30 to 90 minutes of runtime at idle loads, far more than necessary to survive any brief interruption. Dedicated UPS units for a single machine cost $60 to $200 and provide similar protection but take up space and have their own maintenance requirements. The laptop includes this capability by default.

Battery health degrades over time, and a laptop running continuously for two or three years will likely have a battery that holds a fraction of its original capacity. Some operators replace the battery every year or two as a maintenance item; others accept that the remaining capacity is still sufficient for their purposes. There is also a school of thought that continuous charging at 100% accelerates degradation, and some ThinkPad firmware allows you to set a charge threshold (typically 80%) to extend battery longevity. On Linux, this is accessible via /sys/class/power_supply/BAT0/charge_control_end_threshold on supported hardware.

Operating System Logistics

Running Linux headless on a laptop requires a small amount of upfront configuration that is easy to miss.

The most common issue is lid close behavior. By default, most Linux distributions suspend the system when the lid is closed, which is obviously catastrophic for a machine in a colo rack. The fix is straightforward in systemd-based systems:

# /etc/systemd/logind.conf
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore

After editing, reload with systemctl restart systemd-logind. The display backlight can be managed separately; xset dpms force off handles it if you have an X server running, though for a pure headless setup there is no display management needed at all.

Thermal management is worth monitoring. Laptops are designed to throttle CPU frequency under sustained load to prevent overheating, and this behavior is more aggressive than what you see on desktop hardware. For workloads that involve sustained high CPU usage, thermald on Intel hardware and careful attention to fan behavior matters. Tools like sensors from the lm-sensors package and powertop give visibility into thermal and power state. Some operators physically repaste the CPU every year or two, particularly on older ThinkPads where the thermal paste has dried out.

Comparing the Alternatives

The natural comparison class for this setup is not rack servers but mini PCs: Intel NUC, Beelink Mini S, Minisforum units, and similar form factors. These are purpose-built compact computers designed for the same power envelope as laptops, often with better sustained thermal performance because they are not trying to fit into a millimeter-constrained chassis.

A Beelink SER5 with a Ryzen 5 5500U costs around $200 to $250 new and draws similar power to a comparable laptop. It has no battery, but its thermal design is generally better for sustained workloads. Without the battery, you lose the built-in UPS, but in a facility with good power infrastructure that may not matter.

The laptop wins primarily when you already own it. The secondhand price of a ThinkPad T480 is lower than a new mini PC, and the battery is a genuine advantage. If you are buying hardware specifically for this purpose, a mini PC is probably the more rational choice. If you have old laptops sitting in a drawer, the math shifts considerably.

Cloud VPS comparison is relevant for smaller operators. A $6/month VPS from Hetzner or $4/month from Vultr provides persistent compute with no hardware management, no colo trip risk, and known uptime SLAs. For workloads that need occasional access and do not require sustained compute, cloud VPS remains compelling. The laptop-in-colo approach makes more sense when you have multiple services to run, when you need more control over the hardware stack, or when your workload profile makes per-hour cloud pricing unfavorable compared to fixed monthly costs.

Who This Makes Sense For

This is not a setup for production services with SLA obligations. The lack of IPMI, the reliance on consumer-grade hardware, and the logistical overhead of physical access create a risk profile that enterprise workloads cannot accept.

For personal infrastructure, hobby projects, self-hosted services, CI/CD runners for open source projects, VPN endpoints, game servers, or development environments that need to be accessible from anywhere, the economics are favorable and the risk profile is acceptable. The total cost of ownership for a colocated laptop running a personal website, a Jellyfin instance, a Minecraft server, and a handful of monitoring services compares well against cloud pricing once you account for the fact that those services run continuously and cloud providers charge by the hour.

The approach also forces a certain discipline around redundancy and recovery procedures. When you know that a crashed system requires either a PiKVM session or a physical trip, you become more careful about testing kernel upgrades in staging, keeping bootloader configurations clean, and maintaining SSH key backups. These habits are worth developing regardless of where your infrastructure lives.

The Hacker News thread that accompanied the original post surfaced a range of people who have been doing this for years, quietly, with good results. The idea is not novel, but seeing it documented with specific hardware choices, colocation notes, and honest cost accounting makes it more accessible. Sometimes the unglamorous solution is the right one.