Como hospedar o OpenClaw por conta própria em 2026: Gateway, canais e segurança

Trate o OpenClaw como um sistema pequeno, não como uma imagem Docker. O objetivo do OpenClaw para o usuário é claro: um Gateway de assistente de IA com mais de 22 integrações de canais; a implantação só é aceitável quando você consegue parear um canal de mensagens, enviar uma mensagem recebida, aprovar o remetente, invocar uma ferramenta inofensiva e reconectar a Control UI depois de reiniciar o Gateway.

Essa distinção identifica o modo de falha que os operadores encontram após os testes locais: o Gateway faz bind apenas em loopback ou o proxy descarta os upgrades de WebSocket. Ela também torna o plano de backup e upgrade específico o suficiente para ser testado.

Escolha a menor topologia viável para o OpenClaw

A menor topologia responsável para o OpenClaw contém um listener privado na porta 18789, uma rota de ingress e um limite de estado documentado. O requisito externo do OpenClaw é uma chave de model provider e pelo menos um canal pareado. Teste o DNS de saída, o TLS e o comportamento do provider sem publicar outro serviço de entrada.

Valide a topologia pedindo a um cliente limpo que pareie um canal de mensagens, envie uma mensagem recebida, aprove o remetente, invoque uma ferramenta inofensiva e reconecte a Control UI depois de reiniciar o Gateway. Durante a execução, observe os turns paralelos dos agentes, a latência do modelo, os processos das browser tools e o tamanho do histórico de sessões acumulado. O resultado mostra se a próxima melhoria deve ser feita em memória, armazenamento, rede ou em um worker separado, em vez de incentivar um dimensionamento arbitrário do container.

Diagnostique um OpenClaw que parece saudável

Uma verificação de health em estado ocioso diz pouco sobre o OpenClaw. Observe os turns paralelos dos agentes, a latência do modelo, os processos das browser tools e o tamanho do histórico de sessões acumulado; depois, crie alertas para o sintoma percebido pelos usuários: a falha da ação “parear um canal de mensagens, enviar uma mensagem recebida, aprovar o remetente, invocar uma ferramenta inofensiva e reconectar a Control UI depois de reiniciar o Gateway”. Mantenha o liveness local e barato; deixe o readiness indicar migrações ou inicialização sem provocar uma avalanche de reinícios.

A área de upgrade mais arriscada é que uma release pode alterar o schema de configuração do Gateway, as skills incluídas, as dependências do browser ou os adaptadores de canais. Leia as release notes, faça um snapshot do estado, implante a versão-alvo usando uma cópia restaurada e repita a ação de aceitação. Se o Gateway fizer bind apenas em loopback ou o proxy descartar os upgrades de WebSocket, correlacione a requisição do cliente com o primeiro log relevante da aplicação, em vez de apagar o estado ou adicionar redirects às cegas.

Cinco verificações mais fortes que o health do container

O registro de release do OpenClaw precisa de fatos, não de um “parece bom”. Armazene o digest da imagem selecionada, o checksum da configuração, o hostname público e o resultado com timestamp de: parear um canal de mensagens, enviar uma mensagem recebida, aprovar o remetente, invocar uma ferramenta inofensiva e reconectar a Control UI depois de reiniciar o Gateway. Use dados de exemplo que não sejam de produção para que a verificação possa ser executada após cada deployment.

Comprove separadamente dois eventos do ciclo de vida. A substituição de um container deve preservar a operação normal; uma recuperação limpa deve mostrar que o Gateway restaurado consegue reabrir seu workspace, reconhecer o canal pareado e usar a autenticação do provider sem passar novamente pelo onboarding. Enquanto as verificações são executadas, meça os turns paralelos dos agentes, a latência do modelo, os processos das browser tools e o tamanho do histórico de sessões acumulado, e mantenha o resultado como o envelope esperado para essa versão.

Teste também uma condição negada ou inválida: negue temporariamente o caminho de teste usado por uma chave de model provider e por pelo menos um canal pareado. O OpenClaw deve falhar de forma diagnosticável e não deve sobrescrever o estado saudável. Restaure a condição válida, execute novamente o exemplo e anexe os logs relevantes com os dados sensíveis removidos. Esses artefatos fornecem evidências concretas para uma futura decisão de rollback.

Execute a primeira instância com formato de produção

Mantenha a primeira invocação do OpenClaw suficientemente reproduzível para ser revisada em um pull request.

docker run -d \
  --name openclaw \
  --restart unless-stopped \
  -p 127.0.0.1:18789:18789 \
  -v openclaw-data:/home/node/.openclaw \
  -e OPENCLAW_GATEWAY_TOKEN=replace-with-a-long-random-value \
  -e OPENCLAW_GATEWAY_BIND=lan \
  ghcr.io/openclaw/openclaw:latest node dist/index.js gateway --bind lan --port 18789

Não dependa de latest depois que houver dados reais. Registre o digest usado, o usuário do container e as permissões do mount. Acompanhe o log da aplicação durante um teste completo — parear um canal de mensagens, enviar uma mensagem recebida, aprovar o remetente, invocar uma ferramenta inofensiva e reconectar a Control UI depois de reiniciar o Gateway — e anote todas as migrações antes de colocar a rota atrás do tráfego de produção.

