Credenciais por connector

Esta é a lista extraída dos manifests dos connectors. Os nomes precisam bater exatamente. Uma chave com nome divergente produz o mesmo sintoma de uma chave ausente: o connector sai do served-set em silêncio, com um connector not served no log de boot como único sinal.

Nenhuma credencial é necessária para o runner subir. Cada connector é lazy: faltar uma chave só faz aquelas operações responderem auth_error.

Esta página diz quais chaves criar, não com que permissões

Para os escopos de cada uma (incluindo a policy IAM pronta da AWS, os escopos do Datadog e o RBAC que o EKS exige além do IAM), veja Escopos e permissões.

Observabilidade

datadog, grafana e signoz são mutuamente exclusivos. Veja Backend de observabilidade.

datadog

Chave	Obrigatória
DD_API_KEY	sim
DD_APP_KEY	sim
DD_SITE	não. datadoghq.eu, us3, us5, ap1 conforme a organização

grafana

Chave	Obrigatória
GRAFANA_CLOUD_TOKEN	sim
GRAFANA_PROM_URL	sim. Mimir é a espinha
GRAFANA_PROM_USER	não. ID numérico da instância; sem ele o token vai como Bearer
GRAFANA_LOKI_URL, GRAFANA_LOKI_USER	não
GRAFANA_TEMPO_URL, GRAFANA_TEMPO_USER	não
GRAFANA_STACK_URL	não. API de Alerting
GRAFANA_SYNTHETICS_URL	não
GRAFANA_SERVICE_LABEL, GRAFANA_ENV_LABEL, GRAFANA_NAMESPACE_LABEL, GRAFANA_HOST_LABEL, GRAFANA_ROUTE_LABEL	não, mas ajuste se os seus labels não seguem a convenção

signoz

Auto-hospedado: o endpoint costuma ser interno, alcançável porque o runner roda dentro da sua rede. Exige a API query_range v5. Serve metrics, logs, traces, topology e monitors — não serve rum nem synthetics.

Chave	Obrigatória
SIGNOZ_ENDPOINT	sim. Ex.: http://signoz.observability.svc.cluster.local:8080
SIGNOZ_API_KEY	sim. Service account, header SIGNOZ-API-KEY
SIGNOZ_SERVICE_FIELD, SIGNOZ_ENV_FIELD, SIGNOZ_NAMESPACE_FIELD, SIGNOZ_HOST_FIELD, SIGNOZ_ROUTE_FIELD	não. Defaults semconv OTel; ajuste se a sua instrumentação divergir

checkly

Especialista em synthetics. Presente, assume a capability de quem for o provider geral.

Chave	Obrigatória
CHECKLY_API_KEY	sim
CHECKLY_ACCOUNT_ID	na prática, para token de usuário. Sem ele a API responde 401 sem dizer por quê. Dispensável para token de conta ou serviço.

Nuvem

aws

Chave	Obrigatória
AWS_ACCESS_KEY_ID	sim, no modo static
AWS_SECRET_ACCESS_KEY	sim, no modo static
AWS_SESSION_TOKEN	não. Credenciais temporárias de STS
AWS_REGION	não pelo manifest, mas obrigatória na atestação aws-sts

Com RUNNER_AWS_CRED_MODE=chain, nenhuma chave é injetada: a cadeia default resolve. Veja Credenciais de nuvem.

kubernetes

Acoplado à AWS: reusa exatamente as mesmas chaves AWS_*. Não há credencial separada.

Adicionalmente, EKS_CLUSTER, fora do manifest, lida do ambiente. Sem ela o health check responde skipped: no cluster configured.

gcp

Chave	Obrigatória
GCP_SA_KEY	sim no modo static. O JSON da service account em uma linha. Desnecessária em chain.
GCP_PROJECT_ID	não
GCP_REGION	não
GCP_BILLING_EXPORT_TABLE	não. Sem ela a operação de custo do GCP falha de forma explícita

Código e deploy

github

Chave	Obrigatória
GITHUB_TOKEN	sim. Leitura basta; o escopo de escrita é opcional (ver abaixo)

O GitHub é o único connector de código com uma operação de escrita: create_github_issue, que abre uma issue no seu repositório. Ela é opcional e você decide pela credencial — um token só de leitura faz a operação falhar dentro da sua infraestrutura, e a ferramenta some da superfície do agente. Não há flag porque não é preciso: o escopo do token já é o interruptor. Nenhuma outra escrita existe no GitHub — nem pull request, nem branch, nem workflow, nem secret. Ver O que o agente escreve.

vercel

Ortogonal ao GitHub: cria operações próprias e não disputa dono com ele.

