Infrastructure

Albgott

Albgott is the infrastructure everything else I build runs on — a self-hosted private cloud I've operated since 2023: three nodes, eight isolated network zones, and more than thirty services, run with the same discipline I'd want from a platform team at work, with nobody to page but myself.

  • Self-hosted
  • Proxmox
  • Docker
  • Jenkins
  • Prometheus
  • Grafana
  • WireGuard
The hardware behind more than thirty services, split across three nodes and eight isolated networks.

Nothing shares a layer without a reason

Traffic doesn't sit on one flat network — it's split into eight zones, from public ingress down to a management plane reserved for the hardware itself. Compute is split the same way, across three Proxmox nodes with different jobs, running at a fraction of what they could handle. The point isn't to fill the hardware — it's that a problem in one zone should never become a problem in the others.

Eight zones instead of one flat network — public, internal, data, CI, backup, corporate, management, and home.

Default deny, explicit everything

Being on the network isn't the same as being allowed to use it. Every connection is denied unless a rule explicitly allows it, and three reverse proxies enforce that as trust tiers: one reachable from the open internet, one from anything inside the network, and one — the console into the hypervisors and switches — reachable only from a separate admin VPN tunnel that the everyday remote-access tunnel is never allowed to touch. Identity runs through Authentik, secrets through Infisical, and every credential a deployment needs — SSH keys, webhook tokens, an SMTP password, a Telegram bot token — lives there instead of in a config file, though moving every last service onto that is still in progress.

Every packet is evaluated against the same two questions before it's allowed anywhere.

A push becomes a deployment, unattended

A git push is the only manual step. Jenkins checks out the code, builds and tags a container image, pushes it to a private registry, deploys it, and runs a health check against the live URL — start to finish in under three minutes. The last stage posts to a Telegram bot with the commit hash, the commit message, who pushed it, and the list of files that changed, so I know a deploy happened before I'd have thought to check.

Checkout to health check in under three minutes — no step run by hand.
The deploy notification: commit, author, live URL, and every changed file — sent the moment the pipeline finishes.

Every layer, watched by something else

Every container exports metrics to Prometheus and logs to Loki, and gets scraped independently by Uptime Kuma, which doesn't rely on the same stack it's checking. Alertmanager watches Prometheus and routes anything that matters straight to Telegram; Grafana ties the metrics and logs together into one place to look.

Metrics, logs, and uptime checks, each with its own path to an alert.
48 monitors across six categories — and the log shows the real outages, not a scrubbed one.

None of it prevents outages — the event log above shows real ones, services flapping down and back up on their own timeline. What it does is guarantee I find out before a client or a script depending on it does.