Goliat: dashboard open source de inventario y FinOps Azure
En pocas palabras: Goliat es un dashboard open source (MIT) que Daniel J. Saldaña lanzó el 29 de octubre de 2026 en dev.to, self-hosted en el propio tenant de Microsoft Azure, con acceso de solo lectura. Recolecta inventario vía Resource Graph y ARM, lo guarda en Blob Storage y lo importa a PostgreSQL, con 73 vistas y módulo FinOps de costos.
El Goliat Azure FinOps dashboard es una herramienta self-hosted que recolecta el inventario de recursos de Azure vía Resource Graph y ARM, lo publica como un JSON versionado en Blob Storage y lo importa a PostgreSQL para mostrarlo en un panel web. Sirve para responder preguntas transversales sobre varias suscripciones (qué corre, qué falta taguear, cuánto se gastó) sin depender solo del portal nativo de Microsoft.
En este artículo:
- En 30 segundos
- ¿Qué problema resuelve Goliat en entornos con múltiples suscripciones de Azure?
- ¿Qué funcionalidades incluye el dashboard de inventario y FinOps de Goliat para Azure?
- ¿Cómo funciona la arquitectura técnica de Goliat?
- ¿Qué medidas de seguridad implementa Goliat?
- ¿Cómo se despliega o se prueba Goliat Cloud Inventory?
- ¿Qué stack tecnológico usa Goliat y bajo qué licencia se distribuye?
- Errores comunes al implementar Goliat
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- Daniel J. Saldaña lanzó Goliat Cloud Inventory el 29 de octubre de 2026 en dev.to, bajo licencia MIT.
- El dashboard tiene 73 vistas en 12 grupos de servicios de Azure, desde compute hasta seguridad y tags.
- El módulo FinOps cruza costos reales y amortizados de Azure Cost Management y nunca muestra datos faltantes como costo cero.
- El collector corre con una identidad administrada de solo lectura (Reader), sin secretos en el código.
- El despliegue por defecto no es gratis: usa PostgreSQL Flexible Server B1ms, que no escala a cero.
¿Qué problema resuelve Goliat en entornos con múltiples suscripciones de Azure?
El problema que ataca Goliat es simple de describir y molesto de vivir: el portal de Azure muestra un recurso a la vez, pero no responde preguntas que cruzan varias suscripciones a la vez, como qué máquinas virtuales están corriendo, qué recursos no tienen el tag Owner o cuánto se gastó en AKS el mes pasado.
Ponele que administrás ocho suscripciones de Azure repartidas entre distintos equipos. Querés saber, en un solo lugar, qué VMs quedaron encendidas de más, qué recursos se crearon sin el tag correspondiente y cuánto gastó el clúster de AKS la semana pasada. En el portal nativo tenés que entrar suscripción por suscripción, abrir Cost Management acá, Resource Graph allá, y armar el cruce a mano (spoiler: nadie tiene tiempo para eso todos los días).
Saldaña describe esa fricción en su publicación original en dev.to: quería un solo lugar para esas respuestas, corriendo en su propio tenant y con acceso de solo lectura. Por eso construyó Goliat y lo liberó como open source.
Nada nuevo bajo el sol, en realidad. El dolor de la visibilidad multi-cuenta en la nube es viejo. Lo que cambia acá es la propuesta: self-hosted, sin depender de un SaaS de terceros que termine viendo tus recursos. Tema relacionado: conectarte por SSH a tus VMs de Azure.
¿Qué funcionalidades incluye el dashboard de inventario y FinOps de Goliat para Azure?

