- Después de años probando distintos enfoques de self-hosting, comparte la experiencia de haber construido con éxito un entorno personalizado
- El objetivo principal fue mantener el control de los datos personales y una infraestructura confiable, combinando para ello varias tecnologías clave como NixOS, ZFS, Tailscale y Authelia
- También se reforzó la accesibilidad pensando en la usabilidad para familiares y conocidos, con SSO y una página de inicio independiente
- Se documentan en detalle los problemas encontrados en la operación real y sus soluciones concretas (por ejemplo: proxy público para servicios privados, entornos VPN mixtos, integración de autenticación)
- A futuro planea mejoras adicionales como infraestructura de respaldos y refuerzo de seguridad, y deja además su experiencia y materiales de referencia
Introducción y motivación
- Tras probar varias formas de self-hosting durante algunos años, logró construir un entorno “suficientemente bueno” para sus propias necesidades
- Consultó varios recursos de código abierto y experiencias de otras personas, y comparte el proceso con la intención de que pueda ayudar a otros desarrolladores
Objetivos
- Al controlar directamente los datos personales y los servicios relacionados, busca reforzar la privacidad y minimizar el riesgo de cambios o cierre de servicios de terceros
- También se enfoca en ofrecer ese mismo control a familiares y conocidos, para crear un entorno de servicios confiable
Requisitos
-
Requisitos imprescindibles
- Limitar al máximo la exposición de los servicios a Internet público para reducir el riesgo de incidentes de seguridad
- Minimizar el tiempo de inactividad de la infraestructura crítica por errores humanos (evitando dependencias circulares y facilitando el rollback de configuración)
- Tener propiedad directa de los componentes clave como autenticación, red y dominio, y priorizar soluciones de código abierto
- Considerar la usabilidad desde la perspectiva de familiares y conocidos (inicio de sesión SSO consistente y mantenimiento mínimo)
- Adoptar activamente una configuración declarativa mediante archivos de configuración (facilidad para control de versiones, respaldo y recuperación, y reutilización de configuraciones de terceros)
- Las actualizaciones deben ser fáciles y seguras para permitir un mantenimiento periódico
-
Requisitos no prioritarios
- No necesita modularidad extrema ni una pulcritud perfecta (se prioriza la practicidad)
- No todo tiene que ser de código abierto, aunque se usa siempre que sea posible
- No persigue alta disponibilidad (HA); en lugar de eso acepta tiempo de inactividad ocasional a cambio de una estructura simple
Selección de tecnologías
-
NixOS
- Una distribución de Linux que administra toda la configuración del sistema operativo de forma declarativa con el lenguaje Nix y su gestor de paquetes
- Al tener la configuración como código, permite control de versiones y rollbacks estructurados
- También soporta una amplia variedad de paquetes e integración con Docker/PODMAN, entre otros
- Fue acumulando experiencia tomando como referencia configuraciones Nix de otros desarrolladores
-
ZFS
- Un sistema de archivos de alto rendimiento con excelentes funciones de protección de datos como snapshots y rollback
- Configuró 4 HDD de 10 TB en RAIDZ2 (tolera fallas simultáneas de 2 discos), con caché en un SSD de 256 GB
- Gestiona por separado los datasets de archivos y medios, con montajes NFS según su uso
- Construyó una arquitectura de almacenamiento principal simple y confiable
-
Tailscale & headscale
- Tailscale: una Mesh VPN muy accesible que permite entrar a la red interna sin exponerla a Internet público solo instalando el cliente
- Headscale: backend de Tailscale de código abierto y autohospedable (elimina el riesgo de cambios en la política de la empresa)
- Mejora la seguridad de red, aunque requiere instalar el cliente en los dispositivos de los usuarios
- Desde el punto de vista de la usabilidad, la necesidad de instalar un cliente por dispositivo sí representa cierta barrera de entrada
-
Authelia & LLDAP
- Authelia: solución de SSO, autenticación y autorización basada en OpenID Connect, integrable con proxy nginx
- LLDAP: LDAP liviano, usado para gestión de usuarios y grupos de Authelia, además de autenticación de respaldo
- Funciona bien con pocos recursos, pero tiene una configuración compleja y una curva de aprendizaje sobre cómo integrarlo con cada servicio
Diseño de la estructura
-
Arquitectura
- Cada servidor fue nombrado con el nombre de un planeta de Star Wars
- El punto de entrada (public server) es "taris", que ofrece servicios esenciales como Authelia, headscale y el blog
- headscale, Authelia y LLDAP deben ser accesibles externamente, así que se operan públicamente dentro de un alcance limitado
- Los servicios privados (Foundry VTT, monitoreo, etc.) se exponen selectivamente a través de un proxy NGINX
-
Servidor privado
- En el servidor principal "kuat", administra una VM con NixOS y el pool de almacenamiento ZFS mediante TrueNAS
- Separa el alcance de snapshots y respaldos entre "files" (datos irrecuperables) y "media" (datos recuperables si se desea)
- Los servicios principales corren en la VM "bespin" con NixOS, y también armó una VM separada para pruebas llamada "alderaan"
-
Otros servicios
- Los dispositivos mission-critical se configuraron como appliances de propósito único (por ejemplo, para smart home usa Home Assistant OS por separado)
- Para el servidor Matrix y el cliente Element se usan los playbooks oficiales de Ansible
- El correo y la gestión de contraseñas se externalizaron a ProtonMail y Bitwarden para evitar dependencias circulares
Problemas individuales y soluciones
-
Página de inicio de servicios
- Un dashboard simple basado en Flame que mejora el acceso a servicios según cada usuario
- Como consume poco y se ve bien, se usa de manera práctica mientras no se adopte un reemplazo
-
Uso conjunto de Tailscale con otras VPN
- Algunos sistemas operativos (sobre todo Android y Windows) no permiten múltiples VPN activas al mismo tiempo
- Combinando la función de exit node de Tailscale con Gluetun (cliente VPN basado en contenedores), se puede desviar el tráfico hacia VPN externas como ProtonVPN
- Eso sí, tiene efectos secundarios como mayor consumo de batería y caídas ocasionales de velocidad
-
Precauciones con la autenticación
- Protocolos principales de autenticación en servicios self-hosted: OIDC (prioridad), OAuth y LDAP
- Se requiere configuración separada tanto en cada servicio como en Authelia
- La cuenta de administrador debe mantenerse siempre por separado de la integración con Authelia/LLDAP, para asegurar un método de recuperación ante fallas de autenticación
- En servicios sin soporte para OIDC, el control de acceso se implementa integrando NGINX con el proxy de Authelia
- El OIDC de Authelia y el control de acceso vía NGINX Proxy requieren configuraciones separadas
-
Emisión de DNS y SSL
- Los servicios públicos operan de la forma habitual (dominio → IP pública)
- Los servicios internos usan el subdominio "internal" y direcciones IP de Tailscale para bloquear la exposición externa
- Los certificados SSL aprovechan el soporte integrado de Let's Encrypt en NixOS (HTTP-01 para servicios públicos y DNS-01 para los internos)
-
Precauciones al instalar NixOS en VPS
- Muchos VPS no ofrecen opción de instalación de NixOS
- Si hace falta instalarlo, conviene consultar la wiki de la comunidad y verificar las rutas de instalación compatibles
-
Montaje de datasets de TrueNAS en VM
- El firewall predeterminado de TrueNAS bloquea el acceso del host desde la VM
- El montaje de datasets NFS se implementó siguiendo la guía oficial (creación de una red bridge)
-
Proxy público para servicios personales
- Con una base headscale, se pueden exponer servicios privados externamente mediante
NGINX proxyPass
- Además de Tailscale Funnel oficial, también se incluyen ejemplos de configuración y materiales de referencia
Próximos pasos y desafíos
- Hace falta agregar un servidor de respaldos dedicado y un sistema de verificación de recuperación
- Planea aprovechar más activamente el control de acceso de Tailscale/headscale
- También tiene previsto reforzar más la seguridad, incluido el acceso por SSH
- Está evaluando incorporar soluciones locales de DNS cifrado y caché como Pi-hole y AdGuard Home
- También considera ampliar con nuevos servicios como Forgejo, Manyfold y RomM
Materiales de referencia
2 comentarios
¡Qué genial!
Comentarios de Hacker News
Si quieres que familiares o amigos lo usen fácilmente, la meta es que cada persona tenga una sola cuenta de inicio de sesión y acceda a varios servicios mediante SSO (inicio de sesión único). Esa parte es realmente difícil, pero al mismo tiempo es lo genial. El open source y Linux son bastante paradójicos: se usan literalmente en todas partes y cubren todos los protocolos, pero construir el entorno cliente real, es decir, conectar a las personas y montar directamente los elementos tipo groupware, termina siendo más complicado. Todo el proceso de integrar varios sistemas de forma orgánica e incluso montar infraestructura de directorio resulta sorprendente. Nunca pensé que algún día administraría FreeIPA o un servicio de directorio compatible con Windows, pero últimamente sí da la impresión de que el mundo basado en OpenID por fin está tomando forma de verdad.
Gracias por la empatía. El login simple y la accesibilidad fueron el requisito más difícil de este proyecto, y creo que es justo lo que determina si la gente realmente lo usa o no. El open source de verdad está en todas partes, pero los problemas empiezan en cuanto un usuario común intenta usar algo por su cuenta. Creo que esta paradoja existe porque cada proyecto quiere innovar por su lado. Que no haya una entidad empujando todo en una sola dirección es una ventaja y a la vez una desventaja. Aun así, viendo solo el self-hosting de los últimos 5 años, sí siento que tanto la instalación como el uso se han vuelto mucho más fáciles.
Estoy totalmente de acuerdo con esa paradoja. Ayer mismo publiqué en mi plataforma de validación sobre lo poco accesible que es FOSS para personas no técnicas. Me hace pensar que quizá una plataforma tipo integrador de sistemas que conecte usuarios técnicos y no técnicos podría ser una solución.
En realidad no es tan difícil. Si en vez de obsesionarte con servicios específicos usas el soporte de SSO como criterio principal de selección, sorprendentemente se puede montar fácil. Yo tampoco tenía casi experiencia al principio, pero con caddy y authentik armé rápidamente mi sistema self-hosted. Como alternativa, yunohost es una distribución muy fácil que incluso te configura el SSO automáticamente.
Yo uso authentik con autenticación SSO de Google, Discord y GitHub. Funciona lo suficientemente bien para todos.
Sé que encontrar el sistema “perfecto” para cada quien puede tomar tiempo, porque todos tienen objetivos, preferencias y entornos distintos. Quiero compartir en un post de blog cómo llegué a mi setup final. Hablo de objetivos y requisitos, tecnologías usadas, diseño y proceso de resolución de problemas. Mi forma no le va a servir a todo el mundo, pero ojalá le sirva de referencia a alguien más. Yo también crecí gracias a mucho contenido y software libre, así que quiero seguir devolviendo la ayuda.
Me da curiosidad saber qué te pareció usar Nix en el homelab. Yo llevo más de 7 años con un rack 25U bastante hardcore, con kubernetes pequeño, ceph y Talos Linux, pero cada vez quiero simplificar más, y curiosamente siempre termino llegando a Nix y ZFS. Esos problemas me resultan demasiado familiares. Si tú también tienes dudas, pregunta con confianza.
Me pregunto si has considerado usar coolify. Yo llevo más de un año usándolo y me gusta bastante lo fácil que hace el despliegue automático desde GitHub, tipo Heroku https://coolify.io/
Me pregunto si también usas cifrado de ZFS. Antes corría varias VM, incluyendo FreeIPA, sobre Debian+ZFS, pero para simplificar cambié a una estructura donde solo corro la librería de cifrado de Seafile en un VPS y hago backup al servidor de casa con ZFS send/receive. Ese servidor se enciende cada noche, se actualiza y sincroniza, y luego vuelve a dormir. Para hacerlo más seguro, estoy pensando si debería usar cifrado total también en el ZFS de mi desktop Linux (Fedora). Como mi dataset principal ya está cifrado, la sincronización a discos externos o a la nube se vuelve mucho más sencilla. Subir toda mi biblioteca de fotos al Seafile del VPS sale caro, así que estoy buscando opciones.
Me parecieron útiles tus impresiones del setup y las explicaciones detalladas. No me resulta fácil adoptarlo de inmediato como tú, pero decidí instalar flame como dashboard para experimentar con mi familia.
Qué gusto. Tu trabajo me parece realmente interesante. Yo también estoy trabajando en un proyecto parecido basado en NixOS. Mi meta es crear una cajita estilo Apple, casi de cero configuración, que cualquiera pueda conectar al módem y terminar de instalar solo con un asistente web. Todavía está en etapa temprana, pero ya la tengo corriendo en casa. Cumple al mismo tiempo el papel de router híbrido (OPNSense/PFSense) y servidor de apps (Nextcloud, Synology, Yunohost, etc.). Toda la configuración se maneja además desde una sola hoja de módulos Nix. Tiene DNS dinámico, certificados de Let's Encrypt, asignación automática de subdominios por app, bloqueo de anuncios y headscale integrado. Ahora mismo también estoy armando el SSO, y pienso tomar algunas ideas de tu post. Más detalles en https://homefree.host
A veces veo mi red casera y me imagino el daño colateral que le dejaría a mi familia si me muriera, o lo difícil que sería para alguien de fuera entender mi setup. Este “juego del homelab” en realidad satisface algo parecido al hobby de esos señores de otra generación que armaban maquetas de trenes. No lo digo en mal sentido; siento que hay gente que tiene el instinto de querer un mundo en miniatura bajo su control absoluto.
Yo pensé exactamente lo mismo y dejé documentación preparada por si acaso. La parte 1 trata del dinero y de dónde están los documentos importantes. La parte 2 son instrucciones de cómo volver la casa “más tonta”. Por ejemplo, cómo quitar los switches inteligentes y restaurar interruptores tradicionales, cómo mover servicios clave como Bitwarden a la nube, cuánto cuesta mantener el dominio y el correo, cómo volver a usar el router básico del ISP, etc. A mi esposa no le entusiasmaba mucho la casa inteligente, pero se quedó tranquila cuando le dije que en cualquier momento se puede volver a una “casa tonta”. La verdad no sé qué tan incómodo sería perder todo esto, pero también me consuela pensar que ya no sería mi problema.
Yo guardo las fotos familiares en un RAID1 del home lab y cada noche hago backup con rsync a un disco externo conectado a la computadora de mis suegros. La idea es que, si pasa algo, la familia también pueda acceder fácilmente. Como a mi esposa no le interesa IT, solo le dije: “si conectas el USB, ahí está todo”.
Creo que se pueden ignorar escenarios de amenaza poco útiles, como el robo de discos físicos. Lo práctico es guardar todas las fotos y documentos importantes sin cifrar, junto con instrucciones fáciles de entender. Lo de la automatización del hogar sí me preocupa más.
Pensar de antemano qué pasará si quien administra el homelab se ausenta por mucho tiempo o queda fuera de juego sí es importante en la práctica. No es que yo haya puesto atención especial para hacerlo fácil, pero siento que sí vale la pena reflexionarlo más. La clave es dejar los datos importantes y las credenciales para acceder a ellos. También es buena idea usar servicios como Nextcloud para que los datos se sincronicen automáticamente con los dispositivos de la familia, y hacer que familiares y amigos realmente usen el sistema por sí mismos. En mi casa también intento que Home Assistant se vuelva lo bastante esencial como para que mi pareja lo use conmigo, casi como un electrodoméstico más. Cuando existe como equipo físico y no como una VM aparte, también es más fácil de administrar. Claro, todo esto tiene bastante de deseo optimista, así que es importante al menos hacer un plan detallado con la familia cercana.
Yo también le he dado muchas vueltas a eso. Parto de la idea de que el NAS y los servicios en Docker no van a arrancar bien sin mí. Siento que nadie podría recuperar de verdad un backup cifrado off-site sin ayuda profesional. Así que uso un disco externo NTFS y con cron guardo snapshots incrementales diarios en carpetas nuevas. Ocupan menos de 50 GB, así que puedo duplicarlos barato. Si me pasa algo, basta con conectar ese disco y copiar las carpetas. También tengo una copia completa de la librería de Seafile en laptops individuales. El dominio de correo lo pagué por adelantado 10 años y lo tengo en iCloud hosting. Como las fotos familiares adjuntas llenan el espacio y hacen que el correo rebote, estoy viendo migadu.
A mí también me interesa mucho este tema. Quiero advertir que si trabajas por tu cuenta o montas una startup de IT, las ganas de hacer homelab se vuelven todavía más fuertes. Poco a poco ya no basta con correr contenedores simples; terminas presentando todo tipo de documentos para conseguir legalmente un DBA y un ASN, y de verdad evolucionas hasta tener tu propio bloque IP/IPv6 y convertirte en tu propio ISP. Mucha gente resuelve el problema del ingress con tailscale, y esa parte sí que es difícil. También pienso que, en teoría, una estructura basada en STUN/TURN donde el servidor solo cachea archivos estáticos y el acceso dinámico se autentica en una pared de login con magic links por correo no sería tan riesgosa ni tan costosa. Cuando armas un entorno de desarrollo remoto, también aparece una nueva excusa para seguir profundizando en esto. Links de referencia: https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT, https://en.wikipedia.org/wiki/STUN
Últimamente he estado trasteando con Immich y cada vez dudo si usarlo fuera de casa solo con tailscale o también montar un reverse proxy en un VPS. Lo que más me preocupa es encontrar una solución de monitoreo/seguridad amigable para usuarios que me avise cuando alguien esté intentando atacar desde el VPS.
Mi setup es mucho más simple
HTTP envía la contraseña en texto plano, así que como mínimo conviene usar un certificado autofirmado.
Construir la infraestructura o los servicios directamente como código es simplemente de lo mejor para aprender. También está buenísimo que puedas ajustarlo exactamente a tus propias necesidades.
Me gustaría probar algo así de operar un homelab, pero no me da el tiempo. Puedo instalar cosas un fin de semana, pero no tengo margen para mantener y actualizar de forma constante. Por eso prefiero dejarlo en manos de un proveedor cloud y olvidarme del tema. Si hay alguien como yo que usa solo cloud, me interesa saber cómo lo aborda.
En mi setup anterior también me estresaba porque el mantenimiento nunca quedaba bien hecho. Por eso terminé apreciando NixOS y ZFS. Con ambos, hacer rollback es realmente fácil. Actualizas, y si algo falla, vuelves enseguida a la versión anterior; ya depuras cuando tengas tiempo. Y si la opción cloud te funciona y te deja satisfecho, también me parece perfecto. Montarlo uno mismo claramente consume tiempo, así que cada quien tiene que comparar costo y valor.
Yo corro como 12 servicios self-hosted, y normalmente las actualizaciones no me toman ni un minuto al mes. Tengo una carpeta por servicio, con su stack de docker-compose y su carpeta de datos, y para actualizar solo hago
docker compose pully luegoup -d. De vez en cuando habrá alguna actualización que requiera cambiar la configuración, pero la mayoría terminan en cuestión de minutos. Ni siquiera uso VM; creo que self-hosting totalmente automatizado solo con Docker Compose es la forma más simple.Esto no se queda simplemente en un solo día de fin de semana. En mi caso empecé instalando Plex “solo para probar” y un año después ya tenía una estructura compleja con Proxmox y toda clase de automatización del hogar integrada. Medio en broma, medio en serio: si quieres un setup mínimo, empieza con docker compose; así también la administración y las actualizaciones son más simples.
Me pregunto si realmente hace falta meter SSO. Si familiares o amigos usan un cliente wireguard (que incluso en iOS es muy sencillo), pueden conectarse a la red de casa con solo activar un switch y usar todos los servicios internos sin necesidad de SSO aparte. En una red doméstica pequeña, creo que las ventajas superan por mucho las desventajas.
Los servicios que usamos, como Nextcloud o Mealie, ya traen cuentas por usuario de forma nativa. Siento que gracias al SSO todos pueden entrar a todos los servicios con la misma cuenta y además yo ya no tengo que administrar contraseñas. El setup se vuelve un poco más complejo, pero la operación termina siendo más fácil, y así es más probable que la familia de verdad lo use.
Yo self-hosteó unas 20 apps y ya me cansé de administrar la autenticación de cada una por separado, así que estoy metiendo SSO. Cuando quieres exponer algunas apps también a la familia, para mí lo más importante es poder resolver la autenticación en un solo lugar. No estoy muy de acuerdo con la idea de arriba.
Me pregunto por qué usar flame específicamente. Es como meter decenas o cientos de dependencias de terceros, como node, react y redux, dentro del “reino de la seguridad”, cuando en realidad una página de inicio podría ser solo un HTML sencillo con una lista de links.
Me gustaría hacer self-hosting con NixOS, pero todavía no doy el paso. Mi entorno se maneja con unas cuantas VM y un archivo docker compose por VM, y solo copio esos archivos con playbooks de ansible. El sistema operativo es Fedora Server, siempre una versión detrás del release actual, y cuando expira hago upgrade y listo. En la Mac uso nix-darwin, así que sí entiendo las ventajas de la configuración con Nix, pero todavía no siento que me dé suficiente eficiencia o retorno sobre el tiempo invertido como para portar todo mi entorno a Nix. Tal vez si un LLM me dictara los archivos de configuración. Por ahora no tengo suficiente motivación para lanzarme.
Yo también probé NixOS y en una semana migré por completo tanto la red de casa como dos servidores reales. Ya van unos 3 o 4 meses y estoy más satisfecho de lo que esperaba. Migrar los servidores fue más fácil que mover una workstation. Últimamente incluso me he entretenido montando un Jetson Orin Nano con NixOS. En tiempos de Gentoo ni me lo habría planteado. Lo que más me desesperaba de Gentoo eran los tiempos de compilación absurdamente largos en hardware viejo; por ejemplo, compilar GHC en una XPS de 2019 me tomaba unas 6 horas.
Para mí la gran diferencia de NixOS fue lo fácil que es hacer rollback cuando algo se rompe. Con un enfoque basado en ansible o compose también puedes tener backup y recuperación, pero tienes la carga de escribir tú mismo ese sistema. Aun así, si ya estás satisfecho con tu sistema actual, creo que eso también está perfecto.
Si ya usas IaC en cierto grado, no sentí que NixOS aportara tanta eficiencia adicional.