So I Got This From Work

So I Got This From Work

Introduction

You’ve just brought home a beast of a workstation – an EPYC‑powered beast with 64 cores, 128 GB of ECC memory, a beefy RTX 3070, and a modest 500 GB SSD. In the office it was humming away rendering high‑resolution frames for Keyshot, but now it sits on your desk, idle most days. The natural question that follows is: what else can I do with this machine?

For homelab enthusiasts, DevOps engineers, and self‑hosted aficionados, an idle workstation is a golden opportunity. It offers more than just raw CPU cycles; it provides a sandbox for experimenting with container orchestration, monitoring stacks, CI/CD pipelines, and a host of other infrastructure services that would otherwise require multiple cheap servers or expensive cloud instances.

In this guide we’ll walk through a systematic approach to transform that dormant workstation into a versatile, production‑ready platform. You’ll learn:

• How to assess the hardware and plan a suitable workload mix.
• Which open‑source tools fit naturally into a self‑hosted environment.
• Step‑by‑step installation and configuration of a Docker host, a Prometheus‑Grafana monitoring stack, a GitLab Runner, and a WireGuard VPN gateway.
• Strategies for securing, optimizing, and maintaining the system over time.

By the end, you’ll have a clear roadmap for turning that “just‑sitting‑there” box into the backbone of your personal homelab, all while keeping the solution entirely self‑hosted and free of vendor lock‑in.

Keywords: self‑hosted, homelab, DevOps, infrastructure automation, open‑source, containerization, monitoring, CI/CD, VPN

---

Understanding the Topic

What Are We Talking About?

The core concept is repurposing an underutilized high‑performance workstation for a variety of DevOps‑centric services. Rather than letting the hardware collect dust, you can allocate its resources to run multiple containers or virtual machines, each serving a distinct function:

• Rendering workloads (e.g., occasional Keyshot jobs) – keep the GPU active on demand.
• Container host – run Docker or Podman to host isolated services.
• Monitoring stack – deploy Prometheus for metrics collection and Grafana for visualization.
• CI/CD runner – use GitLab Runner or Jenkins X for automated builds.
• Network services – host a WireGuard endpoint, DNS resolver, or DHCP server.

Each of these components leverages a different slice of the hardware’s capabilities, allowing you to maximize utilization without over‑provisioning.

Historical Context

The practice of converting surplus server hardware into homelab nodes dates back to the early 2010s when enthusiasts began salvaging decommissioned rack units. With the rise of Docker (2013) and Kubernetes (2015), the barrier to entry lowered dramatically. Today, a single workstation can host an entire microservices ecosystem, something that would have required a small rack a decade ago.

Key Features of a Modern Homelab

Feature	Why It Matters	Typical Implementation
High core count	Enables parallel execution of containers, VMs, and build jobs	Allocate CPU pinning per service
Large RAM	Prevents swapping, supports memory‑intensive workloads (e.g., databases)	Reserve memory quotas via cgroups
Dedicated GPU	Accelerates rendering, ML inference, or GPU‑based monitoring	Pass through to Docker containers using NVIDIA runtime
Fast SSD	Reduces I/O latency for database and log storage	Use as persistent volume for Docker
ECC Memory	Improves reliability for long‑running services	Enable ECC in BIOS, monitor with ipmitool

Pros and Cons

Pros

• Cost‑effective – no recurring cloud fees.
• Full control over networking, security, and updates.
• Ability to experiment with cutting‑edge technologies (e.g., service meshes).

Cons

• Power consumption – ensure adequate UPS and cooling.
• Physical footprint – may require a dedicated rack or shelf.
• Maintenance overhead – hardware failures can be more impactful.

Real‑World Use Cases

• DevOps sandbox – test Kubernetes clusters with Kind or Minikube.
• Media server – run Plex or Jellyfin for personal video library.
• Development environment – host GitLab CE for private repositories.
• Network services – operate a local DNS ad‑blocker (Pi-hole) and DHCP server.

---

Prerequisites

Before you start installing services, verify that the workstation meets the baseline requirements for each component you intend to run.

Hardware Checklist

