En el ecosistema de los homelabs y el self-hosting hay una tendencia clara: cada vez más usuarios quieren una plataforma que les deje montar un NAS, levantar contenedores y desplegar alguna máquina virtual sin tener que “casarse” con un enfoque rígido o con dependencias innecesarias. En ese contexto aparece MOS, un proyecto open source que se presenta como un sistema operativo modular para servidores domésticos y pequeños racks, con una promesa que suena especialmente familiar para administradores de sistemas: una base ligera, un panel web coherente y, sobre todo, una API completa para que la automatización no sea un añadido, sino el núcleo.
MOS se apoya en Devuan como sistema base (una bifurcación de Debian orientada a evitar la dependencia de systemd) y se plantea como una “central de operaciones” para el día a día: monitorización de recursos, gestión de discos, pools y comparticiones, control de usuarios, configuración de red y servicios, además de módulos para Docker, LXC y máquinas virtuales. Todo ello bajo una idea transversal: lo que no se necesita, no se activa; lo que se quiere ampliar, se añade de forma modular.
Una arquitectura pensada para automatizar, no solo para “hacer clic”
La clave técnica más interesante de MOS —y la que más puede atraer a perfiles de sysadmin y desarrollo— es su enfoque “API-first”. La propia documentación del proyecto deja claro que la interfaz web no ejecuta acciones directamente en el sistema: actúa como cliente y se comunica de forma exclusiva con la MOS API. Esto cambia el marco mental: si la UI hace llamadas a API para todo, el usuario también puede hacerlo, con scripts, integraciones o herramientas propias, sin depender de flujos opacos.
La API se documenta mediante Swagger en una URL interna del propio servidor, e incluye secciones organizadas por subsistemas (autenticación, discos, pools, shares, Docker, LXC, máquinas virtuales, etc.). En seguridad, el modelo se apoya en tokens con autenticación Bearer, generados desde el panel, lo que facilita plantear automatizaciones controladas por roles y permisos.
Además, el proyecto no se queda en el “REST y ya”: MOS se presenta también con soporte de eventos en tiempo real mediante WebSocket, especialmente para notificaciones, evitando el clásico enfoque de refrescos constantes o polling agresivo cuando se quiere una experiencia de monitorización viva.
Almacenamiento: mergerfs y SnapRAID como punto de partida
Para un homelab, el almacenamiento suele ser el primer campo de batalla: ampliar capacidad con discos dispares, minimizar riesgos y no complicarse con un RAID tradicional cuando el caso de uso es principalmente media, copias y datos “templados”. MOS incluye por defecto una combinación muy conocida en este terreno: mergerfs para unificar múltiples discos en un solo espacio lógico y SnapRAID para paridad por instantáneas, un enfoque que suele encajar bien en servidores domésticos y NAS de uso mixto.
Lo relevante aquí es el enfoque de modularidad: MOS mantiene una base con herramientas razonables y deja tecnologías adicionales como plugins, distribuidos a través de su propio “hub” de aplicaciones. En la práctica, esto busca que el sistema no cargue con complejidad y dependencias que no todo el mundo necesita, pero que exista un camino relativamente directo si se quiere ir más allá.
Contenedores y virtualización: Docker, LXC y QEMU en el mismo tablero
MOS incluye soporte para Docker y LXC como piezas principales del self-hosting moderno: servicios en contenedores, laboratorios, stacks y aplicaciones que se instalan y se abandonan sin dejar residuos. Junto a ello aparece QEMU para máquinas virtuales, con un matiz importante: el proyecto reconoce que el “frontend” de virtualización todavía está en desarrollo, aunque la API ya estaría cerca de cubrir la mayor parte de las funciones.
En términos prácticos, la propuesta de valor es centralizar la operativa: ver recursos, gestionar almacenamiento y, en paralelo, levantar contenedores o VMs sin saltar entre herramientas. Para un sysadmin, esto no sustituye a un stack profesional si se busca clúster, alta disponibilidad o funcionalidades avanzadas de hipervisor, pero sí apunta a un “todo en uno” razonable para laboratorio, casa o pequeños entornos.
MOS Hub: una tienda interna de plantillas, con programación tipo cron
Uno de los módulos más orientados a la comodidad es MOS Hub, que funciona como un hub de aplicaciones con plantillas Docker preconfiguradas desplegables desde la interfaz. Técnicamente, es una capa que reduce fricción: en lugar de copiar y pegar compose o pelear con variables, se parte de plantillas listas para instalar y mantener.
El control del hub se integra en la configuración del sistema, con opciones para habilitarlo o deshabilitarlo, forzar una actualización inicial por sesión y programar actualizaciones automáticas con sintaxis cron. El valor aquí es que MOS intenta evitar el “repositorio congelado”: la lista de plantillas y metadatos puede refrescarse de manera regular sin interrumpir contenedores en ejecución, según la propia documentación.
Instalación: un USB FAT32, un ZIP y arranque directo
A diferencia de otros sistemas que exigen imágenes grabadas con herramientas específicas, MOS apuesta por un método sencillo: preparar un USB en FAT32, etiquetarlo como “MOS”, descargar el archivo .zip desde la sección de releases y extraerlo directamente al pendrive. Con eso, el sistema está listo para arrancar e iniciar la instalación.
En requisitos, el proyecto recomienda como base un procesador x86_64 y 8 GB de RAM para operar con estabilidad, especialmente si se van a usar contenedores, virtualización y servicios de almacenamiento. Para pruebas rápidas en máquina virtual, también se menciona un umbral mínimo más bajo, orientado a evaluar el sistema sin comprometer recursos del host.
Privacidad y transparencia: sin telemetría como principio, no como opción
En un momento en el que incluso herramientas domésticas acaban incluyendo métricas, tracking o dependencia de servicios externos, MOS subraya un punto que muchos administradores valoran: no hay telemetría, no se recopilan datos y no se hace reporting de uso. Todo corre en local y queda bajo control del operador. A esto se suma el carácter open source del proyecto, con una advertencia realista: MOS está en una fase temprana y se distribuye “tal cual”, por lo que el enfoque prudente —copias de seguridad y cautela con datos críticos— sigue siendo obligatorio.
Una apuesta interesante… con mentalidad de proyecto joven
MOS no llega para destronar a soluciones consolidadas de NAS o virtualización, ni lo necesita. Su espacio natural parece ser otro: quienes quieren un sistema ligero, modular, sin dependencias forzadas, con interfaz web agradable y una API suficientemente completa como para integrar y automatizar de verdad.
En otras palabras: MOS no vende la idea de “olvídate de cómo funciona”, sino la de “míralo todo, contrólalo todo y amplíalo a tu ritmo”. Para un medio de sysadmin y desarrollo, ese enfoque tiene sentido: menos fuegos artificiales, más superficies controlables.
Preguntas frecuentes
¿Para qué tipo de homelab es recomendable MOS frente a una distro generalista?
MOS encaja especialmente en homelabs que quieren una capa de gestión unificada (monitorización, almacenamiento, usuarios y servicios) y un camino claro para contenedores (Docker/LXC) y máquinas virtuales, sin montar manualmente todas las piezas desde cero.
¿Se puede automatizar MOS desde scripts o herramientas externas gracias a su API REST?
Sí. MOS expone una API REST documentada con Swagger y la propia interfaz web actúa como cliente de esa API, lo que facilita replicar acciones desde automatizaciones usando tokens y autenticación Bearer.
¿Qué ventajas ofrece el enfoque mergerfs + SnapRAID en un NAS doméstico?
Es una combinación habitual cuando se quieren sumar discos de forma flexible y añadir una capa de paridad por instantáneas, especialmente útil en bibliotecas multimedia o datos que cambian con menor frecuencia que en un entorno transaccional.
¿MOS es adecuado para datos críticos en producción?
El proyecto se define como temprano y distribuido “as is”. Para usos críticos, la recomendación razonable es tratarlo como plataforma en evaluación o para entornos no críticos, manteniendo backups sólidos y validando bien antes de migrar datos importantes.
