Pré-requisitos

Runtime

Item	Versão	Para quê
Node.js	≥ 20	Buildar e testar os pacotes. O campo engines do repositório exige isso.
Docker	qualquer recente	Rodar o runner em container. A imagem é node:22-alpine.
npm	10+	Os workspaces do repositório.

Você não precisa de Node instalado para rodar o runner em container: só para buildar os pacotes ou desenvolver connectors.

Um control-plane do outro lado

O Agent é a metade “mãos”. Sozinho ele sobe, conecta e fica esperando: sem um control-plane escutando no túnel, ele não faz nada útil. Antes de instalar, tenha em mãos:

• O endereço da imagem e a autorização de pull para a sua conta ou projeto.
• A URL do túnel (RUNNER_TUNNEL_URL), em produção: wss://tunnel.rootpilot.sh:8443.
• O certificado do seu tenant: runner.crt, runner.key e ca.pem.

Os três itens são entregues pelo RootPilot na abertura do ambiente.

O hostname importa mesmo quando outro resolve para o mesmo IP

O certificado do túnel tem SAN DNS:tunnel.rootpilot.sh. Conectar por qualquer outro hostname falha a verificação de identidade do TLS com is not in the cert's altnames. Porta aberta não é o mesmo que hostname certo. Quem manda é o SAN do certificado.

Rede de saída

O runner precisa de egress, e só de egress. Nenhuma porta de entrada.

Sempre:

• tunnel.rootpilot.sh:8443 (WSS + mTLS), o túnel.
• O registry de onde vem a imagem (ECR ou Artifact Registry), no pull.

Sem enrollment, sem app.rootpilot.sh

Na instalação por imagem o Agent recebe o certificado pronto e não faz enrollment, então não precisa de egress para app.rootpilot.sh:443. Essa regra só é necessária se você usar o caminho de enrollment automático — veja Enrollment.

Conforme os connectors que você ligar (só os que usar):

Connector	Host de saída
datadog	api.datadoghq.com
github	api.github.com
aws, kubernetes	*.amazonaws.com, *.eks.amazonaws.com
gcp	*.googleapis.com
amplitude	amplitude.com
slack	slack.com
cloudflare	api.cloudflare.com
azion	api.azion.com
vercel	api.vercel.com
checkly	api.checklyhq.com
grafana	os endpoints dos seus datasources (Mimir, Loki, Tempo, stack)
mongo, sonarqube, jira	os seus próprios hosts, que você informa na configuração

Essa lista é declaratória, não um firewall

Os connectors nativos embrulham SDKs de terceiros que fazem HTTP por conta própria, então a allowlist de egress declarada no manifest não é aplicada a eles: ela documenta a intenção. A mediação real de egress é propriedade do mecanismo sidecar. Se você precisa de garantia, o lugar de aplicá-la é o seu próprio egress control (security group, NetworkPolicy, proxy).

Dimensionamento

Este repositório não publica números de CPU e memória, porque não existe benchmark versionado aqui, e inventar um seria pior que omitir. O que dá para afirmar pela construção:

• O processo é um Node de container único, sem worker pool.
• O cache SQLite é :memory: por default, então a memória cresce com o volume de dados aprendidos na sessão e zera a cada boot.
• O RUNNER_IDEMPOTENCY_MAX_ENTRIES (default 2000) limita o cache de idempotência de propósito, para um runner longevo não crescer sem teto.

Comece pequeno, observe, e ajuste. O runner é cattle: redimensionar é subir outro.

Credenciais das suas fontes

Nenhuma é obrigatória para subir. Cada connector é lazy, instanciado no primeiro uso, então faltar uma chave só faz aquelas operações responderem auth_error; o resto continua funcionando. A lista completa está em Credenciais por connector.

O Profiler tem pré-requisitos próprios, e mais duros

Tudo acima é do Agent. O RootPilot Profiler é um segundo artefato, opcional e privilegiado, e o que ele exige do host não tem interseção com esta página: kernel ≥ 5.8 com BTF compilado, cgroup v2, tracefs montado e cinco capabilities de kernel.

Esses portões reprovam hosts que ninguém espera ver reprovados, então eles se checam antes da POC e não durante: curl -O https://docs.rootpilot.sh/profiler-preflight.sh && sh profiler-preflight.sh. O script é publicado na íntegra na página do Profiler, para ser lido antes de ser executado.