Component	Minimum Requirement	Recommended Specification
CPU	8‑core, 64‑bit	EPYC 7713, 64 cores, 2.8 GHz base
RAM	16 GB	128 GB ECC DDR4
Storage	100 GB free	500 GB NVMe (or SATA) SSD
GPU	DirectX 12 / OpenGL 4.5 compatible	RTX 3070 (or newer)
Network	Gigabit Ethernet	10 GbE optional for future scaling
Power	500 W PSU	80 Plus Gold, redundant if possible

Software Stack

Layer	Recommended Version	Notes
Operating System	Ubuntu Server 22.04 LTS	Long‑term support, stable kernel
Docker Engine	24.0.x	Use the official Docker APT repository
Kubernetes (optional)	v1.28	For advanced orchestration
Prometheus	2.53	Official release binaries
Grafana	10.4	OSS edition
GitLab Runner	16.9	Docker executor for CI pipelines
WireGuard	1.0.20240130	Kernel module + userspace tools

Network & Security Considerations

• Static IP – Assign a permanent address (e.g., 192.168.1.10) to avoid DHCP churn.
• Firewall – Enable ufw or iptables with a default deny policy, then open only required ports (e.g., 22 for SSH, 80/443 for web UI).
• SSH Hardening – Disable root login, enforce key‑based authentication, and consider Fail2Ban for brute‑force protection.
• Backup Strategy – Schedule regular snapshots of critical Docker volumes using restic or borg.

Pre‑Installation Checklist

1. Update the OS: sudo apt update && sudo apt upgrade -y.
2. Install prerequisite packages: sudo apt install -y curl gnupg2 lsb-release apt-transport-https.
3. Verify virtualization support: grep -E '(vmx|svm)' /proc/cpuinfo – should return a line.
4. Confirm GPU drivers: nvidia-smi – driver version ≥ 525 for RTX 3070.
5. Create a non‑root admin user: sudo adduser devops && sudo usermod -aG sudo devops.

---

Installation & Setup

Below is a step‑by‑step walkthrough for turning the workstation into a multi‑service platform. Each section includes the exact commands, configuration snippets, and verification steps.

1. Installing Docker Engine

Docker remains the simplest way to isolate services while still leveraging the host’s resources.

# Add Docker’s official GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# Set up the stable repository
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Update apt and install Docker
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io

# Verify installation
docker version

Explanation of Key Steps

• GPG key – Ensures package authenticity.
• Repository line – Uses $(lsb_release -cs) to target the correct Ubuntu codename.
• containerd.io – Required for newer Docker releases.

2. Configuring Docker Daemon

Create a daemon configuration that limits resource usage and enables GPU access.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "default-runtime": "runc",
  "runtimes": {
    "nvidia": {
      "path": "nvidia-container-runtime",
      "runtimeArgs": []
    }
  },
  "experimental": true,
  "resourceConstraints": {
    "cpuQuota": 128000,
    "memory": 90%
  }
}

Save this as /etc/docker/daemon.json and restart Docker:

sudo systemctl restart docker

GPU Access – Install the NVIDIA Container Toolkit:

distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list
sudo apt update
sudo apt install -y nvidia-docker2
sudo systemctl restart docker

3. Deploying a Prometheus‑Grafana Monitoring Stack

We’ll use Docker Compose to spin up Prometheus and Grafana.

Create a directory for the stack:

mkdir -p ~/homelab/monitoring && cd ~/homelab/monitoring

Create a docker-compose.yml file:

version: "3.8"

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: $CONTAINER_NAMES-prometheus
    restart: unless-stopped
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus_data:/prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.path=/prometheus"
      - "--web.enable-admin-api"

  grafana:
    image: grafana/grafana:latest
    container_name: $CONTAINER_NAMES-grafana
    restart: unless-stopped
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin123
    depends_on:
      - prometheus

volumes:
  prometheus_data:
  grafana_data:

Key Points

• $CONTAINER_NAMES is a placeholder for actual container names; replace with something meaningful like monitoring-prometheus and monitoring-grafana.
• Persistent volumes (prometheus_data, grafana_data) ensure data survives container restarts.

Apply the stack:

docker compose up -d

Verify:

docker ps -a

You should see both containers in Up state. Access Grafana at `http://:3000