Respuesta actual: los widgets nativos de HTML o JavaScript arbitrarios no son una función publicada de ZimaOS
La propuesta de 2026 solicitaba widgets capaces de mostrar el clima, temporizadores Pomodoro, controles de Pi-hole, memos, chat de IA y respuestas de endpoints personalizados. Actualmente, ZimaOS ofrece tarjetas de sistema integradas y una API OpenAPI para integraciones, pero no documenta una función nativa que permita a los usuarios pegar HTML, CSS o JavaScript arbitrarios en el panel de inicio. Esto significa que la solicitud sigue siendo una idea de ampliación del producto, mientras que los paneles externos basados en API ya son viables hoy.
Usa la OpenAPI de ZimaOS para obtener datos en lugar de extraerlos del panel
Actualmente, ZimaOS ofrece interfaces programáticas para el almacenamiento, los usuarios y los servicios del sistema. Un panel personalizado puede llamar a esas API y mostrar sus propias tarjetas sin depender de rutas privadas del frontend. La OpenAPI de ZimaOS es la superficie de integración estable.
Homarr es la vía más rápida para crear un panel personalizado
Si el objetivo es la composición visual y no la integración nativa, Homarr ya ofrece widgets de arrastrar y soltar, integraciones, iconos y autenticación. La instalación de Homarr con Docker proporciona la vía de implementación actual. Los requisitos de aplicaciones de ZimaOS ayudan a dimensionar el servicio adicional.
Por qué ejecutar JavaScript arbitrario dentro de la interfaz de administración es de alto riesgo
Un widget capaz de ejecutar JavaScript sin restricciones dentro del panel NAS autenticado compartiría un origen con privilegios elevados. Un widget malicioso o defectuoso podría leer datos, activar acciones o capturar información de sesión. Si se introducen widgets nativos, un diseño más seguro necesitaría aislamiento, ámbitos de permisos y una API de widgets controlada.
Los riesgos de scripting entre sitios de OWASP explican el problema central de seguridad del navegador.
Prefiere widgets de solo lectura para la supervisión
El uso de la CPU, la capacidad de almacenamiento, las temperaturas, el tiempo de actividad y el estado de los servicios son más fáciles de exponer de forma segura que las acciones de escritura. Un botón para «desactivar Pi-hole» o «reiniciar el contenedor» necesita una autenticación, trazabilidad y confirmación más sólidas, porque un clic en el panel puede cambiar el estado de la infraestructura.
Realiza consultas de forma eficiente en lugar de hacerlo cada pocos segundos
Las consultas frecuentes generan solicitudes constantes en segundo plano en un servidor de bajo consumo. Para el almacenamiento, las temperaturas y el estado de los servicios, normalmente basta con intervalos de 30–60 segundos. El clima quizá solo necesite actualizarse cada varios minutos. Cuando sea posible, usa actualizaciones basadas en eventos en lugar de consultar todo con el mismo intervalo.
Mantén los secretos en el servidor
Si un widget necesita un token de API para el clima, Pi-hole, la IA u otro servicio, no lo integres en el JavaScript del navegador. Usa un proxy backend o una integración del lado del servidor que mantenga las credenciales fuera del paquete del cliente. El proxy HTTPS de ZimaOS resulta útil cuando los servicios necesitan acceso desde el navegador.
Usa un panel independiente cuando quieras la máxima libertad
Un contenedor de panel independiente ofrece control total sobre el diseño y las integraciones sin modificar ZimaOS. También resiste mejor los rediseños del frontend de ZimaOS. En lugar de clonar todos los controles del sistema en una capa personalizada, enlaza con el panel de administración nativo para las tareas con privilegios.
Qué necesitaría un sistema nativo seguro de widgets
Una implementación sólida debería definir manifiestos de widgets, permisos solicitados, renderizado aislado, límites de frecuencia, compatibilidad de versiones, secretos del lado del servidor y una diferencia clara entre los widgets de solo lectura y los que modifican datos. La mejor parte de la solicitud original es la necesidad de una superficie de extensibilidad de primera clase, no la ejecución de código sin restricciones.
Versiona tu panel personalizado por separado de ZimaOS
Mantén el código de los widgets, los adaptadores de API y la configuración bajo control de versiones. Cuando ZimaOS cambie una versión de la API o el flujo de autenticación, podrás actualizar la integración de forma deliberada en lugar de perder un script editado manualmente dentro de un contenedor. Una pequeña capa de compatibilidad también permite que el mismo panel se comunique con varios dispositivos ZimaOS sin duplicar código.
Preguntas frecuentes
¿Puedo añadir widgets personalizados directamente a ZimaOS?
El material público actual no documenta los widgets de HTML/JavaScript definidos arbitrariamente por el usuario como una función integrada.
¿Puedo crear un panel de ZimaOS con OpenAPI?
Sí. Los paneles externos pueden usar las API compatibles de ZimaOS y mostrar sus propios widgets.
¿Deberían los widgets almacenar las claves de API en JavaScript?
No. Mantén las credenciales de los servicios en el servidor.
¿Es Homarr una buena alternativa?
Sí, cuando el objetivo es un panel personalizable en lugar de modificar la interfaz nativa de ZimaOS.
¿Por qué no permitir JavaScript arbitrario?
El panel es una superficie de administración autenticada, por lo que los scripts sin restricciones crearían importantes riesgos de XSS y de escalada de privilegios.
