My 12U 10 All Rounder Home Setup

My 12U 10 All Rounder Home Setup

Introduction

If you have ever stared at a cramped home network, watched ad‑laden pages load, or felt the sting of a rogue device snooping on your traffic, you know the frustration that fuels a homelab project. The phrase “My 12U 10 All Rounder Home Setup” captures a growing niche of enthusiasts who turn a modest rack‑mount cabinet into a self‑hosted command center that handles everything from DNS filtering to VPN termination, from CI pipelines to network monitoring.

This guide is written for seasoned sysadmins and DevOps engineers who already understand the fundamentals of Linux, networking, and container orchestration, but are looking for a concrete, reproducible blueprint to build a compact yet powerful environment under a desk. You will learn why a 12‑U rack is an ideal size for a home lab, how to select hardware that balances performance and power consumption, which open‑source services fit naturally into a ten‑service stack, and how to wire everything together without ending up with a spaghetti of cables.

By the end of this article you will have a clear mental model of the architecture, a step‑by‑step installation plan, a set of hardened configuration snippets, and a set of operational practices that keep the lab reliable, secure, and easy to maintain. The content is deliberately free of marketing fluff; every recommendation is grounded in real‑world experience, and all code examples use placeholders that work with Jekyll’s Liquid templating ($CONTAINER_ID, $CONTAINER_NAMES, $CONTAINER_STATUS, $CONTAINER_IMAGE, $CONTAINER_PORTS, $CONTAINER_COMMAND, $CONTAINER_CREATED, $CONTAINER_SIZE).

---

Understanding the Topic

What Is a “12U 10 All‑Rounder Home Setup”?

A 12U rack unit denotes the vertical space available in a standard 19‑inch server rack. Twelve units can accommodate a modest collection of hardware while still fitting under a desk or in a closet. When we say “10 All‑Rounder”, we refer to a curated set of ten services that collectively cover the most common homelab use cases:

1. Network gateway / DHCP – provides internal routing and address allocation.
2. DNS filtering (e.g., AdGuard) – blocks unwanted queries at the DNS layer.
3. VPN termination – creates secure remote access to the home network.
4. Observability stack (Prometheus + Grafana) – collects metrics and visualizes health.
5. CI/CD runner (e.g., Drone or GitLab Runner) – executes automated tests and builds.
6. Container registry (e.g., Harbor) – stores custom images securely.
7. Backup target (e.g., Restic + Rest Server) – safeguards critical data.
8. Network monitoring (e.g., Netdata) – offers real‑time bandwidth and latency insights.
9. Home automation hub (e.g., Home Assistant) – integrates IoT devices.
10. File sharing / media server (e.g., Nextcloud or Plex) – provides personal cloud storage and streaming.

Each of these services can be containerised, providing isolation, version control, and easy rollback. The “all‑rounder” label reflects that the stack is deliberately diverse: it is not a single‑purpose server but a multi‑tenant platform that can be repurposed as needs evolve.

Historical Context

The modern homelab movement traces its roots to early hobbyist servers built on repurposed workstations. The rise of Docker in 2013 introduced a lightweight approach to packaging applications, and the subsequent emergence of Kubernetes‑lite tools such as Portainer, K3s, and Rancher made it possible to manage multiple containers without the overhead of a full‑blown cluster. Around the same time, AdGuard Home and Pi‑hole democratized network‑level ad blocking, encouraging enthusiasts to experiment with DNS‑based filtering as a first line of defense against tracking scripts.

From a hardware perspective, the MikroTik hEX S and similar compact routers became popular for bridging ISP‑provided modems to a home network while offering extensive firewall capabilities. Their small form factor and low power draw make them ideal candidates for integration into a 12U rack.

Key Features and Capabilities

• Modularity – Each service runs in its own container, allowing independent upgrades and scaling.
• Self‑containment – All dependencies are declared in declarative YAML or JSON files, making the environment reproducible on any compatible host.
• Observability – Built‑in metrics collection (Prometheus, Netdata) provides visibility into container health, network throughput, and host resource utilisation.
• Security hardening – By default containers run with non‑root users, read‑only filesystems, and limited capabilities, reducing the attack surface.
• Scalability – Adding a new service typically involves dropping a new docker run or docker compose entry, without disrupting existing workloads.

Pros and Cons

Pros	Cons
Clean separation of concerns via containers	Initial hardware procurement can be costly if high‑end components are chosen
Easy to back up configurations as plain text files	Requires a baseline understanding of networking and Linux permissions
Ability to run a wide variety of services on a single physical box	Power consumption can increase with many always‑on containers
Strong community support for each component	Debugging multi‑container failures may need familiarity with Docker networking
Flexibility to replace any service with a newer alternative	Need to manage persistent storage for stateful services

Real‑World Applications

• ISPs and telecom engineers use a similar stack to test new routing policies or to simulate subscriber traffic patterns.
• Security researchers leverage DNS filtering and IDS/IPS containers to create a safe sandbox for malware analysis.
• Software developers run CI pipelines locally to validate builds before pushing to cloud CI services.
• IoT hobbyists integrate Home Assistant with a personal media server to create a unified smart‑home hub that respects privacy.

Comparison to Alternatives

