Quickstart

Este caminho sobe o RootPilot Agent com o ambiente de demonstração: o catálogo inteiro respondido a partir de um fixture, sem uma única credencial sua, com um incidente plantado que sempre acabou de acontecer.

É a primeira coisa a fazer numa instalação nova. Ele valida a canalização — a imagem roda no seu ambiente, o certificado é válido, o túnel é alcançável — antes de você provisionar qualquer credencial. Se algo falhar aqui, falharia igual na instalação real, só que com secrets no meio.

O que você precisa

O endereço da imagem e a autorização de pull, que o RootPilot envia.
Uma identidade para o Agent — na maioria das instalações é um bootstrap token, que você mesmo minta em Onboarding no control-plane. Se o RootPilot lhe entregou um certificado já emitido (runner.crt, runner.key, ca.pem), ele serve igual aqui. Ver Identidade e enrollment.
A URL do túnel (RUNNER_TUNNEL_URL).
Egress HTTPS até o host do túnel. Nenhuma porta de entrada.

1. Puxe a imagem

# AWS (ECR)
docker pull <conta-rootpilot>.dkr.ecr.<região>.amazonaws.com/rootpilot-agent:<versão>

# GCP (Artifact Registry)
docker pull <região>-docker.pkg.dev/<projeto-rootpilot>/rootpilot/rootpilot-agent:<versão>

A imagem é multi-arquitetura: o mesmo endereço serve amd64 e arm64.

O registry é privado — se o pull falhar com no basic auth credentials, você ainda não autenticou. São dois comandos, um por cloud, em A imagem › Autenticar antes do pull.

2. Suba em modo demo

Com bootstrap token — o caminho que a página de Onboarding lhe dá pronto:

docker run --rm \
  -e RUNNER_TUNNEL_URL=wss://tunnel.rootpilot.sh:8443 \
  -e RUNNER_ENROLL_URL=https://app.rootpilot.sh \
  -e RUNNER_ATTESTATION_MODE=bootstrap-token \
  -e RUNNER_BOOTSTRAP_TOKEN=<o token que você mintou> \
  -e RUNNER_CONNECTORS=demo \
  <endereço-da-imagem>

Com certificado provisionado, se foi o que você recebeu: coloque os três PEMs num diretório e monte-o em /certs — o entrypoint os carrega sozinho, e nem RUNNER_ENROLL_URL nem o token são necessários.

docker run --rm \
  -v "$PWD/certs:/certs:ro" \
  -e RUNNER_TUNNEL_URL=wss://tunnel.rootpilot.sh:8443 \
  -e RUNNER_CONNECTORS=demo \
  <endereço-da-imagem>

Nenhuma credencial sua entra em nenhum dos dois. O modo demo responde de um fixture.

3. Confirme o boot

Os logs saem em JSON, uma linha por evento:

{"level":"info","message":"boot: liveness","context":"runner","instanceId":"..."}
{"level":"info","message":"enrolled","context":"runner","spiffeId":"spiffe://rootpilot/tenant/<você>/runner"}
{"level":"info","message":"boot: ready","context":"runner","instanceId":"..."}
{"level":"info","message":"hello accepted","context":"runner","sessionId":"..."}

Com certificado provisionado, a segunda linha é using provisioned cert e carrega um notAfter — a data em que ele vence.

O hello accepted é a linha que importa: a partir dela o Agent está conectado e aparece no Fleet do control-plane.

Se aparecer disconnected, reconnecting em ciclo, o Agent está de pé e o túnel não: confira a URL, o egress e a validade do certificado. Veja o troubleshooting.

Os três modos de dados

RUNNER_CONNECTORS decide de onde vêm as respostas. Escolher errado aqui é a causa mais comum de “instalei e as ferramentas retornam lixo”.

Modo	Credenciais	O que responde
`synthetic`	nenhuma	Default da imagem. Um seed de 3 operações com formatos que não batem com os connectors reais. Serve para provar boot e handshake, não para exercitar ferramentas.
`demo`	nenhuma	Catálogo inteiro (~190 ops) a partir de um fixture, com time-shift. É o modo deste quickstart.
`real`	as suas	As APIs de verdade. É o modo de produção.

Próximo passo

Para instalar valendo: Deploy em produção.
Para conectar as suas fontes: Modos de connector e Credenciais por connector.