Montar un homelab desde cero: la visión general - Homelab (01/06)

Quieres montar un homelab. A lo mejor estás harto de pagar suscripciones mensuales por servicios que podrías alojar tú mismo. A lo mejor quieres entender cómo funciona la infraestructura de verdad — no leyendo un libro, sino rompiendo cosas a las 2 de la mañana y aprendiendo a arreglarlas. O simplemente te gusta la idea de tener tu propio rincón de internet.

Sea cual sea el motivo, en esta serie voy a contar cómo monté el mío: una mezcla de servidores en casa y nodos VPS en la nube, conectados por VPN, corriendo desde clústeres de Kubernetes hasta domótica. No hace falta experiencia previa en infraestructura — cada acrónimo queda explicado la primera vez que aparece.

En este primer post toca ver el panorama completo. El hardware, el esquema de nombres (sí, hay un tema), qué corre dónde y cómo se conecta todo. Los tres posts siguientes entrarán a fondo en redes, Kubernetes y GitOps, y seguridad y operaciones.

Vamos a ello.

¿Por qué montar un homelab?

Tres razones que me fueron empujando:

1. Soberanía. Si alojas tú los servicios, los datos son tuyos. Ningún proveedor puede cambiar precios, cerrar un producto o bloquearte la cuenta. Tus servicios corren bajo tus reglas.

1. Aprendizaje. No hay mejor forma de entender redes, contenedores, orquestación y operaciones que gestionarlos tú mismo. Depurando un DNS roto en casa aprendes más que con cualquier curso de certificación.

1. Correr tus propios proyectos. Yo tengo zetesis.xyz — un portal web con autenticación, búsqueda de texto completo y un servidor MCP (Model Context Protocol) — corriendo íntegramente en mi infraestructura. Sin facturas de nube que escalen con el tráfico. Sin dependencia de ningún proveedor.

El hardware

El homelab se reparte entre dos ubicaciones físicas conectadas por internet, más unos cuantos VPS (Virtual Private Server) en la nube para servicios de borde. Esto es lo que hay:

En casa: 4 nodos Proxmox

Proxmox VE es un hipervisor libre y de código abierto — básicamente, software que permite correr varias máquinas virtuales (VMs) y contenedores en un solo servidor físico. Tengo cuatro:

Nodo — Red — Función

marco-aurelio — Atenas (10.1.0.0/24) — VMs: router VyOS, host Docker, domótica

socrates — Atenas (10.1.0.0/24) — VMs de apoyo

pitagoras — Roma (10.0.0.0/24) — VMs: router VyOS, host Docker (reverse proxy, dashboard)

platon — Roma (10.0.0.0/24) — Clúster Kubernetes (cortes)

En casa: un nodo bare metal

Los clústeres no viven solo en VMs. pizarro es un Lenovo ThinkCentre M920q que corre Talos directamente sobre el metal — sin hipervisor de por medio — y aloja el segundo clúster Kubernetes, en su propia red de plataforma dentro de Roma.

En casa: almacenamiento TrueNAS

spinoza es un TrueNAS en la red Atenas (10.1.0.11). Corre MinIO, un servicio de almacenamiento de objetos compatible con S3. Todos los servidores del homelab hacen backup a spinoza — es la capa de almacenamiento central.

Nube: servidores VPS

Hay cosas que tienen más sentido en la nube — servicios que necesitan una IP pública con baja latencia, o nodos de borde que se sitúan entre Cloudflare y el homelab:

VPS — Función

von-braun — Reverse proxy principal (Caddy), túnel Cloudflare, backups

escohotado — Aplicaciones web, foros, autenticación, búsqueda, CMS

unamuno — Foros, túnel Cloudflare, backups

Los nombres

Habrás notado un patrón. Cada máquina, VM, servicio y clúster tiene un nombre sacado de la historia:

Los nodos Proxmox van con filósofos: marco-aurelio, socrates, pitagoras, platon. Los VPS con pensadores y escritores: von-braun (el ingeniero de cohetes), escohotado, unamuno. Los clústeres Kubernetes llevan nombres de conquistadores: cortes (Hernán Cortés) y pizarro (Francisco Pizarro). Los servicios siguen la misma línea: ptolomeo para el agente de CD, tolstoi para backups, cervantes para las pasarelas S3, kepler para el dashboard, rothbard y mises para la domótica. Y las redes van con ciudades antiguas: Atenas y Roma.

