Si hoy tuviera que montar un homelab pequeño desde cero para una casa normal, no empezaría por Kubernetes. Tampoco por Ceph, alta disponibilidad ni un rack con luces que parezca la cabina de un avión. Empezaría por una pregunta bastante menos sexy: qué datos no quiero perder y qué servicios necesita realmente mi familia.
Esa pregunta cambia todo. El homelab de internet suele estar diseñado para enseñar capturas. El homelab de una casa debería estar diseñado para no molestar, no perder fotos, no romper internet y no convertirse en otro trabajo administrativo. Hay una diferencia enorme entre “quiero aprender infraestructura” y “quiero que las fotos de mi hija estén seguras”. Las dos cosas pueden convivir, pero no deberían tener la misma prioridad.
Mi error al principio, como el de casi todos, fue pensar en herramientas antes que en necesidades. Proxmox, Docker, NAS, VPN, dashboards, monitorización, DNS, backups. Todo parece importante cuando lo miras por separado. El problema es que si juntas demasiadas piezas demasiado pronto, acabas montando un sistema que solo tú entiendes y que además te mira mal cada vez que quieres cambiar algo.
Para una casa, yo diseñaría el homelab al revés: primero los datos, luego la red, después los servicios y al final el laboratorio.
Lo que de verdad importa en una casa#
En una casa normal hay pocas cosas digitales realmente críticas.
Las fotos y vídeos familiares son lo primero. No porque sean técnicamente complejos, sino porque son irremplazables. Si pierdes una biblioteca de películas, fastidia. Si pierdes fotos familiares de años, eso ya no se arregla con una tarde de descargas.
Después vienen documentos: DNI escaneado, contratos, facturas, documentación médica, papeles del coche, cosas del colegio, garantías. No ocupan mucho, pero cuando hacen falta hacen falta de verdad.
Luego está la red. Si internet falla porque montaste una arquitectura demasiado lista, el homelab deja de parecer divertido. En una casa, la red tiene que ser aburrida. DNS estable, WiFi fiable, acceso remoto razonable y cero experimentos raros en la ruta principal si no tienes plan de vuelta.
Y por último están los servicios útiles: gestor de contraseñas, automatización de casa, recetas, monitorización, quizá un servidor multimedia, quizá un lector RSS, quizá un sitio donde guardar enlaces. Todo eso está bien, pero no todo merece categoría de infraestructura crítica.
La arquitectura que montaría#
Para un homelab familiar pequeño usaría una arquitectura de tres capas.
La primera capa sería el núcleo doméstico. Un NAS o servidor principal con almacenamiento fiable, backups locales y servicios básicos. No tiene que ser enorme. Tiene que ser entendible.
La segunda capa sería un mini PC eficiente para servicios y automatizaciones. Algo silencioso, con bajo consumo, suficiente RAM y SSD. Aquí pondría Docker o una VM con Docker. Nada heroico. Lo importante es que pueda correr servicios pequeños sin tocar el almacenamiento principal todo el tiempo.
La tercera capa sería el laboratorio. Otro mini PC, una VM, o incluso el mismo equipo pero claramente separado. Aquí puedes romper cosas. Probar Kubernetes. Montar un proxy nuevo. Aprender Ansible. Lo que quieras. Pero si lo rompes, no debería llevarse por delante las fotos, los documentos o la red de casa.
La separación puede ser física o lógica. Lo importante es que exista. Si tu laboratorio y tu producción doméstica son la misma sopa, cualquier tarde de aprendizaje puede acabar en bronca familiar porque el WiFi hace cosas raras.
Hardware: menos épica y más sentido común#
Para este tipo de homelab no compraría un servidor rack. Casi nunca. Son baratos de segunda mano, sí, pero el ruido, el consumo y el calor los hacen bastante poco domésticos. Si tienes garaje, rack cerrado y ganas, adelante. Para un piso o despacho compartido, no me compensan.
Mi base sería algo así:
| Pieza | Qué buscaría | Por qué |
|---|---|---|
| NAS o servidor de almacenamiento | 2 a 4 bahías, discos reemplazables, snapshots o backups claros | Datos familiares y copias |
| Mini PC de servicios | CPU moderna de bajo consumo, 16 a 32 GB RAM, NVMe | Docker, automatizaciones, apps ligeras |
| SAI pequeño | Capaz de aguantar apagado limpio | Evitar corrupción por cortes |
| Disco externo o segundo destino | USB, otro NAS o copia remota | Backup fuera del equipo principal |
| Switch sencillo | VLANs si las vas a usar de verdad | Red estable sin complicarse |
No hace falta acertar con la máquina perfecta. Hace falta no comprar una máquina absurda para el problema. Un mini PC moderno puede correr muchísimos servicios caseros. Un NAS decente puede guardar datos años. Un SAI pequeño puede ahorrarte disgustos. Un buen backup vale más que otro nodo en el cluster.
Sistema operativo: elegir por responsabilidad, no por moda#
Aquí hay varias rutas razonables.
Unraid me gusta mucho cuando quieres NAS, Docker sencillo y una experiencia cómoda. Para una casa, tiene mucho sentido si aceptas pagar la licencia. Es fácil añadir discos de distintos tamaños, la comunidad tiene plantillas para casi todo y no te obliga a pensar como un administrador de sistemas para cada cambio pequeño.
Proxmox me gusta cuando quieres virtualización seria, snapshots de VMs, separación clara y margen para aprender. Pero no lo usaría como primera respuesta para todo. Proxmox no es un NAS doméstico por defecto. Puede hacerlo, claro. También puedes usar un destornillador como cincel, pero luego no te quejes de las marcas.
TrueNAS encaja cuando el almacenamiento es el protagonista y quieres ZFS bien planteado. Es más rígido con discos y ampliaciones, pero muy sólido si sabes a lo que vas. Para documentos, fotos y datos importantes, ZFS da mucha tranquilidad. Para ir metiendo discos de cualquier tamaño cada seis meses, quizá no tanto.
Mi recomendación práctica sería esta:
- Si quieres facilidad y Docker: Unraid.
- Si quieres aprender virtualización y separar servicios: Proxmox más un NAS aparte o almacenamiento muy pensado.
- Si quieres almacenamiento serio y ordenado: TrueNAS.
- Si quieres lo mínimo: un mini PC con Docker y backups bien hechos.
La última opción parece humilde, pero para mucha gente sería la mejor.
Backups antes que servicios bonitos#
Si hay una regla que no negociaría es esta: antes de instalar diez servicios, resuelve backups.
No “tengo RAID”. RAID no es backup. No “tengo snapshots”. Snapshots no son backup si están en el mismo sitio y un error humano los borra. No “lo tengo en el NAS”. El NAS también puede morir, quemarse, cifrarse por ransomware o recibir una metedura de pata maravillosa a las once de la noche.
Para una casa usaría una variante simple del 3-2-1:
- Una copia principal en el NAS o servidor.
- Una copia local adicional en otro disco o equipo.
- Una copia fuera de casa, puede ser nube cifrada o disco rotado.
Y probaría restauración. Esto es lo que casi nadie hace. Un backup que nunca has restaurado es una promesa, no una garantía. No hace falta hacer una simulación militar cada semana. Pero sí descargar un archivo, restaurar una carpeta y comprobar que las fotos abren.
Para fotos familiares sería especialmente pesado. Si uso Immich, Syncthing, PhotoPrism o cualquier solución parecida, quiero saber dónde están los originales, dónde está la base de datos, cómo se copia y cómo se restaura. La app puede ser preciosa, pero si el backup es confuso, no me sirve.
Fotos: cuidado con convertir recuerdos en una beta permanente#
Immich me parece una de las aplicaciones self-hosted más interesantes para una casa. También es una de las que trataría con más respeto. Gestionar fotos familiares no es lo mismo que montar un lector RSS. Si el RSS se rompe, pierdes comodidad. Si las fotos se rompen, pierdes historia.
Mi enfoque sería conservador.
Primero, mantener una copia de los originales fuera de la aplicación. Segundo, hacer backup de la base de datos y de los ficheros de Immich. Tercero, no actualizar a lo loco justo antes de un viaje, una fiesta o una semana complicada. Cuarto, explicar en casa cómo acceder a las fotos si yo no estoy delante.
Esto último importa. Un homelab familiar no debería depender de que una persona recuerde todos los comandos. Si el sistema solo funciona cuando tú estás, no es infraestructura familiar. Es tu juguete con usuarios involuntarios.
Red: estable antes que sofisticada#
La red doméstica es el sitio donde más fácil es pasarse de listo. VLANs, firewalls, DNS interno, resolutores, túneles, VPN, reglas, mDNS, IoT separado. Todo tiene sentido en papel. En la práctica, cada capa añade un punto donde puedes romper Netflix, la impresora, el móvil de alguien o una bombilla que hasta ayer obedecía.
Yo sí separaría algunas cosas, pero sin montar una catedral.
Una red principal para dispositivos de confianza. Una red IoT si tienes muchos cacharros. Una red de laboratorio si vas a probar cosas raras. DNS local para nombres útiles. Tailscale o WireGuard para acceso remoto. Poco más al principio.
Lo que no haría es meter el DNS crítico en una máquina que reinicias cada dos días para aprender. Tampoco pondría el firewall principal en una VM experimental si no tengo acceso físico fácil y plan de rollback. Hay aventuras que en YouTube quedan muy bien y en casa acaban con alguien preguntando por qué no carga YouTube. Ironías de la vida.
Servicios que sí pondría desde el principio#
Mi lista corta sería bastante sobria.
- Backups automatizados y monitorizados.
- Gestor de documentos tipo Paperless-ngx si hay disciplina para escanear.
- Fotos con Immich solo si el backup está claro.
- DNS con Pi-hole o AdGuard Home, pero con fallback sencillo.
- Uptime Kuma o Beszel para saber si algo se ha caído.
- Un gestor de contraseñas si se entiende bien el riesgo y hay backups.
- Un dashboard simple, más para orden que para postureo.
No pondría veinte aplicaciones el primer fin de semana. Es tentador, lo sé. Community Apps, Docker Compose y los repositorios de Awesome Selfhosted son una droga bastante efectiva. Pero cada app nueva pide mantenimiento, actualizaciones, backup, puertos, usuarios y memoria mental.
Prefiero cinco servicios usados cada semana que treinta contenedores con nombres bonitos y cero responsabilidad.
Documentación mínima, pero existente#
No hace falta escribir una novela técnica. Pero sí dejar cuatro cosas claras en un documento:
- Qué servicios existen y dónde corren.
- Dónde están los datos importantes.
- Cómo se restauran backups.
- Qué depende de qué.
- Qué se puede apagar sin miedo.
Esto salva tardes. También ayuda a no depender de memoria. El homelab tiene una capacidad especial para parecer obvio el día que lo montas y absolutamente arqueológico seis meses después.
Yo añadiría una página de “si todo arde”. Algo simple. Primero levantar red. Luego acceso al NAS. Luego backups. Luego servicios. Lo crítico antes que lo bonito. Parece exagerado hasta que un disco falla, una actualización rompe una base de datos o tú mismo borras lo que no tocaba porque ibas con prisa.
Qué dejaría para más adelante#
Dejaría Kubernetes para cuando ya haya una base estable. Me encanta, pero no lo usaría como cimiento inicial de una casa salvo que el objetivo principal sea aprender Kubernetes. Lo mismo con Ceph, HA compleja, observabilidad completa, GitOps y demás piezas serias. Son herramientas fantásticas cuando hay un problema real. También son máquinas de producir trabajo si las metes demasiado pronto.
La alta disponibilidad doméstica merece capítulo aparte. Muchas veces no necesitas HA. Necesitas backups buenos, restauración sencilla y hardware que no sea una bomba. Si un servicio puede estar caído una hora sin drama, quizá no merece un cluster. Si no puede estar caído, entonces sí, pero diseña esa parte con calma.
También dejaría para después los despliegues perfectos. Al principio me importa más saber restaurar que tener CI/CD casero para cada contenedor. La elegancia puede esperar. La seguridad de los datos, no.
El diseño final que sí recomendaría#
Mi homelab familiar ideal sería poco espectacular, que es justo la gracia.
Un NAS o servidor de almacenamiento con dos o cuatro discos, snapshots si encajan y backups externos. Un mini PC silencioso para servicios Docker. Un SAI pequeño. DNS con fallback. Tailscale o WireGuard para entrar desde fuera. Un par de servicios útiles. Monitorización básica. Documentación corta. Laboratorio separado para romper cosas sin llevarse la casa por delante.
Nada de esto gana concursos de rack. Pero aguanta la vida real.
Y esa es la medida que más me interesa ahora. Un homelab doméstico bueno no es el que más servicios enseña. Es el que guarda bien tus datos, no molesta a la familia, te deja aprender y no te convierte en guardia de sistemas de tu propia casa.
Si después quieres montar un cluster, montarás un cluster. Pero lo harás sobre una base que ya funciona. Esa diferencia se nota muchísimo.