Se 2026 acabar sendo o ano em que agentes de IA deixarão de ser apenas demos para se tornar ferramentas operacionais de verdade, o OpenClaw merece estar nessa conversa.E não digo isso no sentido de buzzword.
Digo em um sentido prático, de engenharia: o OpenClaw reúne mensageria, ferramentas, automação, memória e fluxos de trabalho do dia a dia em um único sistema.Ainda assim, este texto não é sobre hype.
É sobre prática.Mais especificamente, é sobre como eu configurei o OpenClaw para o meu próprio uso, o que funcionou bem, o que não funcionou tão bem e o que aprendi ao longo de cerca de um mês usando-o em uma arquitetura remota, em vez do modelo mais simples em que tudo roda na mesma máquina.Quando digo “arquitetura remota”, quero dizer que o assistente roda inteiramente em um host remoto e é acessado pela rede, em vez de compartilhar a mesma máquina com o usuário.
Por que eu não queria o modelo local padrão
Rodar o OpenClaw localmente é simples.Mas eu não queria um assistente que existisse apenas na máquina que, por acaso, estivesse aberta na minha frente.
Eu queria algo que pudesse acessar de qualquer lugar, com um controle de acesso forte, e com uma fronteira de isolamento entre o host e o runtime do assistente para não precisar fingir que ambos pertencem à mesma zona de confiança.Essa decisão parece simples.
Na prática, ela muda completamente o provisionamento, pois muitas ferramentas modernas de IA ainda assumem tacitamente um setup local.
Por que eu usei meu home lab em vez de um VPS
Para começar, esse setup reflete uma escolha pragmática: eu já tenho um home lab.Então, para mim, usar o hardware que eu já tinha era simplesmente mais econômico do que subir um VPS e pagar todo mês para ter uma “máquina isolada” só para o assistente.
Se a capacidade de computação, armazenamento e rede já existe em uma infraestrutura que eu controlo, faz mais sentido reaproveitá-la.Mas o custo foi só parte da decisão.Um setup em home lab também me deu algumas vantagens adicionais:
controle mais direto sobre o host, a rede e o modelo de isolamento
mais liberdade para experimentar diferentes formas de isolar componentes e rotear o tráfego entre eles
nenhuma necessidade de adaptar o setup a imagens ou políticas genéricas de provedores
um ambiente mais limpo para integrar o sistema com outras ferramentas e serviços hospedados na minha própria infraestrutura (self-hosted) no futuro
Também existe uma razão mais ampla pela qual esse caso de uso importa.
Nem todo mundo quer, por padrão, rodar um sistema de IA em infraestrutura alugada de terceiros.Algumas pessoas já têm ambientes bastante capazes, então um VPS nem sempre é a escolha mais óbvia.
E, em alguns contextos corporativos, a questão nem é custo — é governança.Dependendo do ambiente, equipes podem se preocupar com coisas como:
por onde transitam os dados conversacionais e operacionais
se ferramentas internas deveriam rodar em infraestrutura externa
até que ponto o host pode ser integrado aos controles de rede existentes
quanto controle existe sobre isolamento, logging e exposição
Isso não faz de um VPS uma escolha ruim.
Para muita gente, é o caminho mais rápido e simples.Mas não é o único caminho viável; em alguns casos, não é nem uma opção.É por isso que acho esse tipo de provisionamento interessante de documentar.
Ele mostra o que acontece quando você trata o OpenClaw menos como um app descartável e mais como uma peça de infraestrutura que você quer usar.
O provisionamento: Docker Compose, persistência e workspace compartilhado
Estou rodando o OpenClaw em Docker, e a estrutura principal está no Compose abaixo.
version: "3.9"
services:
openclaw:
image: ${OPENCLAW_IMAGE:-ghcr.io/openclaw/openclaw:latest}
container_name: openclaw
environment:
HOME: /home/node
TERM: xterm-256color
# Required (recommended to set)
OPENCLAW_GATEWAY_TOKEN: ${OPENCLAW_GATEWAY_TOKEN}
# Optional
OPENCLAW_ALLOW_INSECURE_PRIVATE_WS: ${OPENCLAW_ALLOW_INSECURE_PRIVATE_WS:-}
CLAUDE_AI_SESSION_KEY: ${CLAUDE_AI_SESSION_KEY:-}
CLAUDE_WEB_SESSION_KEY: ${CLAUDE_WEB_SESSION_KEY:-}
CLAUDE_WEB_COOKIE: ${CLAUDE_WEB_COOKIE:-}
volumes:
- openclaw-data:/home/node
- openclaw-shared:/mnt/shared
# Sandbox isolation (optional) - only enable if you know you want allow OpenClaw to control the local Docker engine
# - /var/run/docker.sock:/var/run/docker.sock
init: true
restart: unless-stopped
command:
[
"node",
"dist/index.js",
"gateway",
"--bind",
"${OPENCLAW_GATEWAY_BIND:-lan}",
"--port",
"18789"
]
# No published ports: access via Cloudflare Tunnel only
networks:
- openclaw_net
healthcheck:
test:
[
"CMD",
"node",
"-e",
"const http=require('http');const req=http.get('http://127.0.0.1:18789/healthz',r=>process.exit(r.statusCode===200?0:1));req.on('error',()=>process.exit(1));"
]
interval: 30s
timeout: 5s
retries: 10
start_period: 60s
cloudflared:
image: cloudflare/cloudflared:latest
container_name: openclaw-cloudflare-tunnel
# Easiest: share the gateway network namespace and point ingress to 127.0.0.1:18789
network_mode: "service:openclaw"
depends_on:
- openclaw
command: tunnel --no-autoupdate run --token ${CLOUDFLARE_TUNNEL_TOKEN} --no-tls-verify
restart: unless-stopped
networks:
openclaw_net:
driver: bridge
internal: false
attachable: false
volumes:
openclaw-data:
external: true
openclaw-shared:
external: true
Existem duas escolhas de design aqui que fazem bastante diferença.
openclaw-data: persistindo o assistente
O volume openclaw-data é o que impede o OpenClaw de virar algo descartável toda vez que o container é recriado.Montado em /home/node, ele preserva o estado de trabalho entre reinicializações e atualizações.
Na prática, isso significa que workspace, notas, memória e configuração continuam existindo mesmo que o contêiner não exista mais.Isso importa porque o OpenClaw não é só um serviço stateless.
Ele funciona muito mais como um ambiente operacional.Se você quiser continuidade, memória e contexto acumulado ao longo do tempo, precisa de armazenamento persistente.
openclaw-shared: uma ponte entre o assistente e os meus arquivos
O volume openclaw-shared cumpre outro papel importante.Eu uso ele como uma área compartilhada entre mim e o OpenClaw.
É ali que ficam os arquivos onde trabalhamos juntos, em vez de tratar o assistente como um sistema fechado.No meu caso, isso funciona bem porque eu uso um NAS.
Portanto o mesmo volume é montado tanto no OpenClaw quanto na minha máquina local, por isso o “compartilhamento”, nesse caso, é literal.O melhor exemplo disso é o Obsidian.
Foi com essa configuração que o OpenClaw deixou de ser apenas um assistente remoto e passou a fazer parte de um ambiente de trabalho compartilhado.Na prática:
eu e o OpenClaw escrevemos e refinamos anotações juntos
organizamos material de pesquisa
mantemos listas de papers
conectamos a memória do assistente com minha base de conhecimento
Esse é um dos motivos pelos quais o home lab funciona tão bem para mim.
O assistente deixa de ser um endpoint e passa a ser parte do ambiente.
Expondo o OpenClaw com segurança
A parte mais simples de todo o setup foi colocar o OpenClaw atrás do Cloudflare Tunnel e do Cloudflare Access.
Isso resolveu praticamente tudo o que queria:
acesso remoto de qualquer lugar
nenhuma porta exposta diretamente na internet
autenticação baseada em identidade
uma postura de segurança muito mais limpa
Ou seja: exposição não foi o problema difícil.
O túnel do Cloudflare resolveu essa questão de forma bastante elegante.
Por que eu gosto desse setup
Não tem nada de particularmente exótico aqui, e isso é excelente.O que gosto é que fica claro quais são as partes que realmente importam:
o runtime do OpenClaw é isolado
o estado é persistente por construção
os dados compartilhados ficam em um volume montado para essa finalidade
não há portas abertas diretamente acessíveis pela Internet
a exposição é feita através de um túnel implementado pelo Cloudflare
o healthcheck acontece dentro do próprio serviço
Isso cria uma base operacional sólida.
Onboarding com openclaw onboard
O OpenClaw usa o comando onboard para fazer a configuração inicial do sistema.Em vez de configurar cada parte manualmente, esse comando centraliza as principais etapas em um só lugar. Em geral, isso inclui:
escolher e configurar um provedor de modelo (via chave de API ou autenticação)
inicializar o workspace e o estado local
configurar o Gateway (endereço de bind, porta e autenticação)
opcionalmente habilitar canais como Telegram e outros
Em um setup local simples, isso normalmente é feito uma única vez pela CLI interativa:
openclaw onboard
O comando pede as informações necessárias e grava a configuração localmente (geralmente em ~/.openclaw/), deixando o ambiente pronto para o runtime subir com tudo configurado.
Por que eu usei o fluxo interativo
Apesar de o OpenClaw suportar um modo não interativo, eu acabei usando o onboarding interativo.O principal motivo foi autenticação.Autenticação via OAuth não pode ser totalmente pré-configurada por variáveis de ambiente da mesma forma que chaves de API, então usar o wizard acaba sendo o caminho viável nesse caso.Eu queria especificamente usar o fluxo de OAuth do ChatGPT porque esse uso é coberto pela minha assinatura do ChatGPT.
Se eu usasse uma API key diretamente, estaria tratando isso como infraestrutura cobrada à parte, o que não era o que gostaria.Esse fluxo é, por definição, interativo. Durante o onboarding, o OpenClaw abre um login no navegador e espera que você copie a URL de callback de volta para a CLI para concluir a autenticação.Esse também é o caminho oficialmente suportado para acesso via assinatura do Codex:
openclaw onboard --auth-choice openai-codex
O processo foi bem direto:
copiar a URL fornecida pelo OpenClaw
abrir no navegador local
concluir o login
copiar a URL de callback de volta para o OpenClaw
Depois disso, a autenticação via OpenAI OAuth funcionou, e o runtime passou a conseguir usar openai-codex/gpt-5.4.
Configuração de canais
Diferentes canais podem ser configurados diretamente durante o onboarding.
No meu caso, escolhi Telegram e Discord.A configuração em si é simples e já está documentada aqui, então não vou repetir o passo a passo. O importante é que a mensageria já entra como parte da configuração inicial, em vez de ser algo adicionado depois.Depois de configurado:
mensagens enviadas via Telegram passam a ser tratadas como entrada do assistente
as respostas retornam pelo mesmo canal
dá para interagir com o sistema sem depender da interface web
Em um setup remoto, isso vira uma forma conveniente de usar o sistema sem precisar abrir uma sessão autenticada completa toda vez.Uma observação rápida sobre o WhatsAppVocê também pode ver referências a integrações com WhatsApp. Diferentemente do Telegram, que oferece uma API de bot estável e bem suportada, o WhatsApp tem regras mais rígidas para automação.Algumas integrações dependem de métodos não oficiais. Nesses casos, contas podem ser sinalizadas ou até banidas por violar os termos de uso da plataforma.Usar a API oficial do WhatsApp Business resolve isso, mas traz mais complexidade e algumas restrições operacionais. Para o meu caso, o Telegram acabou sendo a opção mais simples e confiável.
Problema pós-onboarding: o perfil de ferramentas
Esse foi um dos pontos de atrito do setup.No meu setup, o gateway não estava funcionando apenas como um relay de mensagens na frente de um ambiente de execução mais completo.
Na prática, ele era o próprio runtime operacional.
Não havia um container separado, com o CLI para ficar responsável pela execução das tarefas.Isso significa que a própria instância do gateway precisava:
executar comandos
acessar arquivos
navegar na web
lidar com tarefas de configuração
se comportar como um agente de verdade, e não apenas como uma interface de chat
Por padrão, o perfil de ferramentas ativo se comportava mais como um perfil voltado à mensageria.
Isso provavelmente faz sentido em provisionamentos mais tradicionais, com responsabilidades separadas.
Mas, nesse setup, deixou o sistema incompleto.A solução foi trocar manualmente o perfil de ferramentas para full no arquivo de configuração.
O painel de controle simplesmente não funcionou para essa mudança específica.
A única solução foi editar a configuração diretamente no modo manual.
Depois de recarregar, tudo passou a funcionar como esperado.
Operando o OpenClaw: quando ele começa a ser útil de verdade
Depois que a parte remota estava resolvida, o que mais passou a importar não foi o setup.
Foi o uso no dia a dia.
É aí que o OpenClaw deixa de ser interessante e passa a ser útil.Aqui, a palavra-chave é skill.Skill é um procedimento reutilizável para o agente: basicamente um workflow que pode incluir instruções, convenções, referências e contexto específico, para que o assistente execute tarefas recorrentes com mais consistência.Em outras palavras, em vez de reexplicar o mesmo processo toda vez, você ensina ao sistema como quer que uma determinada classe de tarefas seja executada e deixa esse padrão se manter.
Isso pode ser algo pontual e prático, como regras de formatação ou de escrita, ou algo mais operacional, como a forma de conduzir um fluxo recorrente de pesquisa ou produção de conteúdo.E é isso que transforma o sistema de um assistente genérico em algo moldado ao seu jeito de trabalhar.
As skills que mais tenho utilizado
O que fez o setup realmente funcionar para mim foi a combinação de um workspace persistente com algumas skills bem alinhadas com a forma como eu trabalho.Os mais úteis até agora têm sido aqueles ligados a trabalho de pesquisa, fluxos de escrita e também suporte operacional do dia a dia.
Na prática, isso significa coisas como:
trabalhar com minha base de conhecimento no Obsidian por meio de um diretório compartilhado
escrever e refinar notas ou ideias de posts diretamente no lugar, em vez de ficar copiando conteúdo de um lado para outro
usar skills específicas para fluxos recorrentes, em vez de reexplicar a mesma tarefa toda vez
manter uma memória local leve e o contexto operacional dentro do workspace do OpenClaw
É nesse ponto que o sistema começa a mostrar seu valor.
Em vez de refazer trabalho, ele começa a reutilizar estrutura como base.
Aos poucos, a gente vai moldando o comportamento dele em torno desses workflows recorrentes, fazendo com que essa personalização persista no tempo.
Os cron jobs deram ao sistema uma cara de infraestrutura
Outro ponto que fez bastante diferença foi o uso de cron jobs do OpenClaw.Foi aí que o OpenClaw começou a parecer menos algo que eu “uso quando solicitado”
e mais algo que poderia deixar rodando meus workflows de forma autônoma.
Quando as tarefas são agendadas, o sistema deixa de ser reativo, e passa a ser uma infraestrutura operacional.Isso importa porque boa parte do trabalho útil não é interativo.
Algumas tarefas precisam acontecer no momento certo, outras precisam se repetir, e outras são simplesmente tarefas de manutenção que são fáceis de esquecer quando tudo depende de acionamento manual.No meu caso, isso inclui briefs recorrentes, tarefas de verificação e a curadoria de artigos de pesquisa de alto impacto.
Um bom exemplo é uma tarefa cron que faz o processamento de artigos de alto impacto. Quando um artigo é relevante o suficiente para acionar esse processamento, a automação direciona o fluxo de execução para um script spider.js que expande a rede de citações e retroalimenta os resultados de volta para uma "watchlist" de artigos/autores importantes.
Dessa forma, um único artigo interessante passa a ser uma porta de entrada para uma pesquisa mais ampla sobre autores, laboratórios ou grupos de pesquisa que podem merecer mais atenção ao longo do tempo.
O mais interessante é que não se trata apenas de automação no sentido de executar um script em intervalos definidos. Isso cria continuidade operacional dentro do sistema.
Uma tarefa agendada pode avaliar, verificar, enriquecer e reinserir os resultados em um workflow mais amplo, sem exigir intervenção manual em cada etapa.A combinação de estado persistente, arquivos compartilhados e tarefas agendadas muda a natureza do sistema. Ele começa a se comportar menos como uma demo e mais como um pequeno control plane para workflows pessoais.
Principais aprendizados desse setup
A primeira coisa que eu diria é que a configuração foi mais simples do que parecia, dada a topologia que foi implementada.A arquitetura de um sistema em camadas com host remoto, isolação de container, túnel, camada de identidade e um runtime de agente por trás disso, poderia soar complexo.Na prática, acabou ficando apenas uma composição de componentes bem familiares, onde cada camada tem uma responsabilidade clara, e nenhuma delas se comporta de forma "inusitada".A segunda coisa que eu diria é que a escolha do modelo importa muito mais do que eu esperava.Antes de optar pelo OpenAI via Codex, passei cerca de uma semana testando o Gemini da Google, porque tinha visto bons comentários em relação a custo benefício. Estimei que o custo ficaria em torno de 5 USD por mês para o meu uso. Ledo engano!No fim, acabou me custando €37,94 para o meu uso específico, e sinceramente a qualidade não justificou esse custo.Felizmente, a OpenAI tinha acabado de lançar openai-codex/gpt-5.4, e isso me caiu como uma luva.
Para esse setup, foi claramente uma opção melhor tanto em qualidade quanto em previsibilidade de custo.
Na prática, ele se mostrou mais consistente, deixando a experiência geral muito mais adequada à forma como eu gostaria de usar o OpenClaw.Se alguém me perguntasse hoje o que eu recomendaria, a resposta seria "GPT-5.4 via Codex", sem hesitar.Essa é provavelmente a forma mais honesta de resumir.
Depois que o modelo de provisionamento ficou claro, o OpenClaw em si não foi especialmente difícil de usar e de adaptar.
Aparadas as arestas iniciais, a experiência de uso tem sido genuinamente positiva.É justamente essa experiência positiva que me faz achar que esse projeto merece realmente atenção.
Até mesmo em um setup um pouco fora do comum, ele já foi prático o suficiente para se tornar útil rapidamente.
Considerações finais
A parte interessante desse setup nunca foi entender como provisionar o OpenClaw de maneira remota, deixando-o seguro, utilizável e operacional, quando grande parte do ecossistema ainda assume tacitamente que tudo roda em um único laptop.Esse é mais um motivo pelo qual eu acho que ferramentas como o OpenClaw são importantes.
Elas trazem de volta para a discussão algumas questões reais de engenharia.Agora eu quero ir além com esse setup em algumas direções.Uma área que me interessa particularmente é a arquitetura multiagente. Rodar um único assistente já é bem útil, mas um modelo ainda mais interessante seria um sistema de agentes especializados cooperando entre si, com fronteiras bem definidas entre eles.Na prática, isso significa rodar múltiplos servidores MCP no meu cluster, cada um responsável por uma classe específica de tarefas, em vez de depender de um único runtime genérico.Outra direção é tratar código e skills gerados por IA como artefatos.
Em vez de deixá-los dentro do workspace interno do assistente, quero versioná-los e revisá-los como qualquer outro código.Integrar isso ao meu setup no GitLab permitiria um modelo mais colaborativo: o agente pode gerar e modificar artefatos, mas eu posso intervir, editar, revisar e moldar esses resultados diretamente. O objetivo é não ficar passivamente usando o sistema, mas cooperar ativamente com ele por meio desses artefatos compartilhados e versionados.Essas direções apontam para uma mudança mais ampla: de interagir com um assistente para operar um sistema.Também pretendo dedicar mais tempo a testar o NemoClaw, para entender melhor o que ele busca ser na prática. Essa comparação deve ficar mais interessante à medida que o ecossistema evoluir.Além disso, quero integrar mais controle e monitoramento à minha instância do OpenClaw usando um stack de EDR open-source. Isso provavelmente vai merecer um post próprio quando eu tiver algo mais concreto.E essas questões ficarão cada vez mais relevantes à medida que os agentes deixarem de ser demos e passarem a fazer parte da infraestrutura.E essa transição já está acontecendo.
