MCP

Archestra, plataforma de IA empresarial: para quién es y primer arranque con Docker

Los equipos que quieren unificar el acceso MCP en un entorno autohospedado tienen motivo para probar una vez el quickstart Docker de Archestra; pero el comando de arranque monta el /var/run/docker.sock del anfitrión y escribe en volúmenes locales, y archestra/platform:latest suele ejecutar una release candidate: acepta ambos puntos antes de probar.

Official source · Archestra

Install

docker pull archestra/platform:latest

docker run \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
  -e ARCHESTRA_QUICKSTART=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v archestra-postgres-data:/var/lib/postgresql/data \
  -v archestra-app-data:/app/data \
  archestra/platform:latest

Para quién es

  • El posicionamiento oficial es «la plataforma de IA empresarial open source todo en uno»: ejerce a la vez de MCP registry, gateway y orchestrator, no de un MCP server de propósito único. La forma que encaja: un equipo autohospeda la plataforma en sus propias máquinas y apunta a usuarios, agent y clientes Claude / Codex / Cursor hacia una misma URL; las llamadas a herramientas las asume la plataforma y los clientes solo conocen una entrada.
  • Su MCP gateway usa OAuth + On-Behalf-Of para que las herramientas se ejecuten como el propio usuario y no como una cuenta de servicio compartida; los equipos a los que importa atribuir cada llamada a una persona se benefician con claridad.
  • Criterio de decisión: si tu problema se reduce a «a un cliente le falta una herramienta», basta con un único MCP server; la capa de plataforma solo entra cuando hay que unificar varios servicios, varios clientes y varias identidades.
  • Entorno adecuado: equipos que pueden ejecutar Docker en local o en la intranet y están dispuestos a evaluar el coste del montaje del socket; el quickstart liga los puertos a la dirección de loopback, lo que vale para probar primero en una sola máquina y pasar al uso prolongado cuando se acepten los efectos.
  • Requisito previo: tener Docker en la máquina. La evidencia no indica recursos mínimos, sistemas operativos soportados ni formas de ejecución distintas de Docker: todo eso queda sin confirmar.

Primera prueba en 3 minutos

  • Antes de actuar, confirma que aceptas los dos efectos que la documentación oficial declara de forma explícita: uno, el comando monta el /var/run/docker.sock del anfitrión, con lo que el contenedor puede manejar el daemon Docker del anfitrión; dos, el tag latest de la imagen apunta a la release más reciente y normalmente ejecuta una release candidate. Ambos puntos figuran en la nota oficial y se cuentan en la evaluación; no son detalles para después del despliegue.
  • El primer arranque tampoco es una operación de solo lectura: los volúmenes con nombre archestra-postgres-data y archestra-app-data escriben los datos de la base de datos y de la aplicación en volúmenes Docker locales; no hay comando oficial de limpieza o deshacer, y la evidencia no dice si los datos antiguos afectan a arranques nuevos entre experimentos repetidos: no lo pruebes a la ligera en un anfitrión con datos importantes.
  • Una vez aceptado, ejecuta el comando oficial de inicio rápido:
docker pull archestra/platform:latest

docker run \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
  -e ARCHESTRA_QUICKSTART=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v archestra-postgres-data:/var/lib/postgresql/data \
  -v archestra-app-data:/app/data \
  archestra/platform:latest
  • La señal de éxito confirmable llega hasta aquí: el contenedor sigue en marcha y los dos puertos se ligan solo a la dirección de loopback 127.0.0.1; la configuración que el quickstart exige explícitamente es ARCHESTRA_QUICKSTART=true más ese juego de puertos y montajes. Al ligarse solo a loopback, por defecto únicamente accede la máquina local; cómo configurar el acceso remoto no aparece en la evidencia.
  • El paso siguiente es apuntar Claude / Codex / Cursor a esa única URL; el valor concreto de la URL no viene en el comando y se confirma desde el lado de la plataforma tras arrancar. Cómo se completa el primer inicio de sesión tampoco se menciona.

Casos de uso

  • Caso 1: entrada única para varios clientes. Escenario: en el equipo hay quien usa Claude, Codex y Cursor y nadie quiere conectar MCP por separado en cada cliente. Práctica: arranca la plataforma con el inicio rápido de arriba y apunta los clientes a la misma URL de Archestra. Qué esperar: las llamadas pasan por el MCP gateway y se ejecutan como el propio usuario, con las mismas herramientas llegando a los tres clientes por la misma entrada. Límite: la evidencia no da la lista de qué servicios admite la plataforma; confirma antes de conectar que los que necesitas están.
  • Caso 2: sin cuenta de servicio compartida. Escenario: el equipo no acepta que todas las llamadas queden registradas a nombre de una cuenta de servicio compartida. Usa el mismo mecanismo de identidad del gateway. Práctica: tras conectar, comprueba si las herramientas corren como el propio usuario; si hoy automatizas con una cuenta compartida, puedes comparar antes y después. Confirmable: el enunciado oficial dice eso; el aspecto de la interfaz de configuración de cuentas y de los registros de llamadas no aparece en la evidencia, no des por hecho que existen.
  • La diferencia entre los dos casos: el caso 1 verifica la entrada unificada y el caso 2 la atribución de identidad; pruébalos una vez cada uno, en secuencia.

Límites de uso

  • Naturaleza de lectura/escritura: el primer arranque ya escribe estado local (dos volúmenes con nombre); el montaje del socket da al contenedor la capacidad de manejar los contenedores del anfitrión: es el efecto más pesado y debe valorarse aparte.
  • Credenciales e identidad: el gateway depende de OAuth; cómo se configura el proveedor y si hay que conectar antes una fuente de identidad no lo explica la evidencia: sin confirmar.
  • Relación cliente-plataforma: la postura oficial es apuntar a usuarios, agent o clientes a una URL y dejar que la plataforma se ocupe del resto; qué versiones o plugins necesita cada cliente no se menciona.
  • Límite de versiones: la postura oficial es que los despliegues de producción deben fijar un tag de versión exacto; latest suele corresponder a una release candidate, no le cargues trabajo real directamente.
  • Orden de acciones: acepta primero el montaje del socket y lo de las versiones, y ejecuta después el comando; la primera prueba, mejor complétala en loopback local, sin abrirla directamente a la red pública.
  • Información clave sin confirmar: consumo de recursos, pasos de actualización y reversión, copias de seguridad, declaraciones de lectura/escritura de cada herramienta MCP de la plataforma, política de credenciales inicial: la evidencia no cubre nada de esto; no metas datos reales en el entorno de la primera prueba. Que no aparezca documentación no significa que no haya riesgo; la referencia son los documentos oficiales.