h-sandbox
Control plane auto-alojado para aplicaciones de agentes que centraliza la gestión de entornos efímeros mediante API única, SDK TypeScript y CLI.
Ficha actualizada 23 sept 2026, 19:46 · upstream 23 sept 2026, 19:39 · release v0.4.0
Qué es h-sandbox
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Harakiri Sandbox es una plataforma de control para aplicaciones de agentes que transforma la infraestructura de sandbox en una experiencia de desarrollo consistente. Permite preparar entornos, ejecutar tareas, inspeccionar resultados y liberar runtime mediante una API única, SDK TypeScript, CLI y dashboard. Utiliza PostgreSQL como datastore del control plane y Keycloak-compatible OIDC para autenticación web.
La arquitectura separa explícitamente el control plane (responsabilidad de Harakiri) del proveedor de ejecución (responsabilidad del runtime). Actualmente usa OpenSandbox como default, pero la estructura permite otros proveedores sin hacer que uno sea la identidad del producto. Esto incluye un plan futuro para un runtime Harakiri propio.
El sistema soporta templates para imágenes de runtime, recursos, workdirs y versiones inmutables. Incluye gestión de credenciales mediante Credential Vault que da valores falsos al código mientras el runtime inyecta credenciales reales solo en HTTPS matching. Soporta egress control con networkPolicy compilado a OpenSandbox.
Es un Developer Preview auto-alojado, no un servicio hosted con SLA ni garantía multi-tenant hostil. No implementa concurrency admission ni metering histórico de uso. Workspace persistence no es backup; Vault y egress requieren runtime profile enforceable.
- Orquestación de agentes autónomos en entornos aislados y efímeros con limpieza automática post-ejecución
- Gestión segura de credenciales mediante Credential Vault con inyección dinámica solo en HTTPS matching
- Despliegue de workflows reproducibles con templates predefinidos (Python, OpenCode, etc.)
- Auditoría de ejecución con persistencia controlada de workspaces y verificación de provenance
- Exposición segura de servicios internos mediante rutas temporales con tokens de acceso restringido
- Arquitectura desacoplada entre control plane (Harakiri) y runtime provider (OpenSandbox por defecto)
- CLI robusto con gestión de rutas, egress control y Credential Vault integrado
- SDK TypeScript y API OpenAPI consistentes mantenidos en packages/shared
- Documentación exhaustiva con ejemplos verificados, runbooks y tutoriales end-to-end
- Soporte para múltiples proveedores de runtime sin atar identidad del producto
- Developer Preview sin SLA ni garantía multi-tenant hostil
- No implementado concurrency admission ni metering histórico de uso
- Dependencia crítica de OpenSandbox actualmente como runtime provider
- Workspace persistence no es backup; requiere Vault y egress enforceable
- Soporte restricted OpenShift no certificado por Helm rendering
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Recomendado iniciar con k0s local o Kubernetes estable. Pinning versiones específicas del CLI/SDK (ej: 0.5.0-rc.11). Revisar matriz de soporte de runtime antes de producción. No exponer seed identities a través de public ingress. Para contribución usar runtime-free local setup con fixtures no reales. Verificar docs/developer-preview.md y operator checklist antes de despliegue en entorno crítico.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
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.