Torne a recuperação do OpenClaw mensurável

Uma imagem de container pode ser baixada novamente; o workspace, o estado dos canais e a configuração do OpenClaw não podem. Faça o mount de /home/node/.openclaw antes do bootstrap, grave dados de exemplo inofensivos e substitua o container para provar que esse caminho é realmente persistente. Inspecione o mount efetivo em vez de confiar no nome de um arquivo Compose e verifique se o usuário de runtime pode escrever onde o OpenClaw espera.

Defina a retenção e um destino externo ao host e depois ensaie a recuperação sem tocar na produção. O exercício só é aprovado quando o Gateway restaurado consegue reabrir seu workspace, reconhecer o canal pareado e usar a autenticação do provider sem passar novamente pelo onboarding. Para estados baseados em banco de dados, combine snapshots de armazenamento com exports consistentes com a aplicação, conforme descrito em recuperação point-in-time versus snapshots.

Teste o OpenClaw de fora do servidor

Trate a URL externa do OpenClaw como uma configuração que sobrevive a redeploys. Primeiro, configure o endereço público do Gateway e um proxy compatível com WebSocket; depois, encaminhe o hostname para a porta 18789 mantendo intactos o host e o scheme originais.

O checklist de reachability do deployment pode comprovar que as requisições entram no container. Depois desse ponto, a falha conhecida — o Gateway faz bind apenas em loopback ou o proxy descarta os upgrades de WebSocket — deve ser investigada no OpenClaw, em seu estado ou em sua carga de trabalho, e não na automação de certificados.

Reduza a autoridade mantida pelo OpenClaw

As credenciais de bootstrap são temporárias; o modelo de confiança é permanente. No OpenClaw, fique atento a deixar o token do Gateway sem definição ou aprovar pareamentos de canais desconhecidos; use um trust boundary por Gateway, revise cada pareamento de DM e coloque em sandbox as tools que tocam o host.

Trate OPENCLAW_GATEWAY_TOKEN de acordo com sua função no OpenClaw: mantenha valores sensíveis fora do Git, documente os efeitos da rotação e nunca substitua um exemplo público em produção. Execute a imagem sem capabilities desnecessárias do Linux e exponha apenas a rota pública da aplicação. Mantenha a atividade de administradores visível sem registrar valores secretos.

Conecte o OpenClaw ao ciclo de vida do Dockup

A camada de plataforma do OpenClaw consiste na porta 18789, ingress, TLS, configuração de runtime, armazenamento e reachability das dependências. O Dockup pode reproduzir essas partes em sua própria infraestrutura ou em um servidor conectado pelo cliente.

Depois, o operador conclui a camada de produto: configure o endereço público do Gateway e um proxy compatível com WebSocket; aplique esta regra de acesso — use um trust boundary por Gateway, revise cada pareamento de DM e coloque em sandbox as tools que tocam o host; e execute “parear um canal de mensagens, enviar uma mensagem recebida, aprovar o remetente, invocar uma ferramenta inofensiva e reconectar a Control UI depois de reiniciar o Gateway”. Registrar esse teste junto do deployment evita confundir o provisionamento automatizado com a prontidão da aplicação.

Perguntas frequentes

Do que o OpenClaw precisa para um deployment de produção?

Encaminhe o container do OpenClaw na porta 18789 por meio de uma única origem HTTPS. O requisito externo de entrega é uma chave de model provider e pelo menos um canal pareado. Não considere o OpenClaw pronto até conseguir parear um canal de mensagens, enviar uma mensagem recebida, aprovar o remetente, invocar uma ferramenta inofensiva e reconectar a Control UI depois de reiniciar o Gateway.

Quais dados do OpenClaw devem fazer parte de um backup?

Mantenha /home/node/.openclaw persistente e inclua o workspace, o estado dos canais e a configuração do OpenClaw no mesmo manifesto de recuperação. Uma restauração limpa do OpenClaw só é aprovada quando o Gateway restaurado consegue reabrir seu workspace, reconhecer o canal pareado e usar a autenticação do provider sem passar novamente pelo onboarding.

O OpenClaw precisa de HTTPS atrás de um reverse proxy?

Use HTTPS para a origem pública do OpenClaw e mantenha a porta 18789 na rota interna. Aplique corretamente a configuração do OpenClaw: configure o endereço público do Gateway e um proxy compatível com WebSocket. No OpenClaw, o HTTPS protege credenciais ou conteúdo do usuário durante o trânsito e mantém consistente o comportamento do cliente sensível à origem.

Como um upgrade do OpenClaw deve ser testado?

Restaure o estado atual do OpenClaw em um deployment isolado, aplique a versão candidata e repita sua transação de aceitação. Dê atenção especial a esse processo, pois uma release pode alterar o schema de configuração do Gateway, as skills incluídas, as dependências do browser ou os adaptadores de canais. Mantenha a imagem anterior do OpenClaw até entender os limites da migração de dados e do rollback.