¿Es demasiado? Puede. Pero cuando llevas un rato mirando un terminal a medianoche, ayuda que cada nombre te diga algo. Los filósofos alojan cosas, los exploradores descubren territorio nuevo y los escritores cuentan historias.

Arquitectura general

Así se conecta todo. Las dos redes locales (Atenas y Roma) están unidas por un túnel WireGuard entre sus routers. Los VPS se unen al homelab a través de Tailscale, una VPN en malla. El tráfico de internet entra por Cloudflare.

Algunas cosas a tener en cuenta:

Cloudflare se pone delante de todo lo público. Gestiona DNS, protección DDoS y caché. von-braun es el punto de entrada principal — corre Caddy (un reverse proxy) con CrowdSec (un sistema de detección de intrusiones) y enruta tráfico hacia el homelab a través de Tailscale. WireGuard conecta las dos redes físicas: los routers VyOS (temistocles y constantino) mantienen un túnel cifrado permanente entre Atenas y Roma. Y Tailscale es una VPN en malla construida sobre WireGuard; los VPS la usan para alcanzar servicios internos sin exponer puertos a internet. spinoza también anuncia rutas a través de Tailscale para que los servidores remotos puedan hacer backup hacia él.

Todo esto lo veremos en detalle en el Post 2: Redes.

Qué corre dónde

Un repaso rápido de lo que hay en cada parte de la infraestructura.

Kubernetes: pizarro (Roma)

El clúster de plataforma: los servicios que sostienen a todo lo demás. Corre sobre Talos Linux en el nodo bare metal — sin hipervisor, un sistema operativo mínimo e inmutable diseñado específicamente para Kubernetes:

• Infisical — Gestor de secretos autoalojado (como HashiCorp Vault, pero más sencillo)
• Harbor — Registro privado de imágenes de contenedores y charts
• Observabilidad — Prometheus, Grafana, Loki y Tempo: la telemetría de toda la flota termina aquí
• ArgoCD — Despliegue continuo GitOps para Kubernetes
• Traefik — Controlador ingress (enruta tráfico HTTP a los pods)
• K8up — Operador de backup (snapshots a MinIO en spinoza)

Kubernetes: cortes (Roma)

Dedicado a correr zetesis.xyz. Separado de pizarro para que la aplicación de cara al usuario no comparta recursos con la plataforma:

• Zetesis Portal — La aplicación web (producción)
• Zetesis-Auth — Gestión de identidad y acceso (Keycloak standalone, login, SSO)
• Typesense — Motor de búsqueda de texto completo
• CNPG PostgreSQL — Operador de PostgreSQL cloud-native (gestiona la base de datos)
• Servidor MCP — Servidor Model Context Protocol para integraciones con IA

VMs Docker: aristoteles (en ambas redes)

Hay una VM llamada "aristoteles" en cada red, corriendo servicios Docker con Docker Compose:

aristoteles en pitagoras (Roma):

• colon — Reverse proxy Caddy para la red local
• kepler — Dashboard Homepage (página central de estado)
• marco-polo — DDNS de Cloudflare + túnel

aristoteles en marco-aurelio (Atenas):

• rothbard — Zigbee2MQTT + Mosquitto (puente de domótica)
• mises — Homebridge (integración con Apple HomeKit)
• dijkstra — Servicios adicionales

Servidores VPS

Los nodos VPS en la nube se encargan del enrutamiento de borde y alojan algunas aplicaciones web. von-braun corre Caddy (reverse proxy + CrowdSec), un túnel Cloudflare y agentes de backup. escohotado tiene aplicaciones web, Keycloak, PostgreSQL, Ghost CMS, Typesense y foros. unamuno corre foros, un túnel Cloudflare y agentes de backup.

Backup: tolstoi (en todas partes)

Cada servidor corre un servicio llamado tolstoi — un agente de backup Restic que envía datos a MinIO en spinoza a través de una pasarela Tailscale (llamada cervantes). Los clústeres Kubernetes usan K8up en su lugar, pero el destino es el mismo: spinoza.

Dos sistemas de CD

