Configuración
Configuración es el modo de la barra lateral donde viven los ajustes del workspace y de la instalación. Se entra con “Configuración”, abajo a la izquierda, y se vuelve con “Volver a la app”. Esta página cubre las secciones que no tienen página propia: Webhooks, API, Registro de auditoría, Salud, Actualizaciones, Idioma y Cuenta, más el panel “Acceso a la beta” que ve el operador de la SaaS. Miembros, Tableros, Motores de IA, Credenciales, MCPs, Sandboxes, Uso e Infraestructura se explican en sus páginas (ver Relacionado).
Casi todo pide rol administrador. Salud, Actualizaciones y la dirección de telemetría son de la instalación entera: el detalle completo lo ve un admin del workspace operador (en self-hosted, el que nombra OCTOPUS_OPERATOR_WORKSPACE; en modo dev, cualquiera). Para entender qué hace cada rol y qué protege cada clave, mirá Seguridad y auditoría.
Flujo recomendado: dejar lista una integración
Sección titulada «Flujo recomendado: dejar lista una integración»El orden que suele funcionar para conectar Thulu con otra herramienta (n8n, un pipeline de CI) es: un webhook para que Thulu avise, una API key para que la herramienta responda, y una mirada al registro de auditoría para confirmar qué pasó. Necesitás rol administrador en el workspace y la URL donde la otra herramienta recibe webhooks.
-
Abrí “Configuración → Webhooks”. En “URL del endpoint” pegá la dirección que te dio la otra herramienta. Tiene que ser pública: Thulu rechaza direcciones privadas o de loopback (“la política de salida bloquea ese destino”).
-
En “Eventos” dejá “Todos los eventos (*)” o destildalo y elegí los que te interesan; el rótulo pasa a “2 eventos”. Apretá “Agregar webhook”.
Cada endpoint muestra a qué eventos está suscripto, con los botones Entregas, Probar, Rotar secreto y eliminar. -
Copiá el secreto de firma que aparece arriba de la lista (“Copialo ahora: no se va a volver a mostrar”) y cargalo en el receptor. Cada entrega viaja firmada en el header
X-Octopus-Signature: sha256=<hmac>, un HMAC-SHA256 del cuerpo con ese secreto.
El secreto se muestra una sola vez. Si lo perdés, rotalo. -
Apretá “Probar” en la fila: Thulu manda una entrega de prueba y avisa “Entrega de prueba OK: HTTP 200 en 85 ms”, o el código o el motivo con que falló.
-
Andá a “API” y generá una clave para la herramienta (detalle en API keys). Copiala al toque: tampoco se vuelve a mostrar.
-
Abrí “Registro de auditoría” y confirmá que figuran el alta del webhook y de la clave.
Webhooks
Sección titulada «Webhooks»Un webhook es un endpoint externo al que Thulu le hace un POST cada vez que pasa algo en el workspace. Los eventos que se pueden elegir son 12:
| Evento | Cuándo se dispara |
|---|---|
task.created, task.stage_changed, task.deleted |
Se crea una tarea, cambia de etapa o se borra |
chat.message |
Llega un mensaje a un chat |
boards.changed, stages.changed, task_types.changed |
Se crea, renombra o borra un tablero (o cambia el predeterminado), se editan sus columnas o cambian sus tipos de tarea |
question.asked, question.answered, question.canceled |
Un agente pregunta algo en una tarea, alguien contesta o la pregunta se cancela |
approval.requested, approval.decided |
Se pide una aprobación o alguien la decide |
No hay evento para comentarios, PRs ni corridas fallidas. Si una entrega falla (error de red o respuesta fuera de 2xx), Thulu la intenta hasta 5 veces en total, con esperas de 2, 4, 8 y 16 segundos, y después la marca como fallida. El historial de entregas se guarda 30 días: “Entregas”, en la fila de cada endpoint, muestra los últimos intentos con cuándo, evento, resultado y tiempo, y “Reintentar” vuelve a encolar una entrega.
“Rotar secreto” pide confirmación y genera un secreto nuevo: el anterior deja de verificar desde la próxima entrega, así que tené a mano el receptor para actualizarlo enseguida. El tacho borra el endpoint sin preguntar.
La sección API tiene cuatro paneles.
Especificación OpenAPI
Sección titulada «Especificación OpenAPI»“openapi.json” abre la especificación de toda la API REST (OpenAPI 3.1) y “Copiar URL” copia su dirección para importarla en Postman, Insomnia o un generador de clientes.
Dirección de telemetría
Sección titulada «Dirección de telemetría»La URL pública por la que una aplicación desplegada llega a este Thulu para mandarle métricas. Los agentes que configuran telemetría la leen de acá. Debajo del campo se ve la dirección completa a la que van a enviar (“Las aplicaciones van a enviar a https://…/ingest”). Si no sabés cuál es, dejala vacía: los agentes reciben “dirección desconocida” en vez de una equivocada. Es un valor de la instalación: sólo lo guarda el operador; otros admins lo ven bloqueado. Más contexto en Métricas y dashboards.
API keys
Sección titulada «API keys»Una API key da acceso a la API sin sesión, para CI, scripts o integraciones. Cada clave pertenece al workspace donde la creaste y tiene tres límites que se suman:
| Campo | Qué decide | Notas |
|---|---|---|
| Nombre | Cómo la reconocés en la lista y en la auditoría | Si lo dejás vacío queda “Clave de API” |
| Rol (“lector”, “desarrollador”, “administrador”, “dueño”) | Cuánta autoridad tiene | Nunca más que tu propio rol: los roles superiores aparecen deshabilitados |
| Permisos | Sobre qué partes de la API actúa | Lectura y escritura por grupo (Tareas, Tableros y etapas, Proyectos, Agentes, Corridas y uso, Credenciales, Configuración, Miembros), más “Emitir claves” y “Rutas de servicio” |
| Vencimiento (días) | Cuándo deja de funcionar | Arranca en el máximo de la instalación (90 días por defecto, OCTOPUS_API_KEY_MAX_TTL); en blanco también es el máximo |
Una llamada tiene que pasar las dos cosas: el rol alcanza para esa ruta y el permiso cubre ese grupo. Los presets llenan los casilleros y después podés ajustarlos:
| Preset | Qué tilda |
|---|---|
| “Sólo lectura” | Lectura de todo salvo credenciales |
| “CI” | Tareas (lectura y escritura), Proyectos y Corridas (lectura) |
| “Agente” | Tareas (lectura y escritura), Tableros y Proyectos (lectura), Corridas (lectura y escritura), Rutas de servicio |
| “Todo” | Todos los casilleros |
-
En “Clave de API” escribí un nombre que diga quién la usa (“Exportador nocturno de métricas”).
-
Elegí el rol y un preset, y destildá lo que sobre.
-
Ajustá el vencimiento si querés menos que el máximo y apretá “Generar clave”.
El preset tilda casilleros; lo que se manda es lo que queda tildado. -
Copiá la clave (
oct_…) con “Copiar”. Debajo, Thulu dice qué concedió y hasta cuándo.
Cada fila de la lista dice rol, permisos, vencimiento, quién la emitió y su último uso.
Si pedís algo que tu rol o el de la clave no permite, el daemon lo rechaza y lo explica en rojo debajo del formulario, por ejemplo: “una key viewer no puede usar flows:write, projects:write, …; necesitan un rol más alto”. También avisa si pasás el máximo de días.
Para cambiar una clave sin cortar la herramienta que la usa, apretá “Rotar” en su fila: Thulu crea una clave nueva con el mismo nombre, rol y permisos y la muestra una sola vez. En “La clave actual sigue funcionando” elegís cuánto dura la vieja (nada, 1 hora, 24 horas, 3 días o 7 días); mientras tanto la fila dice “La reemplazó otra; funciona hasta el” y la fecha.
Para dar de baja una clave apretá “Revocar” en su fila y confirmá. No se puede deshacer; queda en la lista marcada “revocada”.
Claves de corridas en curso
Sección titulada «Claves de corridas en curso»Cada corrida de agente y cada chat recibe su propia clave, que Thulu revoca al terminar. Este panel lista las que están vivas ahora, y no aparecen en la lista de arriba. Si una clave sigue acá después de que su corrida terminó, revocala: la corrida pierde acceso a la API en el acto.
Registro de auditoría
Sección titulada «Registro de auditoría»Lista lo que pasó en el workspace, de lo más nuevo a lo más viejo: inicios de sesión, altas y bajas de miembros y claves, tareas, aprobaciones, preguntas, cambios de agentes y credenciales, actualizaciones. Columnas: “Hora”, “Evento”, “Actor”, “Recurso” y “Resumen”. El selector filtra por familia (task.*, auth.*, approval.* y otras), “Cargar más” trae la página siguiente y el botón de recarga la actualiza.
Actor dice quién hizo cada cosa: la persona, la API key por su nombre, la corrida de un agente o Thulu mismo. Cuando el recurso todavía existe, la columna Recurso es un link a él.
“Verificar” recalcula el hash de cada entrada y dice cuántas cubre la cadena y cuál es su hash de cabeza; si encuentra una rota, “Ir a la entrada” la muestra.
“Exportar CSV” y “Exportar NDJSON” bajan todo lo que coincide con el filtro actual, sin límite de páginas. NDJSON es una entrada JSON por línea, listo para un SIEM. Exportar requiere una licencia Enterprise en la instalación (OCTOPUS_LICENSE_KEY); sin ella la sección lo explica y el registro se guarda y se muestra igual. Cómo verificar la integridad del registro y mandarlo fuera de la máquina está en Seguridad y auditoría.
“Salud” muestra un chequeo por cada parte de la base de datos, Docker y disco, el tiempo activo y, en “Sistema”, la versión de Go, las goroutines y los GB libres. El indicador de arriba resume todo (“ok”) y el botón de recarga vuelve a preguntar. El reporte completo sólo lo ve el operador; un admin de otro workspace recibe el estado general.
El panel “Licencia” muestra la edición (Community o Enterprise) y, con licencia, el licenciatario, el vencimiento con los días que faltan y las funciones habilitadas. En una instalación Docker, la licencia Enterprise agrega exportar la auditoría; el runtime de Kubernetes también la pide (ver Operación self-hosted).
El panel “Retención y limpieza” fija cuánto se guarda lo que dejan las corridas antes de que el janitor lo borre. 0 lo guarda para siempre y un campo vacío vuelve al valor por defecto. Los plazos están en Seguridad y auditoría.
Actualizaciones
Sección titulada «Actualizaciones»Muestra la versión que corre, el canal y si corre en Docker o Kubernetes, cada cuánto Thulu busca releases nuevas y el resultado de la última búsqueda. Thulu no se actualiza solo y esta pantalla no cambia nada: da los comandos.
| Panel | Qué tiene |
|---|---|
| “Versión” | Versión, canal, runtime, el botón “Buscar ahora” y avisos de seguridad conocidos de la versión en marcha |
| “Versiones disponibles” | Cada release más nueva con fecha, migraciones, si volver atrás requiere restaurar la base, variables nuevas, pasos manuales, el comando para copiar y “Descargar paquete de cambios” (Markdown o JSON, para un ticket de cambio) |
| “Volver atrás” | Las versiones guardadas en el host con el comando que vuelve a cada una (en Kubernetes, thulu update -to <versión>) |
| “Historial” | Cada arranque en una versión nueva y cada corrida de actualización, con quién la hizo |
- Abrí “Actualizaciones” y apretá “Buscar ahora” si querés no esperar a la próxima búsqueda automática.
- En la release que te interesa, apretá “Descargar paquete de cambios” para revisar qué va a hacer.
- Copiá el comando y corrélo en la máquina que administra la instalación. El CLI verifica la firma de la release, saca un snapshot de la base y vuelve atrás solo si algo falla. Detalle en Operación self-hosted.
- Volvé a la pantalla: “Historial” registra el cambio.
En la SaaS esta sección la ve sólo el operador; para el resto dice que la versión “sólo se le muestra a un admin del espacio de trabajo operador”.
Un selector, “Idioma del dashboard”, con español e inglés. Al elegir uno la página se recarga en ese idioma. Vale para este navegador: se guarda en una cookie, no en tu cuenta. Los textos que escribe el daemon (comentarios en tareas, resúmenes de auditoría, errores de la API) siguen el idioma de la instalación, que en self-hosted se cambia con OCTOPUS_LOCALE=es.
Aparece sólo cuando hay inicio de sesión (no en modo dev). Tiene:
- “Tu perfil”: correo, nombre, workspace actual y rol.
- “Sesiones activas”: cada navegador o dispositivo con tu sesión abierta, cuándo empezó y su último uso, con “Cerrar sesión” por fila y “Cerrar sesión en los demás dispositivos” (no pide confirmación; la sesión actual sigue).
- “Tus workspaces”: con qué proveedor iniciaste sesión, tus workspaces con “Renombrar” y, en el que sos dueño, “Pasar a otro dueño” y “Borrar workspace”. Se explican en Workspaces y equipo.
- “Términos y privacidad” y “Borrar tu cuenta”, que borra también los workspaces donde sos el único miembro y pide escribir tu correo para confirmar.
No hay contraseña ni segundo factor para configurar acá: los maneja tu proveedor de identidad.
Acceso a la beta (SaaS)
Sección titulada «Acceso a la beta (SaaS)»En la SaaS, el operador ve en “Miembros” un panel más: “Acceso a la beta”. Mientras la instalación esté en modo lista (OCTOPUS_SIGNUP_MODE=allowlist), sólo los correos de esta lista pueden crear una cuenta, y sólo si el proveedor de identidad verificó ese correo. Los miembros del workspace del operador entran siempre.
- Abrí “Configuración → Miembros” y bajá hasta “Acceso a la beta”.
- Escribí el correo y, en “Nota”, quién es y por qué entra.
- Apretá “Invitar”. La fila muestra quién la agregó y cuándo.
El tacho quita el acceso: la persona no puede volver a entrar y sus sesiones abiertas terminan en unos minutos. Si un workspace invitó a alguien que la lista todavía no admite, aparece en “Esperando acceso” con el botón “Dar acceso”.
Problemas comunes
Sección titulada «Problemas comunes»- “Cuenta” o “Miembros” no aparecen: la instalación corre sin login (modo dev).
- Actualizaciones dice “no disponible”: no sos admin del workspace operador.
- No puedo exportar la auditoría: la instalación no tiene licencia Enterprise.