Ctrl K
ComunidadGuías…
GITHUB · ANALIZADO

ai-helm

GitOps Helm charts para plataforma AI auto-alojada. Gestiona LibreChat, modelos AI vía Envoy Gateway, Keycloak y observabilidad unificada con Alloy/Grafana. Usa ArgoCD y patrones ADR.

Ficha actualizada 24 sept 2026, 13:38 · upstream 24 sept 2026, 13:32 · release webank-training-v0.3.1

Ver códigoProblemas y ayudaRepositorio ↗
00

Qué es ai-helm

Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.

Este repositorio actúa como fuente de verdad GitOps para una plataforma de IA auto-alojada, utilizando Helm charts y ArgoCD para orquestar la infraestructura en Kubernetes. La arquitectura se basa en un patrón de 'umbrella' que emite manifestos Application hacia otros workloads o repositorios upstream, separando la lógica de despliegue del estado específico del entorno.

CASOS DE USO
  • Desplegar una plataforma completa de IA con chatbots y modelos auto-alojados
  • Gestionar flotas de modelos AI mediante Envoy AI Gateway y políticas de tráfico
  • Implementar autenticación centralizada con Keycloak y gestión de roles
  • Centralizar métricas, logs y trazas en Alloy/Mimir/Loki/Tempo para Grafana
  • Operar bases de datos MongoDB y motores de búsqueda Meilisearch
  • Generar dashboards Grafana dinámicamente mediante scripts Python
PUNTOS DESTACADOS
  • Arquitectura GitOps clara con ArgoCD como punto de entrada único para el clúster
  • Documentación arquitectónica rigurosa mediante Architechture Decision Records (ADR)
  • Observabilidad unificada con atribución por usuario en logs estructurados
  • Uso de herramientas modernas de Python (uv, ruff) para generación de dashboards
  • Licencia MIT que permite uso y modificación abierta del código fuente
  • Soporte nativo para múltiples proveedores de modelos (Fireworks, DeepInfra, Google AI Studio)
PRECAUCIONES
  • Complejidad HIGH requiere conocimientos avanzados en Kubernetes, Helm y GitOps
  • Dependencia obligatoria de ArgoCD para la gestión del ciclo de vida del despliegue
  • Gestión de secretos a través de External Secrets Operator (ESO) requiere configuración previa
  • No incluye Dockerfiles propios; depende de imágenes upstream o contenedores predefinidos
  • Actualización de versiones de dependencias requiere auditoría manual de pins semver
01

Perfil de infraestructura

Estimación inicial derivada del repositorio y de los servicios detectados.

CPU4 vCPUrecomendación inicial
MEMORIA8 GBRAM estimada
DISCO30 GBalmacenamiento base
COMPLEJIDADhighnivel de operación
02

Despliegue detectado

Qué señales reales de instalación hemos encontrado.

Despliegue manual

Requiere clúster Kubernetes con ArgoCD instalado. Mínimo 4 cores CPU y 8GB RAM. Configurar External Secrets Operator para gestión de secretos. Fijar versiones de Helm explícitamente (semver/SHA). Verificar compatibilidad de imágenes upstream antes del despliegue.

—Dockerfile
—Compose
—One-click
03

Stack y dependencias

Componentes inferidos a partir de manifests, configuración y documentación.

FRAMEWORKS
RustPython
SERVICIOS
MongoDBMeilisearch
BASES DE DATOS
MongoDBMeilisearch
PUERTOS
No detectados
05

Puede sustituir a

Relaciones detectadas por el análisis del repositorio y su categoría.

06

Experiencia real de la comunidad

Ayuda a contrastar la estimación automática con instalaciones reales.

Todavía no hay datos comunitarios para este proyecto.