• Raspberry Pi‑based labs are cheaper but lack the expandability and thermal headroom of a dedicated 12U chassis.
• Full‑blown on‑premises servers (e.g., Dell PowerEdge) provide higher CPU counts but consume far more electricity and generate more heat.
• Pure virtualization (VMware, Proxmox) offers stronger isolation for workloads that cannot be containerised, but introduces additional management overhead.

---

Prerequisites

Hardware Requirements

Component	Minimum Specification	Recommended Specification
Chassis	12U rackmount case with adequate airflow	Steel chassis with front and rear intake fans, tool‑free slide rails
Motherboard	Mini‑ITX form factor, at least 4 SATA ports	Server‑grade board with IPMI, dual Ethernet ports, support for ECC RAM
CPU	Quad‑core 2.0 GHz	Six‑core 3.0 GHz with AES‑NI for encryption
RAM	8 GB	32 GB DDR4 ECC
Storage	2 × 250 GB SATA SSD	2 × 1 TB NVMe SSD in RAID‑1 for redundancy
Network	Single Gigabit Ethernet	Dual 1 GbE ports, optional 10 GbE for future expansion
Power	350 W PSU	550 W 80 PLUS Gold, redundant if possible
Cooling	One 120 mm exhaust fan	Two 120 mm front intake + rear exhaust fans with PWM control

Software Requirements

• Operating System – Ubuntu Server 22.04 LTS or Debian 12 with kernel 6.x.
• Docker Engine – Version 24.x or later.
• Docker Compose – Version 2.20 or later.
• Git – For pulling configuration repositories.
• SSH – For remote administration.
• Fail2Ban – Optional, for brute‑force protection on exposed services.

Network and Security Considerations

• The ISP modem should be placed in bridge mode to avoid double NAT.
• A dedicated LAN interface on the router (e.g., MikroTik hEX S) will handle internal DHCP and firewall rules.
• All external‑facing services must be bound to the WAN interface only if explicitly required; otherwise, keep them on the internal network.
• Use iptables or nftables to enforce a default‑deny policy on inbound traffic.

Required Permissions

• The user performing the installation must belong to the docker group or have sudo rights to manage containers.
• Access to the server’s IPMI console is recommended for out‑of‑band management.

Pre‑Installation Checklist

1. Verify BIOS settings: enable VT‑x/AMD‑V, disable Secure Boot if Docker requires it.
2. Update the OS packages (apt update && apt upgrade -y).
3. Install Docker Engine following the official convenience script.
4. Add the current user to the docker group and reload group membership.
5. Confirm Docker daemon is running (systemctl status docker).
6. Allocate persistent storage volumes for each stateful service (e.g., /var/lib/harbor).

---

Installation & Setup

1. Initializing the Base Stack

Create a directory that will hold all configuration files:

mkdir -p $HOME/homelab/config
cd $HOME/homelab/config

Initialize a Docker Compose file that defines the ten services. Below is a skeleton that you can extend:

version: "3.9"

services:
  # 1. Network gateway / DHCP (example: Keenetic or OpenWrt container)
  dhcp:
    image: $CONTAINER_IMAGE
    container_name: $CONTAINER_NAMES[0]
    restart: unless-stopped
    ports:
      - "53:53/udp"
      - "53:53/tcp"
    environment:
      - DHCP_ENABLED=true
    volumes:
      - $CONTAINER_PORTS[0]:/etc/dnsmasq.d
    $CONTAINER_COMMAND

  # 2. DNS filtering (AdGuard Home)
  adguard:
    image: $CONTAINER_IMAGE
    container_name: $CONTAINER_NAMES[1]
    restart: unless-stopped
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
    environment:
      - TZ=UTC
    volumes:
      - ./adguard:/opt/AdGuardHome/work
      - ./adguard/conf:/opt/AdGuardHome/conf
    $CONTAINER_COMMAND

  # 3. VPN termination (WireGuard)
  wireguard:
    image: $CONTAINER_IMAGE
    container_name: $CONTAINER_NAMES[2]
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=UTC
    volumes:
      - ./wireguard:/config
    $CONTAINER_COMMAND

  # 4. Observability (Prometheus + Grafana)
  prometheus:
    image: $CONTAINER_IMAGE
    container_name: $CONTAINER_NAMES[3]
    restart: unless-stopped
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus:/etc/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
    $CONTAINER_COMMAND

  grafana:
    image: $CONTAINER_IMAGE
    container_name: $CONTAINER_NAMES[4]
    restart: unless-stopped
    ports:
      - "3000:3000"
    volumes:
      - ./grafana:/var/lib/grafana
    $CONTAINER_COMMAND

  # 5. CI/CD runner (Drone)
  drone-server:
    image: $CONTAINER_IMAGE
    container_name: $CONTAINER_NAMES[5]
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      - DRONE_GITEA_SERVER=https://gitea.example.com
      - DRONE_RPC_SECRET=supersecret
      - DRONE_ADMIN=admin
    volumes:
      - ./drone:/data
    $CONTAINER_COMMAND

  # 6. Container registry (Harbor)
  harbor:
    image: $CONTAINER_IMAGE
    container_name: $CONTAINER_NAMES[6]
    restart: unless-stopped
    ports:
      - "5000:5000"
    environment:
      - HARBOR_ADMIN_PASSWORD=admin123
    volumes:
      - ./harbor:/data
    $CONTAINER_COMMAND

  # 7