I set up a homelab bathroom setup once as an experiment in space and cooling. The room was unused and had decent ventilation. I treated it like a technical space, not a spare loo with servers dumped on the floor. That mindset changes choices: waterproofing, safe power, sensible racks, and clear rules about liquids.
Start by assessing the physical risks and the power draw. Measure the available floor and wall space, note where plumbing runs, and identify the nearest consumer unit. Put metal server cases off the floor on a raised shelf or wall mount. Use IP-rated enclosures for any kit that sits close to wet areas. Fit a residual current device (RCD) on the circuit serving the room and add a separate fused spur for the homelab if possible. Count the watts of each device before buying. A good rule is to budget 20 to 40 per cent headroom over your calculated load so the circuit never runs flat out. Treat water cooling as a specialist option. A closed-loop, professional water-cooling loop can cut noise and cool dense racks, but it brings leak risk. If you use water cooling, buy leak detection sensors and route the loop so any leak drains away from electronics. Prefer external radiators or put radiators in a dry cupboard outside the bathroom whenever you can.
Choose equipment with power and cooling in mind. Pick small, low-power servers for always-on tasks. Single-board computers, NUC-class devices, or low-TDP mini-servers handle DNS, DHCP, local CI, and lightweight VM hosts. Reserve bigger boxes or GPUs for batch work only. If you run GPUs, cap their power draw and clock to reduce heat and bills. For storage, choose NAS units with efficient drives or SSDs; spinning disks add heat. Use fans sized for airflow rather than RPM. Bigger fans at lower speed move more air and make less noise. For server management, use an out-of-band console or IPMI on a separate VLAN. Keep the management network off the main residential router. Automate configuration with Ansible or simple shell scripts so you can reprovision quickly if something floods or trips the RCD.
On Linux configurations focus on power and reliability. Turn off unused services. Use powertop to find the biggest wakeups and apply its suggestions. Set a conservative CPU governor such as ondemand or schedutil, and reduce swappiness to 10 for systems with plenty of RAM: echo 10 | sudo tee /proc/sys/vm/swappiness. Use systemd timers for heavy cron jobs and schedule them to run during off-peak hours if you’re on a time-of-use tariff. For containers, limit CPU shares and memory to stop runaway processes from heating the room. Keep logs rotating aggressively to save SSD wear and to avoid surprises with storage full. Test changes incrementally and have a rollback plan. If a kernel or driver behaves oddly with your hardware, hold the known-good package until you can test the upgrade offline.
Track power consumption and act on the data. Fit a clamp meter for rough checks and use smart plugs or an inline power meter for per-device readings. Capture usage over a week, during peak runs, and while idle. Log the numbers to a simple Prometheus endpoint, or even a CSV—trend is what matters. Target a baseline idle figure, then push changes and watch the delta. For energy efficiency, batch heavy renders at times when you can accept higher draw, or move them to a separate, better-cooled location. Small changes add up: undervolt CPUs by a few hundred millivolts, lower GPU power limits, and reduce fan curves where safe. Each tweak should come with a verification step so you know performance and failure modes haven’t changed.
Concrete takeaways: treat the bathroom like a wet plant room, not a garage; separate power and management networks; measure power before and after each change; keep water-cooling loops away from electronics and use leak detection; automate Linux configuration so recovery is fast.