Todo el homelab se despliega desde un único repositorio Git. Push a main y está en producción. Pero hay dos sistemas distintos gestionando el despliegue, porque Docker Compose y Kubernetes son animales muy diferentes:

ptolomeo (Docker Compose)

Para los hosts VPS y las VMs, un agente ligero llamado ptolomeo (basado en doco-cd) consulta el repositorio Git cada 180 segundos. Cuando detecta cambios, ejecuta docker compose up en el directorio correspondiente. Cada host tiene un .doco-cd.yaml que le dice a ptolomeo qué vigilar:

# Ejemplo: .doco-cd.yaml en vps-von-braun
name: colon
reference: refs/heads/main
working_dir: vps-von-braun/colon
external_secrets:
  CF_API_TOKEN: 893d53fb-...:prod:/colon/CF_API_TOKEN
  CROWDSEC_API_KEY: 893d53fb-...:prod:/colon/CROWDSEC_API_KEY

La sección external_secrets obtiene secretos de Infisical en el momento del despliegue — así no hay contraseñas almacenadas en Git.

ArgoCD (Kubernetes)

Para los clústeres Kubernetes, ArgoCD vigila el mismo repositorio Git y sincroniza los manifiestos de Kubernetes automáticamente. Cada clúster tiene un bootstrap.yaml que usa el patrón App-of-Apps — una aplicación "padre" que gestiona todas las aplicaciones hijas:

# Ejemplo simplificado: talconfig.yaml (definición del clúster Talos)
clusterName: cortes
talosVersion: v1.12.4
kubernetesVersion: v1.35.0
endpoint: https://10.0.0.110:6443
allowSchedulingOnControlPlanes: true

cniConfig:
  name: none  # Usamos Cilium en su lugar

nodes:
  - hostname: cortes
    ipAddress: 10.0.0.110
    controlPlane: true
    installDisk: /dev/sda

Esto es una configuración de Talos Linux — define todo el clúster de forma declarativa. El sistema operativo, la versión de Kubernetes, el plugin de red, las IPs de los nodos — todo en un fichero YAML dentro de Git.

Profundizaremos en ambos sistemas de CD en el Post 3: Kubernetes y GitOps.

Anticipo de las redes

Las redes merecen su propio post (es el siguiente), pero la versión corta es esta: dos redes físicas (Atenas y Roma) conectadas por un túnel WireGuard sitio a sitio. Routers VyOS (temistocles y constantino) que gestionan DHCP, DNS, BGP, reglas de firewall y el túnel. Tailscale como overlay VPN en malla para que los VPS alcancen servicios internos sin abrir puertos. Cloudflare para DNS público y protección DDoS. Y Caddy (en von-braun y los reverse proxies locales) terminando TLS y enrutando tráfico.

El recorrido de una petición pública a zetesis.xyz queda así:

Usuario -> Cloudflare -> Caddy (von-braun) -> Tailscale WireGuard -> Traefik (cortes) -> Pod

Ningún puerto abierto en la red de casa. Todo pasa por túneles de Tailscale.

Lo que viene

Esta era la vista a vuelo de pájaro. En los tres posts siguientes entramos a fondo:

Post 2: Redes — Cómo encajan WireGuard, Tailscale, Cloudflare y Caddy. Configuración de los routers VyOS, BGP entre los clústeres y el borde, subredes y DNS. Por qué no se reenvía ningún puerto. El recorrido completo del tráfico, del usuario al pod.

Post 3: Kubernetes y GitOps — Talos Linux, ArgoCD, el patrón App-of-Apps, ptolomeo para hosts Docker, y cómo un solo push a Git despliega en todos los servidores.

Post 4: Seguridad y operaciones — Tres capas de gestión de secretos (Infisical, SOPS, ESO). Estrategia de backup con Restic y MinIO. Domótica con Zigbee2MQTT y HomeKit.

Si estás pensando en montar un homelab, espero que esto te dé una idea de lo que se puede conseguir. No hace falta tener todo esto desde el primer día — yo desde luego no empecé así. Empieza con un servidor, un servicio, y ve creciendo.

Nos vemos en el Post 2.

Esta serie documenta la arquitectura detrás de la infraestructura que hace funcionar zetesis.xyz. Todo el código vive en un único repositorio GitOps. Ningún proveedor de nube resultó herido durante la creación de este homelab.