under development — this site is still work in progress

Robin Miller

IT infrastructure · Networking & security · Virtualization

I look after the IT infrastructure of a private bank in Munich — networking, firewalls, virtualization. At home I run a small datacenter of my own: three servers, a segmented network, everything documented as code. I came to IT as a career changer — no formal IT education, but all the more drive of my own. The fact that I spend my evenings voluntarily doing what I do for a living probably says more about me than any cover letter could.

robin@homelab: ~
Robin Miller

robin@homelab

role: IT Service Specialist — Infra & Virtualization

employer: Merkur Privatbank, Munich

homelab: 3-node Proxmox cluster · 30+ services

stack: OPNsense · VMware · Ansible · Docker

focus: Infrastructure as Code

uptime: in IT since 2018 — enthusiastic for far longer

$ play · ·

Experience

  1. IT Service Specialist — Infrastructure & Virtualization @ Merkur Privatbank KGaA

    01/2022 — today

    Munich, Germany

    • Planning, building and operating the bank's LAN, WAN and WLAN infrastructures
    • Network and security architecture: firewalls (pfSense, Sophos), VPN, DMZ, network segmentation and SIEM
    • Software-defined networking via the LANCOM Management Cloud
    • Virtualized server and storage environments (VMware, SAN) and the Windows Server landscape
    • Patch, change and incident management incl. testing and release; proactive monitoring (PRTG)
    • IT projects focused on infrastructure and network security; technical documentation and emergency procedures

    pfSenseSophosLANCOMVMwareSANWindows ServerPRTGSIEM

  2. IT Organisator (IT operations & organization) @ Merkur Privatbank KGaA

    10/2020 — 12/2021

    Munich, Germany

    • Introduction of the bank's private inhouse cloud — migrating the servers from bare metal to VMware, incl. planning, configuration and regular system checks
    • Planning and administration of server rooms, SAN storage networks (DataCore) and VMware environments
    • Building out WAN (primary and secondary links), LAN, WLAN, VPN and the bank's firewall
    • Backup concept incl. controls and restore verification; proactive monitoring (PRTG)

    VMwareDataCorePRTG

  3. IT Administrator @ VR-Bank Memmingen eG

    01/2018 — 09/2020

    Memmingen, Germany

    • Administration of Windows servers and clients, mobile devices and Citrix
    • Operating the datacenter banking applications; disaster recovery planning and system restart procedures
    • Deputy to the head of IT; point of contact in the user helpdesk
    • In parallel: trainee in project lead / project management (05/2019 – 01/2020): intranet platform "VR-WIKI", successful rollout in spring 2020

    Windows ServerCitrix

  4. Apprenticeship & bank clerk @ VR-Bank Memmingen eG

    09/2013 — 12/2017

    Memmingen, Germany

    • Apprenticeship as a bank clerk (Bankkaufmann, until 01/2016), then worked as a bank clerk — 2018 brought the career change into IT

Skills & technologies

Networking & security

  • Firewalls (pfSense, Sophos, OPNsense)
  • Network segmentation: VLANs, DMZ
  • VPN & site connectivity (WAN)
  • SIEM & security monitoring
  • LANCOM Management Cloud (SD networking)
  • Reverse proxies (Traefik, Caddy) & WAF
  • DNS (split-horizon), SSO / OIDC

Virtualization & servers

  • VMware vSphere
  • Proxmox VE
  • Windows Server
  • Linux (Debian)
  • LXC & Docker Compose
  • Storage: SAN (DataCore), ZFS
  • Backup: Proxmox Backup Server, backup concepts

Automation & IaC

  • Ansible
  • GitOps deployments (Komodo)
  • OpenTofu / Terraform
  • Git & CI/CD (Forgejo Actions)
  • Secrets management (SOPS / age)
  • Bash / scripting

Operations & processes

  • Monitoring & alerting (PRTG, self-hosted stack)
  • Patch, change & incident management
  • Technical documentation & emergency concepts
  • IT projects focused on infrastructure & network security

Homelab

