Garage Rack Upgrade: Power, Networking and Resilience (2026)
During May 2026 I made a fairly substantial round of improvements to the detached garage rack that supports the wider Promethix platform. This was not just a cosmetic tidy-up. The work was aimed at improving power resilience, separating failure domains, cleaning up management access, and making the rack a more solid foundation for future growth.
The garage already benefits from a 5 kW solar installation fitted in 2024, backed by three battery storage units that provide substantial energy capacity for overnight and low-generation periods. During the solar installation a new consumer unit was also fitted, which created a sensible base for later electrical work around the rack.
What follows is a snapshot of where that environment now stands.
Power Improvements
One of the more important changes was replacing the original single garage socket used to power the rack. That feed has now been removed and replaced with an industrial Commando socket and a dedicated isolation switch.
The practical goal here was simple: move the rack onto a more datacentre-style power feed and give it its own dedicated RCBO, rather than sharing protection with more general garage circuits. That reduces the chance of nuisance trips and makes it much easier to isolate the rack cleanly from faults elsewhere in the garage or house wiring.
Separate double UK socket outlets were also installed on their own RCBO for general-purpose garage use. That means tools, chargers, and other ad hoc loads are much less likely to affect power delivery to infrastructure that is expected to stay up.
Within the rack itself, power distribution now follows a more deliberate layered approach. The Commando feed terminates into a rack-mounted PDU using IEC style connectors, which then supplies two independent UPS systems. Those UPS units in turn feed separate rack PDUs that distribute power to the rest of the equipment. It is still an evolving setup, but it is already a better basis for balancing load and thinking in terms of independent power paths rather than one flat feed.
Fire protection also got some attention during the same round of work, with a wall-mounted multi-purpose extinguisher added in the garage. The environment already had Zigbee smoke detection together with temperature and humidity sensors, so this adds another practical layer to the existing fire and environmental monitoring. None of that is glamorous, but it is exactly the kind of operational detail that matters more once a platform starts carrying real workloads.
Rack Layout and Environmental Details
The rack is built as a working infrastructure platform, with the layout driven more by serviceability and resilience than presentation. The overall structure is getting cleaner and more intentional, and the current layout separates networking, management, compute, storage, and power more clearly than before, which makes it easier to understand and maintain.
A spare long-range Wi-Fi access point was also installed to improve administration and maintenance connectivity in and around the garage. That is mainly there as an operational convenience rather than as part of the primary platform design, but it is useful when working locally on the rack.
Networking Changes
Networking in the garage rack has continued to evolve toward a more top-of-rack style design. A UniFi aggregation switch now serves as the main entry point for connectivity arriving from the house. The house and garage are linked by dual armoured fibre optic runs through underground conduit, and those fibres form the backbone between the house network cabinet and the detached garage rack.
From that aggregation layer, connectivity is carried downstream over bonded DAC links to both a dedicated SFP+ server switch and a UniFi PoE switch. The aim is straightforward: keep east-west bandwidth high between compute, storage, management, and switching, while preserving flexibility in how services are placed.
The wider WAN design has evolved as well. In the house network cabinet, the ISP-supplied ONT has now been replaced with a personally owned XGS-PON SFP+ ONT module. That removes an extra piece of hardware from the path and gives me more control over how the WAN side is presented into the switching fabric.
WAN connectivity is now carried over a dedicated VLAN. That allows internet access to move between multiple OPNsense routers configured for CARP high-availability failover, and it makes it possible to present the WAN anywhere in the switching fabric where that VLAN is available. In practical terms, that is much more flexible than tying the WAN edge to one fixed box and one fixed physical location.
Additional switching capacity has also been reserved to support a future secondary internet connection for provider redundancy.
Remote Management and Operational Convenience
Most of the systems in the rack use enterprise server boards with IPMI, so out-of-band access is already part of the normal operating model. The main exception is the TrueNAS storage server, which uses a consumer motherboard. To close that gap, I installed a JetKVM unit to provide remote console access.
That is a small detail in one sense, but in operational terms it is useful. Storage is one of the least convenient things to lose console access to, and this gives the SAN platform something much closer to the management experience already available on the rest of the rack.
Platform Direction
At the moment the wider platform still follows a fairly traditional split between compute and storage. Virtualisation workloads run on Proxmox hosts, while shared storage is provided by a dedicated TrueNAS SAN server. That model has served well and gives a lot of operational flexibility, but it also means the SAN remains one of the larger remaining single points of failure.
The likely longer-term direction is toward a more hyperconverged architecture that reduces dependence on a single storage appliance while preserving the advantages that shared storage currently gives me.
Backup strategy remains a major focus. A dedicated Proxmox Backup Server running on an older Dell R410 provides image-level backups of critical virtual machines. Because of the age and power characteristics of that hardware, custom automation powers it on only during scheduled backup windows, usually aligned with periods of solar generation to keep operating costs down.
Kubernetes adds another layer of protection. The current platform includes an RKE2 Delta cluster, and Velero is used to back up cluster state and workloads to S3-compatible object storage. That gives me a second backup path that is independent of Proxmox-level protection.
Security work has continued as well. The RKE2 Delta platform now includes CrowdSec for threat detection and response, together with additional Cilium network security policies to strengthen workload isolation and east-west traffic control.
Next Steps
One of the next major networking changes will likely be the retirement of the existing MikroTik server switching role. The current plan is to move the smaller UniFi aggregation switch into the house cabinet, replacing an existing MikroTik aggregation switch there, and then install a larger UniFi aggregation switch in the garage.
That should allow the current aggregation and server-switching functions to be consolidated into a single higher-capacity UniFi platform. The main motivation is to remove the interoperability rough edges I currently see between MikroTik and UniFi implementations of link aggregation and VLAN transport, while simplifying administration at the same time.
Overall, this is another step in the same direction the platform has been moving for some time. While it still supports my own engineering work and platform experimentation, this rack is better thought of as a small business infrastructure platform than a homelab. It hosts real third-party client sites, supports virtual machines and services for our family business, and increasingly needs to be operated with the same attention to resilience, failure isolation, power design, operational access, automation, and long-term maintainability that would be expected of a small private datacentre environment.