Una nota de Zima
Gracias, Bob, por convertir tu tiempo con ZimaCube en algo mucho más útil que una reseña convencional. Tu diario continuo sigue a la máquina mientras cambia de función —desde las primeras impresiones y el desmontaje del hardware hasta ZimaOS, Windows Server, Proxmox, las copias de seguridad, la supervisión, los agentes de IA e incluso un router virtualizado—, a la vez que mantiene en el mismo registro las partes que te gustan y las que te frustran. Este tipo de experimentación honesta y a largo plazo nos ayuda a entender no solo qué puede hacer ZimaCube, sino también qué ocurre después de que pasa a formar parte de un homelab real.
— Zima
Conoce a Bob Loves Tech
Bob Loves Tech es un entusiasta del homelab y creador de contenido tecnológico cuyo trabajo abarca Windows, Linux, virtualización, redes, autoalojamiento y el hardware que sustenta todo ello.
Su relación con el hardware de Zima es anterior a este proyecto. Bob ya había pasado tiempo con productos Zima anteriores, incluidos ZimaBoard y ZimaBlade, antes de unirse al Zima Pioneer Programme. Cuando llegó ZimaCube, decidió no producir una única reseña pulida y pasar página. En su lugar, creó ZimaCube Experience Blog, un repositorio público que sigue creciendo a medida que la máquina cambia junto con su homelab.
Bob lo describe como un diario continuo y no como una reseña formal. Esa distinción explica bien el proyecto. Incluye la primera reacción ante el hardware, lo que descubrió después de abrirlo, los sistemas operativos que probó, la infraestructura que construyó a su alrededor y las conclusiones que cambiaron después de semanas de uso.
Documentar ZimaCube más allá de una primera impresión
Las primeras entradas del proyecto de Bob comienzan donde suelen hacerlo la mayoría de las historias sobre hardware: desempaquetando la máquina, observando la calidad de construcción, comprobando los puertos y las bandejas para unidades, y decidiendo qué se siente diferente cuando el hardware está físicamente sobre el escritorio.
Pero el diario no termina ahí. Bob vuelve al hardware después de haber convivido con él. Su repositorio incluye un análisis específico del hardware, un desmontaje completo, un seguimiento de seis semanas, un examen más detallado de por qué la memoria, y no los núcleos de CPU, se convirtió en el cuello de botella práctico, y una entrada independiente que plantea la pregunta que al final importa a todo reseñador: ¿realmente gastaría su propio dinero en él?
Esa progresión hace que el proyecto sea valioso. Una primera impresión te dice cómo llega un producto. Un diario continuo te dice qué permanece después de que desaparece la novedad.
Abrir el hardware y seguir los detalles
Uno de los capítulos sobre hardware se titula simplemente Desmontarlo, lo que dice mucho sobre el enfoque de Bob.
En lugar de tratar el ZimaCube como un dispositivo NAS sellado, abrió el chasis y documentó los componentes internos, incluido el sistema de refrigeración y los pequeños detalles de hardware que solo se hacen visibles cuando alguien decide que la máquina debe poder mantenerse y modificarse.
Ese desmontaje da paso posteriormente a otra parte del diario: qué cambió después de seis semanas y qué no. Algunas observaciones pierden importancia con el tiempo. Otras —incluidas la refrigeración, el comportamiento del ventilador, la capacidad de memoria, el acceso a las actualizaciones y la forma en que el hardware encaja en un entorno siempre activo— adquieren más importancia.
Para quienes quieran profundizar en las mismas cuestiones de hardware, nuestra guía de desmontaje del ZimaCube amplía la información sobre la distribución interna y las opciones de actualización, mientras que 7 detalles ingeniosos del diseño del ZimaCube examina más de cerca aspectos que se hacen visibles al abrir el sistema, en lugar de observarlo únicamente a través de una tabla de especificaciones.
Descubrir que la RAM importa más que tener más núcleos de CPU
Una de las entradas de hardware posteriores llega a una conclusión mucho más útil que otro gráfico de rendimiento: el ZimaCube no necesitaba más núcleos de CPU para la carga de trabajo de Bob. Necesitaba más memoria.
Su diario describe un sistema con diez máquinas invitadas en ejecución mientras el uso de la CPU se mantenía alrededor del cuatro por ciento, pero el consumo de memoria había aumentado hasta aproximadamente 27 GB. Esto cambia la forma en que debe evaluarse el hardware. El procesador no era el primer límite práctico; lo era la configuración de memoria incluida de fábrica.
Para una máquina que se está convirtiendo gradualmente en host de virtualización, servidor de copias de seguridad, nodo de monitorización, host de máquinas virtuales para el router y entorno de pruebas de IA, la capacidad de memoria se convierte en infraestructura y deja de ser una simple especificación.
Este es exactamente el tipo de conclusión que puede revelar la experiencia prolongada de un usuario. No surge de preguntar qué puede hacer teóricamente la CPU, sino de observar el sistema después de acumular cada vez más cargas de trabajo reales.
Borrar ZimaOS e instalar Windows Server 2025
El experimento más destacado del repositorio de Bob comenzó cuando eliminó ZimaOS e instaló Windows Server 2025 directamente en el ZimaCube.
Bob describe esta combinación como una mezcla extraña, precisamente por eso decidió probarla. El proyecto se convirtió en una forma de poner a prueba el hardware sin depender del entorno de software con el que se comercializaba: el comportamiento de la instalación, la búsqueda de controladores, la red, el almacenamiento y si una plataforma NAS compacta seguía teniendo sentido al tratarla como un servidor Windows de uso general.
El experimento también demuestra una parte importante de la filosofía del hardware de Zima. Eliminar ZimaOS no pone fin a la vida útil del equipo. El hardware x86 sigue siendo una plataforma que puede reconstruirse en torno a un sistema operativo diferente.
Convertimos ese experimento en una guía de configuración de Windows Server 2025 en ZimaCube más estructurada, que abarca el proceso de instalación, el trabajo con el controlador de red Intel y la configuración del almacenamiento para quienes quieran explorar la misma dirección.
Poner a prueba ZimaOS antes de continuar
Windows Server es solo una parte de la historia del sistema operativo. Bob también escribió una reseña de ZimaOS específica en el diario del homelab.
Su conclusión es intencionadamente más matizada que «bueno» o «malo». El repositorio describe ZimaOS como una opción muy adecuada para dispositivos más pequeños, pero cuestiona si la experiencia simplificada se ajusta a lo que busca en un ZimaCube al que se le exige cada vez más en materia de virtualización e infraestructura de homelab.
Esa crítica es útil porque Bob no evalúa ZimaOS como alguien que prueba el self-hosting por primera vez. Lo evalúa desde la perspectiva de alguien que ya gestiona un homelab con varios sistemas y se siente cómodo administrando por sí mismo las capas inferiores.
Para otro usuario, la simplicidad puede ser el motivo para quedarse. Para Bob, el aumento de la complejidad de la infraestructura terminó siendo el motivo para marcharse.
El mismo equilibrio se analiza en nuestra comparativa entre ZimaOS, Proxmox y Windows Server, que surgió del mismo conjunto más amplio de experimentos.
Convertir Proxmox en el centro del homelab
Después de probar otras opciones, Bob llegó finalmente a una conclusión mucho más firme sobre el sistema operativo que quería instalar en el ZimaCube: Proxmox era el entorno que más sentido tenía para su homelab.
El diario describe un ZimaCube funcionando junto con almacenamiento NFS de Synology y pasando a formar parte de un conjunto de tres hosts. En ese momento, el equipo ya no se evalúa principalmente como NAS. Se ha convertido en infraestructura.
Ese cambio abre la puerta a varias entradas posteriores del diario, porque Proxmox proporciona la base para los siguientes experimentos: infraestructura de copias de seguridad, supervisión, servicios de IA y virtualización de red.
Para los usuarios interesados en crear la misma base, nuestra guía de configuración de ZimaCube + Proxmox cubre el proceso desde la preparación de la BIOS hasta las máquinas virtuales, los contenedores LXC, el almacenamiento, la red y el passthrough.
Crear copias de seguridad en torno a la infraestructura
Una vez que una máquina se convierte en infraestructura, la siguiente pregunta ya no es si puede ejecutar más servicios. Es qué ocurre cuando uno de esos servicios desaparece.
El diario de Copias de seguridad de Bob sigue esa transición. Proxmox Backup Server entra en escena, junto con la incómoda cuestión circular de hacer copias de seguridad de la infraestructura usando una infraestructura que forma parte del propio sistema protegido.
El resultado no consiste tanto en encontrar un único destino de copias de seguridad perfecto como en crear capas que hagan que la recuperación sea lo bastante predecible para que las copias de seguridad dejen de ser algo en lo que Bob tenga que pensar constantemente.
Esa experiencia sirvió de base para nuestra guía de Proxmox Backup Server, que desarrolla la idea mediante copias de seguridad incrementales de máquinas virtuales y contenedores, retención, verificación y capas de protección adicionales.
Supervisar la flota en lugar de comprobarla constantemente
La siguiente pregunta de Bob es familiar para cualquiera cuyo homelab haya crecido más allá de un par de servicios: ¿cuánta supervisión necesita realmente una sola persona?
Su entrada Supervisar la flota explora herramientas como Pulse y Proxmox Data Center Manager, pero el objetivo más interesante es reducir la cantidad de atención manual que requiere la infraestructura.
Un sistema de supervisión útil no debería crear otro panel que haya que vigilar todo el día. Debería hacer que el funcionamiento normal sea silencioso y que los fallos sean visibles cuando realmente requieran atención.
Desarrollamos más esa parte de la experiencia de Bob en nuestra guía de supervisión de servidores domésticos, que abarca Pulse, Uptime Kuma, Proxmox Data Center Manager y el momento en que la supervisión debería reducir el mantenimiento en lugar de generarlo.
Dar un hogar permanente a un agente de IA
Con el tiempo, el diario pasa a otra capa del autohospedaje: ejecutar un agente de IA persistente en ZimaCube.
En Por qué Hermes Agent pertenece a tu ZimaCube, Bob analiza la máquina no simplemente como infraestructura de almacenamiento o virtualización, sino como un lugar siempre activo donde puede residir un agente autohospedado.
La combinación tiene sentido en el contexto de todo lo anterior. Una vez que ZimaCube ya está conectado las 24 horas, integrado en el homelab, respaldado y supervisado, un agente puede convertirse en otro servicio persistente, en lugar de estar ligado a una sesión en un portátil.
Si quieres explorar ese flujo de trabajo directamente en ZimaOS, nuestra guía de configuración de Hermes Agent para ZimaOS explica la instalación, la configuración del modelo, la integración de mensajería y el acceso al panel de Hermes.
Convertir ZimaCube en un router OPNsense
Uno de los experimentos posteriores más interesantes vuelve a llevar la máquina a un papel completamente diferente: infraestructura de red.
El diario de OPNsense de Bob analiza las dos interfaces 2.5GbE de ZimaCube junto con Proxmox y se pregunta si una máquina virtual de router podría ser uno de los usos más convincentes del hardware hasta ahora.
Aquí es donde la decisión anterior sobre el sistema operativo empieza a dar sus frutos. Proxmox permite que la misma máquina física aloje cargas de trabajo que tradicionalmente requerirían equipos independientes, mientras que las dos interfaces Ethernet ofrecen una vía natural para separar la WAN y la LAN dentro de una configuración de firewall virtualizado.
Nuestra guía de Proxmox también explora la ejecución de OPNsense como router de software en una máquina virtual en ZimaCube, incluida la idea de asignar interfaces 2.5GbE independientes al dispositivo de red.
El valor está en el diario, no en un veredicto final
Considerado en conjunto, el proyecto de Bob es mucho más interesante que una reseña con una conclusión fija.
El mismo ZimaCube aparece en varias formas diferentes a lo largo de la vida del repositorio.
Comienza como una pieza de hardware nueva. Bob la saca de la caja, inspecciona su construcción, abre el chasis, cuestiona la refrigeración y empieza a pensar en actualizaciones.
Se convierte en un experimento con Windows Server. Eliminar ZimaOS permite comprobar si el hardware subyacente sigue siendo útil sin el software con el que se entregó.
Vuelve a plantear la cuestión del sistema operativo. Bob evalúa ZimaOS por separado antes de decidir que su entorno, cada vez más complejo, necesita algo diferente.
Se convierte en un host de Proxmox. A partir de ahí, la máquina se integra en una flota más amplia y comienza a asumir responsabilidades de infraestructura.
Se convierte en parte del sistema de copias de seguridad y monitorización. Proxmox Backup Server, Pulse y la gestión de flotas cambian el objetivo de «seguir añadiendo servicios» a «hacer que los servicios sean lo bastante fiables como para dejar de pensar en ellos».
Después se convierte en un host de IA y un dispositivo de red. Hermes Agent y OPNsense no son experimentos aislados; son posibles porque las capas de infraestructura anteriores ya están instaladas.
El resultado es exactamente lo que Bob prometió originalmente: no una reseña formal, sino notas, experimentos, opiniones que cambian con la experiencia y un proyecto de homelab cada vez más ambicioso.
Una historia de usuario se convirtió en una biblioteca de guías sobre ZimaCube
El proyecto de Bob también demuestra por qué las pruebas comunitarias a largo plazo tienen valor más allá del homelab de una sola persona.
Varios experimentos documentados en el blog sobre la experiencia con ZimaCube se han convertido desde entonces en recursos más completos de Zima: instalación de Windows Server, implementación de Proxmox, selección del sistema operativo, arquitectura de copias de seguridad y monitorización del homelab.
Esto crea un ciclo útil entre la experiencia de la comunidad y la documentación. Bob prueba algo porque siente curiosidad. El diario registra lo ocurrido. Las partes útiles resultan más fáciles de reproducir para la siguiente persona.
La historia todavía se está escribiendo
La historia de Bob Loves Tech y Zima todavía se está escribiendo. Su blog sobre su experiencia con ZimaCube ya ha pasado por el desempaquetado y el desmontaje del hardware, ZimaOS, Windows Server, Proxmox, copias de seguridad, monitorización de flotas, Hermes Agent y OPNsense; y la idea central de un diario en curso es que no tiene por qué existir una configuración final.
A medida que cambia el homelab, también puede cambiar el papel de ZimaCube. Si quieres ver con qué experimenta Bob a continuación, sigue en GitHub el blog continuo de Bob Loves Tech sobre su experiencia con ZimaCube.