My homelab is my laboratory: it's where I try technologies before I take them seriously, and where I host everything I can host myself. It runs in production for the whole family — so outages get noticed.

Cluster nodes
3 × Proxmox VE (HA)
Services
30+ self-hosted
Backup
Proxmox Backup Server, versioned
Docs
100% as a Git repo (docs as code)

Projects

Homelab: Proxmox cluster

Self-built 3-node Proxmox cluster with HA, separate VLANs, a dedicated firewall, central backup and 30+ self-hosted services — fully documented as a Git repository.

ProxmoxOPNsenseDockerZFSPBS

Infrastructure as Code

Step-by-step migration of the homelab to declarative provisioning: OpenTofu creates the containers, Ansible configures them, Komodo deploys the Docker Compose stacks straight from the Git repo via GitOps — CI checks every change.

OpenTofuAnsibleDocker ComposeKomodoForgejo ActionsSOPS

From the engine room

Three short excerpts from my homelab repository — rewritten and anonymized for publication, but true to structure and style. Expand to read.

LXC updates with a safety net yaml

Ansible playbook (excerpt): all containers update in batches; after the upgrade a health check probes the Docker stack — failing hosts are held for review instead of rolling on.

- name: Update LXC containers in controlled batches
  hosts: lxc_all
  serial: 5
  tasks:
    - name: Apply pending upgrades
      ansible.builtin.apt:
        update_cache: true
        upgrade: dist

    - name: Health check — compose stack still running?
      ansible.builtin.command: docker compose ps --status running -q
      args:
        chdir: /opt/{{ service_name }}
      register: health
      changed_when: false
      failed_when: health.stdout == ""

    - name: Hold host for manual review instead of rolling on
      ansible.builtin.file:
        path: /var/lib/updates/hold/{{ inventory_hostname }}
        state: touch
      when: health is failed
A container as code hcl

How a new LXC comes to life: one OpenTofu module call. The conventions (template, unprivileged, backups, delete protection) are enforced by the module — not by caller discipline.

module "webapp01" {
  source = "./modules/lxc-standard"

  hostname    = "webapp01"
  vmid        = 4210
  ip_address  = "192.0.2.10/24"   # documentation range — real IPs stay private
  gateway     = "192.0.2.1"
  target_node = "node01"
  cores       = 2
  memory_mb   = 2048
  disk_gb     = 16

  # the module enforces the conventions, not the caller:
  # Debian 12 template, unprivileged, onboot, firewall on,
  # backups scheduled, prevent_destroy unless marked otherwise
  tags        = ["docker", "web"]
  destroyable = false
}
Nightly drift detection bash

The Git repo is the truth: a timer compares the live cluster against the inventory and reports deviations via push notification.

#!/usr/bin/env bash
# Nightly: is the live cluster still what the Git repo says it is?
set -euo pipefail

repo=/opt/homelab
"$repo/scripts/collect/guests.sh" > "$repo/inventory/guests.yml"

cd "$repo"
if git diff --quiet -I '^# generated:' -- inventory/; then
  exit 0                     # no drift — stay silent
fi

git diff --stat -- inventory/ | tail -1 \
  | curl -s -H "Title: inventory drift detected" -H "Priority: high" \
      -d @- "https://ntfy.example.org/alerts"

How I work

At work

Calm during incidents

Keep the overview under pressure, prioritize in a structured way, communicate clearly — things get hectic on their own.

Changes with a safety net

Patch, change and incident management with testing and release — changes to production systems need a way back.

Clean handovers

Technical documentation and emergency procedures are written with the change — not someday after.

In the homelab

Docs as code

Every decision, every runbook, every inventory lives versioned in a Git repo. What isn't documented doesn't exist.

Security by default

Hardened containers, minimal privileges, encrypted secrets, no direct access from outside.

Automate instead of repeat

Anything done manually twice becomes a script, a playbook or a pipeline the third time.

Understand first, then build

New technologies are evaluated in the lab, documented, and only then put into production.

Contact

E-mail is the fastest way to reach me.