Infrastructure
Home Server Infrastructure
A self-hosted platform built from hardware that was already sitting idle. It runs Linux headless with the lid closed, is administered entirely over key-based SSH, and reports hardware events to my phone within seconds of them happening.
01 — The problem
What was actually happening
Every project I build eventually needs somewhere to run. Renting that from a cloud provider is easy but it is a monthly bill and a black box — and an old MacBook Pro was already sitting in a drawer doing nothing. The obstacle was that a laptop is engineered to do the exact opposite of what a server needs.
- Close the lid on a laptop and it suspends — the single behaviour a server must never have.
- With no monitor or keyboard attached, a machine that fails to come back after a reboot is simply gone.
- Default SSH configuration is password-based, which is the wrong posture for anything left running unattended.
- A home server dies silently: power gets cut, the machine goes down, and nobody finds out until they need it.
02 — The solution
What I built, and why
Treat it as infrastructure rather than a repurposed laptop. That means the machine has to survive a reboot with nobody at the keyboard, refuse anything but key-based access, and tell me when something happens to it — because the failure mode of a home server is silence.
- Linux Mint as the base, chosen for stability and for behaving like a normal Linux server underneath.
- SSH hardened to Ed25519 key authentication only — password login and root login both disabled, attempts limited.
- Full headless configuration: lid-close suspend, sleep and hibernate targets masked so the machine stays up while closed.
- A Python service that watches AC adapter state through UPower and detects disconnect and restore events.
- That script promoted to a systemd unit — starts on boot, runs in the background, and restarts itself if it dies.
- Events pushed to a Discord webhook, which turns a hardware event on a machine in a cupboard into a notification on my phone.
03 — Process
How the work was sequenced
- 01
Define what 'server' means here
Wrote down the properties that actually mattered — survives reboot unattended, no console required, no password authentication, and tells me when it breaks — before installing anything.
- 02
Rebuild the machine
Replaced macOS with Linux Mint and established a base system that behaves predictably under the standard Linux service tooling.
- 03
Secure the front door
Set up Ed25519 key authentication from my main machine, then closed off password and root login and limited authentication attempts. Verified I could still get in before disabling the fallback.
- 04
Make it headless
Worked through the power-management layer — lid-close handling, suspend, hibernate and sleep targets — until closing the lid changed nothing about the machine's state.
- 05
Add eyes
Wrote a Python monitor against UPower to detect AC adapter transitions, because power loss is the failure this machine is actually exposed to.
- 06
Make it survive itself
Converted the monitor into a systemd service with automatic restart, so recovery does not depend on me noticing, and wired the alerts to a Discord webhook that reaches my phone.
04 — Technology
The stack, as decisions
Platform
Access & security
Monitoring
05 — Results
What it changed
Headless
Runs closed, with no monitor or keyboard attached
Key-only
Password and root SSH login disabled entirely
Self-recovering
systemd restarts the monitor on failure and on every boot
The interesting engineering was not in the happy path — it was in every assumption a laptop makes about having a person in front of it. Turning that off one layer at a time is what infrastructure work actually is, and building the alerting first changed how much I trust the machine to be left alone.
Have a problem worth solving?
Tell me what the process looks like today and where it breaks. If technology is the right answer, I will tell you what I would build — and if it is not, I will tell you that too.