Goliat organiza el inventario en 73 vistas repartidas en 12 grupos de servicios (compute, containers, redes, storage, bases de datos, seguridad, integración, datos e IA, observabilidad y tags) y suma un módulo de FinOps que cruza costos reales y amortizados directamente desde Azure Cost Management.
- Inventario por categorías. Cada grupo tiene un overview con KPIs y gráficos, y cada tabla soporta filtro por suscripción, búsqueda, filtros de columna, agrupamiento, orden, paginación y exportación.
- Búsqueda global con Ctrl+K. Permite buscar recursos, IDs, tags y suscripciones sin hacer ninguna llamada extra a la nube, porque el buscador trabaja sobre lo que ya está cargado en memoria.
- FinOps sin maquillaje. Si falta un dato o un permiso, Goliat lo muestra explícito, nunca como costo cero, y jamás mezcla monedas distintas en un mismo cálculo.
- Administración del collector. Un panel muestra la salud de la Function, PostgreSQL y Blob Storage, el cronograma del collector, los tag keys monitoreados y un aviso si el inventario publicado difiere del importado.
- Roles con Entra ID. El login usa Microsoft Entra ID, con una vista opcional de Members para otorgar o revocar el rol de admin, con registro de auditoría.
La interfaz es bilingüe, inglés y español. Detalle chico, pero para equipos de Latinoamérica que laburan con Azure en inglés y reportan en español, ahorra bastante traducción manual todos los días.
¿Cómo funciona la arquitectura técnica de Goliat?
La arquitectura separa la recolección de datos de la presentación: una Azure Function junta el inventario y lo publica como un único documento JSON versionado en Blob Storage, y un backend en Next.js lo valida e importa a PostgreSQL en una sola transacción.
Primero corre la Azure Function (Flex Consumption), disparada por timer, por cola o por una llamada HTTP autenticada; consulta Azure Resource Graph, completa los huecos con ARM, valida el documento entero y lo publica con una condición de ETag, y si alguna query falla, no publica nada.
El backend de Next.js baja el blob, valida el contrato de versión y mete las 73 vistas en PostgreSQL en una sola transacción. Según la documentación del repositorio en GitHub, el contrato usa schemaVersion 2 con 69 reportes de origen más cuatro vistas que calcula el propio backend. Si la importación falla, queda la foto anterior; el mismo ETag nunca se importa dos veces.
¿Y si apretás el botón Refresh? Le pide a la Function una generación nueva con un token de Entra, espera la publicación, importa y recarga la UI. Un lock de PostgreSQL (advisory lock) permite solo un refresh manual a la vez entre todos los usuarios y réplicas. Sobre eso hablamos en certificaciones de Azure según tu rol. ¿Qué medidas de seguridad implementa Goliat?
¿Qué medidas de seguridad implementa Goliat?
Goliat corre con identidades administradas en todos los componentes, sin secretos en el código ni credenciales que lleguen al navegador, y aplica mínimo privilegio: el collector solo tiene el rol Reader sobre las suscripciones que inventaría.
- Identidades administradas en todo el pipeline. No hay secretos hardcodeados; las credenciales nunca cruzan hacia el navegador.
- Mínimo privilegio real. El collector tiene Reader y nada más. El servicio web suma acceso de lectura a blobs, el rol Cost Management Reader y dos roles custom chicos para métricas y gestión de la Function.
- Solo configuración, nunca contenido. El collector no lee el contenido de los blobs, datos de la base, secretos de Key Vault, claves de cuenta ni connection strings.
- Fail closed. Si la configuración de autenticación está mal, Goliat bloquea el acceso; nunca cae en modo público por default. Los roles se revisan de nuevo en el servidor en cada request.
- Logging cuidadoso. Nunca registra bodies de requests, cookies, tokens, query strings ni SQL.
¿Alguien auditó esto de forma independiente? Hasta el 29 de octubre de 2026 no hay una auditoría externa publicada, así que el diseño de seguridad queda, por ahora, en la palabra del propio autor y en lo que cualquiera puede revisar leyendo el código.
¿Cómo se despliega o se prueba Goliat Cloud Inventory?
Goliat se despliega completo en un único resource group de Azure usando Bicep más un wrapper de PowerShell (goliat.ps1), y también se puede probar en local con datos falsos sin tocar una cuenta real de Azure.
El flujo típico es .\goliat.ps1 init, .\goliat.ps1 plan y .\goliat.ps1 deploy -GrantReader -RunAfterDeploy. Por default, eso crea un App Service F1, un PostgreSQL Flexible Server B1ms, una Function Flex Consumption y una cuenta de Storage.
Ojo con esto: no es gratis. PostgreSQL Flexible Server no escala a cero, así que el servidor consume aunque nadie lo use. Por eso el proyecto suma comandos stop, start y destroy-plan para controlar el gasto. Lo explicamos a fondo en comparativa entre Microsoft y GitHub.
Para quien prefiera contenedores, el Dockerfile tiene tres targets: runner, collector y migrator. Si tu equipo además administra hosting o dominios fuera de Azure para proyectos locales, en Argentina plataformas como donweb.com cubren esa parte sin que tengas que mezclarla con el stack cloud. Y si solo querés ver de qué se trata sin pelearte con Azure, alcanza con Node.js y PostgreSQL en local: npm ci, copiar el .env.example, npm run db:init y npm run db:seed, que carga una demo con 5 suscripciones y 214 recursos ficticios. También existe un demo interactivo online que corre entero en el navegador, sin cuenta de Azure, con inventario, FinOps, gestión de usuarios y panel de admin incluidos.
¿Qué stack tecnológico usa Goliat y bajo qué licencia se distribuye?
Goliat se distribuye bajo licencia MIT y corre sobre Next.js 16, React, shadcn/ui, Tailwind CSS 4 y Recharts en el frontend, con Auth.js, PostgreSQL y Azure Functions en Node.js del lado del backend, más Bicep y PowerShell para la infraestructura.
El testing incluye unit tests, pruebas de integración contra PostgreSQL y tests de navegador con Playwright en desktop y mobile. Corren en cada push vía GitHub Actions y, esto es lo interesante, no necesitan credenciales de nube para ejecutarse.
Es un proyecto de una sola persona, Daniel J. Saldaña, publicado el 29 de octubre de 2026. No tiene respaldo corporativo ni es un producto de Microsoft. Tomalo con pinzas en ese sentido: el soporte depende de que el autor siga manteniendo el repo.
Errores comunes al implementar Goliat
- Asumir que es gratis porque es open source. El código no cuesta nada, pero correr PostgreSQL Flexible Server B1ms y el resto de la infraestructura en Azure sí genera factura mensual.
- Darle más permisos de los que necesita al collector. El diseño pide Reader nomás. Asignarle Contributor “por si acaso” rompe el principio de mínimo privilegio que el propio autor marca como prioridad.
- No revisar el contrato de versión del JSON. Si tocás el pipeline de collection a mano, el backend puede rechazar el blob por schemaVersion desalineado; conviene seguir la documentación del repo antes de meter mano ahí.
- Probarlo en producción sin pasar por la demo local primero. Con npm run db:seed podés cargar 214 recursos ficticios y ver toda la UI sin gastar un centavo en Azure. Saltearse ese paso es perder tiempo debuggeando en un entorno real.
Preguntas Frecuentes
¿Qué es Goliat Cloud Inventory?
Goliat Cloud Inventory es un dashboard self-hosted y open source, bajo licencia MIT, que junta el inventario de recursos de Azure y los costos de Azure Cost Management en un solo panel con 73 vistas. Lo publicó Daniel J. Saldaña el 29 de octubre de 2026.
¿Cómo optimizar costos en Azure con Goliat?
El módulo FinOps de Goliat cruza costos reales y amortizados por servicio, suscripción, grupo de recursos y recurso individual, con evolución diaria. La clave es que nunca disfraza un dato faltante como costo cero, así que los números que ves son confiables para tomar decisiones de baja de recursos ociosos. Esto se conecta con lo que analizamos en repos de Microsoft comprometidos con malware.
¿Qué permisos necesita Goliat para funcionar en Azure?
El collector solo necesita el rol Reader sobre las suscripciones a inventariar. El servicio web suma acceso de lectura a blobs, el rol Cost Management Reader y dos roles custom pequeños para métricas y gestión de la Function, nada más.
¿Es gratis usar Goliat Cloud Inventory?
El código es gratis porque está bajo licencia MIT, pero correrlo en Azure no lo es. El despliegue por defecto incluye PostgreSQL Flexible Server B1ms, que no escala a cero y genera costo fijo mensual mientras esté levantado.
¿Cómo se instala un dashboard de FinOps para Azure como Goliat?
Se instala en Azure con Bicep y el wrapper goliat.ps1 (init, plan, deploy), o se prueba en local con Node.js y PostgreSQL usando npm run db:seed para cargar una demo de 5 suscripciones y 214 recursos ficticios sin tocar una cuenta real.
Conclusión
Lo que cambia con Goliat no es la idea de tener visibilidad multi-suscripción en Azure, eso ya lo resuelven herramientas comerciales de FinOps desde hace rato. Lo que cambia es que un proyecto individual, publicado el 29 de octubre de 2026 bajo licencia MIT, te deja correrlo entero en tu propio tenant, con el código a la vista y sin mandar tus datos de costos a un tercero.
Si administrás varias suscripciones y ya te cansaste de armar reportes a mano cruzando el portal con Excel, vale la pena probar primero la demo local con datos ficticios antes de desplegar nada en Azure real. Ahí vas a ver si las 73 vistas te cubren lo que necesitás, sin gastar un peso. Lo que no vas a tener, al menos todavía, es una auditoría de seguridad independiente ni un historial largo de producción: es un proyecto nuevo, y como tal, conviene monitorear cómo evoluciona el repo antes de confiarle el inventario completo de una empresa grande.






