Skip to content
back to the quest log
Estella infrastructure diagram — on-premise and cloud, load balancing, backups and monitoring
epic⎈ infrastructureinternal

Estella Data Centre

Concrete, cooling, then Kubernetes

Built from an empty room: A+B power, HVAC, structured cabling, VLANs, Proxmox clusters — and a public Arch Linux mirror on top.

role
Senior DevOps Engineer
org
Estella Studio
when
2024 — 2026

What it is

This one started with a floor plan. Rack and stack, redundant A+B power with UPS and PDUs, HVAC and humidity control, structured cabling, then VLANs and L2/L3 routing before a single virtual machine existed.

Above that: Proxmox VE clusters running Windows Server alongside Arch and Debian, an on-prem Kubernetes footprint, and remote access locked behind Tailscale and WireGuard with Nginx terminating in front. Cloudflare proxies the edge; Sora is the load balancer and exit node.

Then the fun part — hosting an official Arch Linux mirror at high-volume uptime, with cron-driven backups landing in object storage and a secondary archive keeping seven rolling copies.

where the effort went

  • Physical96
  • Networking88
  • Reliability85
  • Automation70

the numbers

Power
A + B

UPS + PDU redundant feeds

Hypervisor
Proxmox VE
Backups
7 rolling

cron → object storage

Public service
Arch mirror

built with

  • Proxmox VE
  • Kubernetes
  • Tailscale
  • WireGuard
  • NGINX
  • Cloudflare
  • Prometheus
  • Grafana
  • GitHub Actions
  • Docker
  • Arch Linux
  • Debian

delivery record

What I made

The studio needed an owned compute and network foundation that could support internal workloads and a public mirror without treating the physical room as someone else's problem.

  • 01

    Rack layout, A and B power feeds, UPS, PDUs, cooling, and humidity control

  • 02

    Structured cabling, VLANs, and routed network segments

  • 03

    Proxmox clusters for Windows, Arch, and Debian workloads

  • 04

    On-premises Kubernetes and secured remote administration

  • 05

    Cloudflare and Nginx edge path through the Sora load balancer

  • 06

    Public Arch Linux mirror with rolling off-site backups

Hard problems

The constraints mattered as much as the finished interface.

01field note

Reliability begins before the operating system

problem
Redundant services cannot survive shared power, heat, cabling, or network failure domains.
response
I designed the room, power feeds, cooling, cable plant, and VLAN boundaries before placing compute workloads.
02field note

A public mirror on private infrastructure

problem
High-volume public traffic must not flatten internal services or turn recovery into a local-only process.
response
The mirror uses a controlled edge path, monitoring, and object-storage backups with seven rolling copies.

The rack

Named machines, as they appear in the diagram. Yes, they are all named after something.

  • SoraLoad balancer · exit node
  • acheron-serverOn-prem compute
  • natsuOn-prem node
  • mizuOn-prem node
  • fuyuOn-prem node
  • db-centralDatabase
  • Linux mirrorPublic Arch Linux mirror

Architecture

Drawn as it was built. Open it full size — the labels are the interesting part.

after shipping

What stayed with me

  • The cleanest cluster design cannot compensate for an unplanned physical failure domain.

  • Operating a public service is a practical test of capacity, observability, and restoration procedures.