Visión general

WhyStack es una división runner / control-plane. El edge es la mitad que corre en tu infraestructura: el Agent, los connectors, la redacción de PII y el contrato de comunicación. Nada de eso emite un juicio: recolecta, normaliza, redacta y responde.

Las dos mitades

La dirección es una sola: el control-plane pide, el Agent decide si puede y responde. La regla que separa los dos lados: la recolección, la normalización y la redacción ocurren en tu infraestructura; el juicio ocurre del otro lado, y solo sobre datos ya redactados.

Cómo se conecta el runner

El runner se conecta hacia afuera. No hay puerto de entrada, no hay endpoint de health expuesto, no hay nada que tengas que abrir en tu firewall para el tráfico de entrada. Abre un túnel WSS inverso con mTLS hacia el control-plane y atiende las llamadas desde dentro de él.

Eso tiene una consecuencia operativa que conviene conocer temprano: como el runner es cliente y no servidor, no hay probe de liveness HTTP. Su salud se observa en los logs de boot y en la vista Flota del control-plane.

Qué hace el runner en una llamada

El control-plane pide una operación del catálogo (por ejemplo, metrics.getServiceLatency).
El runner la valida contra el enforcement point: ¿la op está en el catálogo versionado? ¿Los argumentos validan en modo estricto contra su inputSchema? ¿Cabe en el deadline?
El connector correspondiente hace la llamada de solo lectura contra tu fuente, con credenciales leídas de tu secret manager.
El resultado pasa por la redacción en el borde: campo declarado, estructural y luego de contenido, en ese orden.
El resultado redactado vuelve por el túnel.

El control-plane pregunta qué. El runner decide si puede. Esas dos preguntas viven en lados distintos a propósito.

Terminología: “Agent” es el producto, `runner` es el código

El componente que corre en tu infraestructura se llama WhyStack Agent en el producto, en la UI y en la documentación para clientes, porque es el término conocido de observabilidad, como el Datadog Agent. En el código, el protocolo, las variables de entorno y el SPIFFE id se llama runner, y va a seguir así: renombrarlo rompería el contrato de wire y toda la superficie RUNNER_* sin ganar nada.

Si encuentras la palabra “agent” dentro del código de este repositorio, casi siempre significa otra cosa: el LLM que consume las tools. No confundas los dos.

WhyStack es el nuevo nombre de RootPilot

El producto tiene un nombre nuevo, y esta documentación ya lo usa en todo lo que ella misma elige. Tres grupos de identificadores mantienen rootpilot, porque cambiarlos solo en el texto rompería el comando:

Lo que definen la imagen y el protocolo: las imágenes (rootpilot-agent, rootpilot-profiler), rootpilot-health, las variables ROOTPILOT_*, los nombres de la base de Kubernetes, las métricas rootpilot.* y el SPIFFE id spiffe://rootpilot/tenant/<slug>/runner. Cambian junto con los servicios.
Los dominios: app.rootpilot.sh, tunnel.rootpilot.sh y este docs.rootpilot.sh. La documentación cambia cuando el dominio nuevo esté en línea.
Lo que tu instalación ya creó: el volumen rootpilot-identity y el servicio rootpilot-agent de Compose, y el perfil de AppArmor rootpilot-profiler. Renombrar el volumen en un up -d le costaría al Agent su identidad y un bootstrap token nuevo.

Los nombres que las guías sugieren para una instalación nueva ya son whystack: la policy de IAM, el prefijo de los secrets, el role de Vault, la cuenta de Argo CD, la entrada en el cliente MCP. Si tu instalación usa los nombres antiguos, mantenlos. Ningún componente de WhyStack los lee: solo conectan piezas que tú mismo configuraste.

Qué hay en cada paquete

Paquete	Qué es
`apps/runner`	El contenedor efímero. Enrollment, túnel, enforcement, redacción, drain.
`packages/connectors`	Los 15 clientes de fuentes externas: lecturas, salvo las seis escrituras de ticket, chat e issue.
`packages/core-edge`	Utilidades de borde: caché, errores, redactor de PII, catalog loader.
`packages/protocol`	El contrato versionado runner↔control-plane.
`packages/connector-sdk`	SDK abierto para escribir tus propios connectors.
`packages/otel`	Instrumentación OpenTelemetry compartida.
`packages/demo`	Un entorno ficticio completo, sin ninguna credencial.

Cattle, no pets

El runner no guarda estado durable. Las credenciales viven solo en memoria, el SQLite local es una caché y su valor por defecto es :memory:. Está hecho para morir: spot reclaim, OOM, docker compose down. Sube otro y el sistema sigue. No le hagas backup, no lo trates como un servidor con nombre y no guardes dentro de él nada que necesites recuperar.