MCP

Archestra, plataforma de IA corporativa: para quem é e o primeiro início com Docker

Equipes que querem concentrar o acesso MCP num ambiente auto-hospedado têm razão para testar uma vez o quickstart Docker do Archestra; mas o comando de início monta o /var/run/docker.sock do host e grava em volumes locais, e archestra/platform:latest normalmente roda um release candidate — aceite os dois pontos antes de testar.

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 quem é

  • O posicionamento oficial é «a plataforma de IA corporativa open source tudo em um»: ela assume ao mesmo tempo os papéis de MCP registry, gateway e orchestrator, e não é um MCP server de propósito único. O formato que se encaixa: uma equipe auto-hospeda a plataforma nas próprias máquinas e aponta usuários, agent e clientes Claude / Codex / Cursor para a mesma URL; as chamadas de ferramentas ficam por conta da plataforma e os clientes conhecem uma única entrada.
  • Seu MCP gateway usa OAuth + On-Behalf-Of para que as ferramentas executem como o próprio usuário, e não como uma conta de serviço compartilhada; equipes que se importam em atribuir cada chamada a uma pessoa são claramente beneficiadas.
  • Critério de decisão: se o seu problema é só «falta uma ferramenta em um cliente», um único MCP server basta; a camada de plataforma só entra quando é preciso unificar vários serviços, vários clientes e várias identidades.
  • Ambiente adequado: equipes que conseguem rodar Docker localmente ou na intranet e aceitam avaliar o custo da montagem do socket; o quickstart amarra as portas ao endereço de loopback, o que serve para testar primeiro em uma máquina e partir para uso contínuo depois de aceitar os efeitos.
  • Pré-requisito: ter Docker na máquina. A evidência não traz configuração mínima de recursos, faixa de sistemas operacionais suportados nem modo de execução fora do Docker — tudo isso segue sem confirmação.

Primeira tentativa em 3 minutos

  • Antes de agir, confirme que você aceita os dois efeitos declarados explicitamente pela documentação oficial: primeiro, o comando monta o /var/run/docker.sock do host, e com isso o contêiner passa a controlar o daemon Docker do host; segundo, o tag latest da imagem aponta para o release mais recente e normalmente roda um release candidate. Os dois pontos estão na nota oficial e entram na avaliação desde o início — não são detalhes para depois da implantação.
  • O primeiro início também não é uma operação somente leitura: os volumes nomeados archestra-postgres-data e archestra-app-data gravam os dados do banco e da aplicação em volumes Docker locais; não existe comando oficial de limpeza ou reversão, e a evidência não diz se dados antigos atrapalham inícios novos entre experimentos repetidos — não teste por cima em um host com dados importantes.
  • Depois de aceitar, execute o comando oficial de início 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
  • O sinal de sucesso confirmável vai até aqui: o contêiner continua rodando e as duas portas se amarram apenas ao endereço de loopback 127.0.0.1; a configuração exigida explicitamente pelo quickstart é ARCHESTRA_QUICKSTART=true mais esse conjunto de portas e montagens. Amarradas só ao loopback, por padrão apenas a máquina local acessa; como configurar acesso remoto não consta na evidência.
  • O passo seguinte é apontar Claude / Codex / Cursor para essa única URL; o valor exato da URL não está no comando e se confirma no lado da plataforma depois da subida. Como se faz o primeiro login, igualmente não se menciona.

Casos de uso

  • Caso 1: entrada única para vários clientes. Cenário: na equipe umas pessoas usam Claude, Codex e Cursor e ninguém quer ligar o MCP separadamente em cada cliente. Prática: suba a plataforma com o início rápido acima e aponte os clientes para a mesma URL do Archestra. O que esperar: as chamadas passam pelo MCP gateway e executam como o próprio usuário, com as mesmas ferramentas chegando aos três clientes pela mesma entrada. Limite: a evidência não lista quais serviços a plataforma aceita; confirme antes de ligar que os serviços de que você precisa estão incluídos.
  • Caso 2: sem cair em conta de serviço compartilhada. Cenário: a equipe não aceita que todas as chamadas de ferramentas fiquem registradas no nome de uma conta de serviço compartilhada. Usa o mesmo mecanismo de identidade do gateway. Prática: depois de ligar, confira se as ferramentas rodam como o próprio usuário; se hoje a automação roda numa conta compartilhada, dá para comparar antes e depois. Confirmável: o enunciado oficial diz exatamente isso; o visual da interface de configuração de contas e dos logs de chamada não aparece na evidência — não presuma que existam.
  • A diferença entre os dois casos: o caso 1 verifica a unificação da entrada, o caso 2 verifica a atribuição de identidade; teste cada um uma vez, em sequência.

Limites de uso

  • Natureza de leitura/escrita: o primeiro início já grava estado local (dois volumes nomeados); a montagem do socket dá ao contêiner a capacidade de controlar contêineres do host — o efeito mais pesado, a avaliar em separado.
  • Credenciais e identidade: o gateway depende de OAuth; como configurar o provedor e se é obrigatório ligar antes uma fonte de identidade não estão explicados na evidência, seguem sem confirmação.
  • Relação cliente-plataforma: a linha oficial é apontar usuários, agent ou clientes para uma URL e deixar a plataforma cuidar do resto; quais versões ou plugins cada cliente precisa não se menciona.
  • Limite de versão: a linha oficial é que implantações de produção devem fixar um tag de versão exato; latest normalmente corresponde a um release candidate, não coloque carga real sobre ele diretamente.
  • Ordem das ações: aceite primeiro a montagem do socket e a questão da versão, depois execute o comando; faça a primeira tentativa preferencialmente em loopback local, sem abrir direto para a rede pública.
  • Informações-chave sem confirmação: consumo de recursos, etapas de upgrade e rollback, forma de backup dos dados, declarações de leitura/escrita das ferramentas MCP dentro da plataforma, política inicial de credenciais — nada disso está coberto pela evidência; não coloque dados reais no ambiente da primeira tentativa. Não achar documentação não significa ausência de risco; a referência é a documentação oficial.