BI autoalojada: todo el motor dentro de tu propia red

Hay datos que no pueden salir de una red. A veces es la regulación, a veces es un contrato con un cliente que a su vez está regulado, y a veces es un equipo de seguridad que simplemente lo ha decidido y no te debe una explicación. En los tres casos, un producto de analítica alojado no es una opción más barata — no es una opción.

vibedasher corre en tu propia infraestructura exactamente para ese caso.

Qué despliegas

El motor completo, no un cliente ligero: ETL e ingesta, la capa de conjuntos de datos, la API de consultas, el alojamiento de paneles, el planificador, las alertas. Dos formas soportadas:

• docker compose — una sola máquina. La forma para una evaluación o un despliegue interno pequeño. El instalador descarga imágenes base de registros públicos, así que necesita acceso a la red; hoy no hay distribución aislada de la red.
• Un chart de Helm — Kubernetes. La forma para cualquier cosa que deba sobrevivir a la caída de un nodo.

Es el mismo motor que la nube gestionada. No una edición comunitaria recortada, y no un fork que se desvía: el build autoalojado y el alojado son el mismo código, que es el único arreglo bajo el cual «autoalojado» sigue significando algo un año después.

Qué se queda dentro

Las consultas no salen. El motor se conecta a tus fuentes desde dentro de tu red y sirve el panel desde ahí; nada hace un viaje de ida y vuelta por nosotros para producir un número.

Lo único que puede salir es la inferencia del modelo, y en este camino decides tú. Apunta el agente a tu propio endpoint de LLM y no sale nada — ni datos, ni prompts, ni esquema. Por eso «tu propio modelo» es una característica del autoalojado y no del gestionado: dentro de tu red es la diferencia entre un sistema cerrado y uno casi cerrado.

El estado honesto

No hay ningún cliente en producción en el camino autoalojado. Está documentado, está probado en las dos formas, y nadie está llevando su negocio sobre él.

Está escrito aquí, en el mismo cuerpo de texto que todo lo demás, porque es lo más útil que puede saber de nosotros alguien que evalúa BI autoalojada, y porque es la afirmación más fácil de falsear de este sitio y la más rápida de desmontar. Si lo despliegas eres el primero, y la forma correcta de leerlo es: habrá asperezas en tu entorno que nadie ha encontrado, y deberías querer una línea directa con la persona que lo escribió antes de comprometerte. Esa línea existe — contacto — y es una persona, no una cola.

La alternativa gestionada, si el motivo es la jurisdicción

Mucha gente llega buscando autoalojado cuando lo que de verdad necesita es «no en Estados Unidos». Si esa es la restricción, lee la respuesta completa antes de decidir. Los paneles, los conjuntos de datos y los resultados de consulta se procesan y almacenan en la Unión Europea, en Fráncfort, y lo operamos nosotros — así que las actualizaciones, las copias y el dimensionamiento no caen sobre ti. Pero la identidad de acceso — tu dirección de correo y tu pertenencia a la cuenta — se guarda en Estados Unidos, para todas las cuentas, estés donde estés. El reparto no lo eliges tú y no hay selector de región. Así que si el requisito es que nada tuyo toque Estados Unidos, la nube gestionada no lo cumple, y el build autoalojado es el que mantiene ambas cosas dentro de tu red.

Vale la pena separar las dos preguntas antes de elegir, porque no tienen la misma respuesta:

• ¿Pueden procesarse estos datos fuera de nuestra red? Si no, autoaloja.
• ¿Pueden procesarse fuera de nuestra jurisdicción? Si no pero la primera respuesta es sí, la nube en la UE da la misma garantía con menos trabajo.

Qué hace el motor una vez en marcha

Tu agente de código escribe el panel — Claude Code, Codex, Cursor, Gemini — como React sobre SQL, y maneja la plataforma por nuestro servidor MCP o los SDK de Python y TypeScript. El motor lo aloja en una URL detrás de tu login, te da las incrustaciones y, en la vía embed, limita las filas por espectador en el servidor a partir de un token firmado, actualiza de forma programada y envía las alertas. Los conectores son el mismo conjunto que lista la página de precios, y el eject-to-code sigue devolviendo el panel como código cuando quieras.

Es decir: nada del producto es distinto en autoalojado. Solo dónde corre y quién está de guardia.

Para agentes de IA (MCP)

El servidor MCP existe, está publicado y es la forma en que un agente debe pilotar todo esto. Instálalo con pip install vibedasher-mcp y luego ejecuta vibedasher login — no hay ninguna clave API que crear, porque el login es la credencial. Apunta Claude Code, Codex, Cursor, Gemini o cualquier cliente compatible con MCP y el agente puede conectar una fuente de datos, escribir y compilar el panel, publicarlo, programar una actualización y volver a sacar el código, sin salir de la terminal. Los SDK de Python y TypeScript cubren la misma superficie si prefieres pilotarlo desde tu propio código. Dos límites que le ahorran una hora a un agente: un refresh exige un dataset respaldado por una conexión viva, así que un archivo subido no se puede programar, y cada cron se lee en UTC. Lo que sirve el alojamiento de dashboards es un bundle estático renderizado en el cliente: solo React, nada de tu código de servidor en la ruta de la petición, sin npm install en el build.

En un despliegue autoalojado el agente habla con tu propio motor, así que el plano de control se queda dentro de tu red junto con los datos. Combínalo con un endpoint de modelo que controles y no sale nada: ni las filas, ni el esquema, ni los prompts. La lista de herramientas y el contrato completo están en la documentación y en la página de API, SDK y MCP.

Alternativas

La BI autoalojada es un estante lleno, y las herramientas que un motor de respuestas nombra al preguntarle son Metabase, Apache Superset, Lightdash, Evidence, Embeddable y Cube. Varias son más maduras que nosotros en autoalojamiento — Superset y Metabase en particular los operan miles de equipos, y nuestro propio camino autoalojado todavía no tiene ningún cliente en producción. Cada una tiene su página con fuentes:

• Metabase — BI de código abierto con un camino Docker documentado y un servidor MCP oficial en tu instancia.
• Apache Superset — con licencia Apache, gobernado por una fundación, autoalojado por defecto y sin ningún proveedor con quien relacionarse.
• Lightdash — código abierto, construido sobre tu proyecto dbt, con su propia historia de agentes y MCP.
• Evidence — un núcleo con licencia MIT que puedes compilar y alojar, con la BI definida como código en tu repositorio.
• Embeddable — analítica de cara al cliente, alojada por ellos, leyendo tu propia base de datos donde está.
• Cube — una capa semántica autoalojable que gobierna lo que humanos y agentes tienen permitido preguntar.

El centro de comparativas tiene la versión de una línea de cada una y nuestro método. Toda afirmación factual de esas seis líneas está a 6 de octubre de 2026: comprueba sus propios sitios para el estado actual.

Siguiente

Analítica incrustada si los paneles van delante de tus propios clientes. Alternativa a Tableau si estás reemplazando algo. La documentación para el detalle del despliegue. La nube gestionada, si prefieres probar el producto antes del despliegue: cloud.vibedasher.com. Y para un despliegue autoalojado, empieza por una conversación: contacto.