Chave	Obrigatória
VERCEL_TOKEN	sim. Use um token read-only escopado ao time
VERCEL_TEAM_ID	na prática, para token de time. Sem ele a API responde 403 sem explicar. Ausente em conta pessoal.

argocd

Ortogonal ao GitHub e à Vercel: cria operações próprias e não disputa dono com nenhum dos dois. O servidor costuma ser interno ao seu cluster, e o RootPilot o alcança por rodar lá dentro.

Chave	Obrigatória
ARGOCD_SERVER_URL	sim. Ex.: https://argocd-server.argocd.svc.cluster.local
ARGOCD_TOKEN	sim. Conta local com RBAC de leitura, via argocd account generate-token

O RootPilot lê o rollback, nunca o dispara — nem sync, nem rollback, nem terminate, nem delete. Ele também não pede refresh, que é um parâmetro de leitura da API do Argo CD com efeito de escrita: ele força reconciliação no seu cluster. Um token com RBAC somente de leitura é o interruptor que garante isso do seu lado; ver Escopos e permissões.

sonarqube

Chave	Obrigatória
SONARQUBE_HOST	sim
SONARQUBE_TOKEN	sim

Dados e produto

amplitude

Chave	Obrigatória
AMPLITUDE_API_KEY	sim
AMPLITUDE_SECRET_KEY	sim
AMPLITUDE_TZ_OFFSET_MINUTES	não

AMPLITUDE_TZ_OFFSET_MINUTES é o offset do fuso do projeto Amplitude em relação a UTC, em minutos (BRT = -180). A API lê as datas de janela como YYYYMMDD no fuso do projeto, e não expõe qual é — sem o offset, um projeto em BRT tem toda leitura entre 21:00 e 00:00 local caindo no dia seguinte: o número volta certo para a pergunta errada. Ausente = UTC.

As operações de usuário e de session replay do Amplitude são as que passam pela camada estrutural de redação de PII. Veja Redação de PII.

mixpanel

Alternativa ao Amplitude, não adição: os dois servem as mesmas operações, então quem escolhe é RUNNER_ANALYTICS=amplitude|mixpanel (default amplitude). Ver Backend de observabilidade.

Chave	Obrigatória
MIXPANEL_SERVICE_ACCOUNT	sim. Service account de projeto, no formato <nome>.<id>.mp-service-account
MIXPANEL_SERVICE_SECRET	sim
MIXPANEL_PROJECT_ID	sim. Com service account ele não é opcional
MIXPANEL_REGION	não. eu ou in para residência de dados — muda o host
MIXPANEL_ACTIVE_USER_EVENT	não, mas sem ele “usuários ativos” não tem resposta — ver abaixo

A Mixpanel serve 8 das 16 operações de analytics. As outras não estão pendentes: não existe API de Boards, e o Insights só responde por bookmark de relatório salvo. As ferramentas correspondentes somem da superfície do agente, em vez de responderem vazio.

“Usuários ativos” precisa da sua convenção

A Query API da Mixpanel não mede usuários ativos entre eventos: a segmentação exige um evento e não aceita curinga, e o Insights responde apenas por relatório salvo. Declare em MIXPANEL_ACTIVE_USER_EVENT qual evento significa “usuário ativo” na sua instrumentação (por exemplo App Open). Sem ele a leitura devolve nulo com o motivo — nunca zero, que num número desses seria lido como “ninguém usou o produto”.

Três operações usam endpoints que a Mixpanel declara em maintenance mode (segmentação, funis e stream de atividade). Elas continuam servidas, e a resposta diz isso — a alternativa que a própria Mixpanel recomenda, o Insights, responde só por relatório salvo e por isso não cobre consulta ad-hoc.

A Query API tem cota de 60 consultas por hora e 5 concorrentes, por projeto.

mongo

Chave	Obrigatória
MONGO_URI	sim

Rede

cloudflare

Chave	Obrigatória
CLOUDFLARE_API_TOKEN	sim

azion

Chave	Obrigatória
AZION_TOKEN	sim. Atenção: não é AZION_API_TOKEN

Tickets e chat

Os únicos connectors com operações de escrita: cinco no total, todas cobertas por confirmação humana em duas camadas. Veja Modelo de segurança.

jira

Chave	Obrigatória
JIRA_HOST	sim
JIRA_EMAIL	sim
JIRA_API_TOKEN	sim

slack

Chave	Obrigatória
SLACK_BOT_TOKEN	sim

Ao adicionar um connector

A chave precisa entrar em duas listas, ou ela nunca chega ao container:

1. docker-compose.yml, na lista environment: (pass-through, nome puro sem =).
2. runner.secrets.env.example, para quem usa o fallback por arquivo.

O teste apps/runner/tests/connectors/env-surface.test.ts falha se você esquecer de uma delas.