Get in touch →
The Dell PowerEdge T160 that runs most of Albgott

MY PRIVATE CLOUD,
BUILT AND RUN AT HOME.

I'm Alberto, a software engineer. Albgott is where my projects and my clients' projects actually run: three Proxmox nodes built from hardware I already had, eight isolated networks and 38 services, including the pipeline that deployed this page.

See how it's builtHow it started
Services in production
38
Network segments
08
Operated since
2023
Monitored
24/7

It began with a €300 AWS bill for machines I'd forgotten to turn off. The fix looked obvious: run things myself, on a couple of old laptops that never slept.

The cheap fix turned into the expensive lesson. Starting a service is easy. Keeping it up, reachable and boring is a different job, and three years and a few rebuilds later, that job is what this site is about.

Every page below is the real setup, written the way I'd explain it to someone taking it over from me.

  • Compute03 NODES
  • Network08 SEGMENTS
  • Workloads38 SERVICES
  • ObservabilityFULL STACK · 24/7
  • AutomationMOSTLY BY HAND
01 · Principles

Three rules I didn't start with

01

Architecture

One flat network was fine until it wasn't. Now every service gets a VLAN before it gets an IP, and that VLAN decides what it can reach.

Read more →02

Security

Connecting isn't the same as being allowed. A VPN gets a device as far as the router; a firewall rule written for that exact flow decides everything after.

Read more →03

Operations

If a client is the one telling me something is down, monitoring has failed. Alerts reach my phone first, and every new host reports metrics before it runs anything.

Read more →
02 · SystemFull breakdown →

Three nodes, eight networks

Compute
pve01pve02pve03
Network
Publicingress
Internalapps
Datastateful
CIbuild
Backuprestricted
Corpwork
Mgmtadmin
Homeuser
Access
AdministratorsDevelopers

Choices that
cost me something

All three make day-to-day work slower. All three keep a mistake in one place from becoming a problem everywhere.

  • 01
    Hardware matched to the job
    The 64 GB tower holds the databases and the public traffic. The laptop only runs things I can rebuild.
  • 02
    No trust between internal networks
    Two VLANs can't talk just because both are mine. Every allowed flow is a named rule on the MikroTik.
  • 03
    One VPN per role
    Collaborators use one WireGuard tunnel and administration uses another, so a lost phone on the first one can't reach a hypervisor.
03 · SecurityFull breakdown →

If there's no rule for it, it doesn't connect.

How the router decides
Flowchart: invalid packets are dropped, established connections allowed, anything without an explicit rule dropped.

How access
is decided

Being on the network doesn't mean being allowed to use it. Three boundaries do most of the work:

  • 01
    Default deny, explicit allow
    Every flow between networks is a RouterOS rule with a source list, a destination list and a port. Anything else gets dropped.
  • 02
    Three proxies for three audiences
    Public traffic, internal tools and hardware consoles each come in through their own Caddy instance. Getting into one doesn't open the other two.
  • 03
    Identity, halfway there
    Authentik with MFA guards the monitoring stack today. The rest of the services are moving behind it one at a time.
04 · OperationsSee operations →

SCRAPED EVERY 15s.LOGS KEPT 30 DAYS.ALERTS ON MY PHONE.

Metrics, logs and outside-in checks each answer a different question, and all three end up in the same Telegram chat. The goal is simple: I find out first.

PROMETHEUSGRAFANALOKIJENKINSUPTIME KUMAALERTMANAGER
PROMETHEUSGRAFANALOKIJENKINSUPTIME KUMAALERTMANAGER
05 · RoadmapFull roadmap →

What's still missing

20/ 41 items done

Backups. There aren't any yet, and everything stateful lives on a single 8 TB disk. It's first on the list, which is why a NAS is the next thing I'm buying.

  • ✓Split the network into isolated VLANs
  • ✓CI/CD pipeline with Jenkins and Harbor
  • ✓Metrics, logs and alerts for the whole stack
  • Put every service behind SSO
  • Automated, tested backups
  • Keep monitoring alive when a node dies
  • Move the hardware into a proper rack
06 · AboutThe rest of the story →

Running it myself was supposed to be the cheap option.

It wasn't, but it's been the best teacher I've had. The full story, including the day a client found an outage before I did, is on the about page.

Alberto Morán

Built by Alberto Morán, Software Engineer

GOT SOMETHING THAT CAN'T GO DOWN?

If you're building infrastructure or a service that has to keep working after launch day, tell me about it. I like working through the hard parts.

Get in touch →