Minha configuração OpenClaw: uma máquina só que cria sites

O site que você está lendo agora é mantido por agentes de IA rodando em uma pequena máquina Linux na minha casa — e todo o arranjo foi construído para que eles possam fazer trabalho de verdade sem nunca conseguir destruir nada.

Antes de mais nada, a parte que se autodemonstra: este artigo é atualizado uma vez por semana pela própria configuração que ele descreve. Uma tarefa agendada acorda um agente OpenClaw, que relê esta página, corrige o que estiver desatualizado, roda as verificações de segurança e carimba o resultado. A data de “Atualizado” no topo desta página é escrita por essa tarefa semanal — ninguém a digita. Se essa data for recente, o pipeline destes diagramas rodou, do início ao fim, nos últimos sete dias.

A máquina inteira, em resumo

Tudo mora em uma única máquina. Os modelos fornecem tokens — hoje em dia principalmente a API de nuvem barata do DeepSeek, com modelos locais como reserva —, o gateway OpenClaw os transforma em agentes com ferramentas, os agentes editam conteúdo em texto puro, um gerador determinístico constrói o site, e um único script controlado é o único caminho até o servidor.

O que você obtém

O estado final, antes de qualquer papo sobre configuração:

• “Rascunha um post sobre X” no chat → um agente escreve um artigo em Markdown na pasta content/ do site, seguindo o esquema de frontmatter e o estilo da casa, e reconstrói a prévia local.
• “Publica isso” → o agente roda o script de deploy, que por padrão é um dry run: mostra exatamente quais arquivos mudariam no servidor e não toca em nada. Publicar de verdade exige um --go explícito meu, e mesmo assim o script faz um backup do lado do servidor primeiro e nunca apaga nada.
• Uma vez por semana, uma tarefa agendada acorda um agente para atualizar o site — corrigir datas desatualizadas, melhorar posts fracos, checar links — com verificações de segurança antes que qualquer coisa possa ser publicada (o Passo 3 tem os detalhes).
• O próprio laserlloyd.com é gerenciado assim.

A divisão de trabalho é o ponto principal: os agentes digitam, os scripts impõem as regras, e eu tomo a única decisão que importa — se uma mudança vai ao ar ou não.

Hardware e sistema operacional: qualquer máquina Linux serve

Eu uso um mini-PC com bastante memória unificada porque gosto de rodar modelos grandes localmente (a stack completa está no artigo irmão, Oito agentes de IA, uma máquina AMD). Mas para gestão de sites especificamente, os requisitos são modestos:

• Qualquer máquina Linux de 64 bits — um mini-PC, um desktop antigo, até um notebook razoável. 16GB de RAM rodam bem modelos locais pequenos; 32GB ou mais abrem espaço para modelos de porte médio que escrevem uma prosa visivelmente melhor.
• Uma distro com systemd (praticamente todas) — o agendamento e a supervisão de serviços abaixo partem desse pressuposto.
• Python 3 para o gerador de site estático, rsync + SSH para os deploys.

Você nem precisa, a rigor, de uma GPU. Modelos pequenos ajustados para instrução rodam de forma aceitável em CPU para rascunhar e editar texto. Mas vou ser honesto sobre onde cheguei depois de meses rodando os dois: a API de nuvem do DeepSeek é hoje o motor principal de toda a minha configuração OpenClaw. Os modelos locais abertos eram o plano original, e ainda rodam, mas as concessões se acumulam — minutos de carregamento do modelo, malabarismo de VRAM entre serviços, e uma inteligência visivelmente menor do que um modelo de nuvem barato e de ponta que custa frações de centavo por mensagem. O local é minha reserva e minha camada de privacidade, não meu motorista do dia a dia. (A conta mensal real: cerca de US$ 24.)

Passo 1: instale um gateway de agentes e um modelo local

Duas peças: algo que sirva um modelo por uma API compatível com OpenAI, e algo que transforme esse modelo em um agente — com ferramentas, acesso a arquivos e tarefas agendadas.

Servidor de modelo. LM Studio, Ollama ou o servidor do llama.cpp — qualquer um funciona. Seja qual for sua escolha, rode-o como um serviço de usuário do systemd para que sobreviva a reinicializações:

# ~/.config/systemd/user/model-server.service
[Unit]
Description=Local LLM server
[Service]
ExecStart=/path/to/your/model-server --port 1234
Restart=on-failure
[Install]
WantedBy=default.target

systemctl --user enable --now model-server
curl -s http://localhost:1234/v1/models   # checagem rápida

Gateway de agentes. Eu uso o OpenClaw, um gateway aberto e auto-hospedado que hospeda agentes nomeados, dá a eles ferramentas (shell, leitura/escrita de arquivos, busca na web), roteia cada agente para um modelo (local ou de nuvem, com fallbacks) e expõe uma interface de chat. Instale-o, aponte um agente “webmaster” para seu modelo local e conceda a ele acesso a ferramentas restrito ao diretório do site. Duas regras de configuração que importam independentemente do gateway escolhido:

• Vincule o gateway ao loopback e coloque qualquer interface de chat atrás de autenticação. Um agente com acesso a shell não é algo para deixar aberto na sua rede.
• Restrinja o diretório de trabalho do agente ao repositório do site. Ele precisa editar content/, não o seu diretório pessoal.

Duas camadas: agentes locais para a rotina, um modelo de nuvem forte para consertos

Uma máquina, duas camadas de poder cognitivo. Os agentes OpenClaw — usando a API barata do DeepSeek, com modelos locais atrás deles — cuidam do trabalho corriqueiro e de alto volume: rascunhar, editar, checar links, a atualização semanal. Mas quando o sistema em si quebra (uma regressão de configuração, um gateway travado, um build que não roda), eu escalono para um modelo de codificação de nuvem forte que trata a máquina inteira como seu paciente. Contei essa história em separado em Quando o OpenClaw quebra, eu conserto com o Claude Code: os agentes OpenClaw são a mão de obra, o modelo de codificação forte é o mecânico.

A equipe: cada bot da máquina

O gateway hospeda um elenco de agentes nomeados, cada um roteado para o modelo que combina com sua função. Todos aparecem no DisPatch, o app de chat que a família usa — mas nem todos nos dois modos: o bloqueio por PIN do DisPatch divide o elenco em um conjunto seguro, sempre disponível, e um conjunto de força total que só aparece depois do desbloqueio.

Bot	Trabalho	Roda em	DisPatch (bloqueado)	DisPatch (desbloqueado)
Bits	Recepção — o agente com quem você fala; entende o pedido, despacha o especialista certo	DeepSeek flash (nuvem)	—	✔
Brains	O pensador pesado — specs, auditorias, qualquer coisa que valha a pena esperar	DeepSeek reasoner (nuvem)	—	✔
Flash	Tarefas rápidas e acompanhamentos agendados — o vigia que cobra trabalho atrasado	DeepSeek flash (nuvem)	—	✔
Hermes	A ponte para o agente de codificação — trabalho de programação despachado	DeepSeek (nuvem)	—	✔
Doxy	Cavalo de batalha local — trabalho pesado e privado que não deve sair de casa	Modelo local de 122B (vLLM)	—	✔
Charley	Visão — "o que tem nesta foto?", tarefas que envolvem imagem	Gemma 31B (local, LM Studio)	✔	✔
Alpha e Beta	Ajudantes gerais seguros para a família — dúvidas de lição de casa, papo do dia a dia	DeepSeek flash (nuvem)	✔	✔
Terminex	Não é um agente — o terminal de codificação Reasonix do DisPatch, um PTY de verdade no navegador	DeepSeek (nuvem)	—	✔

Como eles se saem, com sinceridade:

• Os bots baseados em DeepSeek são os motoristas do dia a dia. Os agentes de nível flash (Bits, Flash, Alpha, Beta) respondem em segundos, custam frações de centavo por mensagem e nunca precisam de aquecimento. O Brains, no nível reasoner, demora visivelmente mais por resposta — e é essa a ideia, é para ele que você manda os problemas que valem a pena pensar — e mesmo assim custa centavos por sessão. A conta medida da stack inteira está no artigo sobre custos.
• Os bots locais são mais lentos e menos espertos, mas privados e gratuitos. O modelo de 122B do Doxy leva minutos para carregar na memória e suas interações longas podem levar vários minutos a mais; os timeouts do gateway tiveram que ser aumentados especificamente por causa dele. O modelo de visão do Charley é a exceção que se mantém ocupada — descrição de imagem é algo que nenhum nível de nuvem barato faz aqui, então um modelo local justifica sua VRAM.
• O conjunto seguro é deliberadamente sem graça. Alpha, Beta e Charley são o elenco do modo bloqueado: informação geral e visão, sem ferramentas que toquem em arquivos ou sistemas. É isso que torna entregar um celular para uma criança um não evento.

Passo 2: um site estático mais um script de deploy controlado

Agentes e WordPress combinam mal — banco de dados, login, plugins e PHP são todos superfície de ataque e todos modos de falha. Um gerador de site estático é o parceiro natural para um agente: o site inteiro é composto de arquivos de texto puro em uma pasta, o build é um único comando, e “publicar” é uma cópia de arquivos. Meu gerador tem algumas centenas de linhas de Python (Jinja2 + Markdown + YAML); Hugo, Eleventy ou Zola funcionam do mesmo jeito. O que importa é o contrato:

• O conteúdo são arquivos Markdown com frontmatter. Um LLM edita isso nativamente, e um git diff mostra exatamente o que ele fez.
• O build é determinístico. Mesmo conteúdo na entrada, site idêntico byte a byte na saída — então qualquer mudança na saída é rastreável até uma mudança no conteúdo.
• Existe exatamente um caminho de deploy, e é um script com a segurança embutida, não um conjunto de instruções que se confia que o agente vai seguir.

Esse último ponto é o coração de toda essa configuração. Eis o formato do meu:

./deploy.sh preflight   # checa SSH, webroot de destino, orçamento de tamanho
./deploy.sh             # build + rsync em DRY-RUN — mostra o que mudaria
./deploy.sh --go        # build + backup do lado do servidor + publica + verifica

E o que o script garante, em ordem de importância:

1. Dry-run por padrão. Rodá-lo sem argumentos nunca pode modificar o servidor. Um agente pode rodá-lo livremente para mostrar a mim um deploy pendente.
2. Nunca apaga. O rsync roda sem --delete. Um agente confuso pode sobrescrever uma página com uma versão mais nova; não pode apagar o site.
3. Faz backup primeiro. Com --go, o script cria um tarball do lado do servidor com o webroot antes que qualquer arquivo seja sobrescrito (mantendo os últimos backups). Se o backup falhar, o deploy é abortado.
4. Fail-closed (falha travando o processo). Um manifesto ausente, um host inalcançável ou um valor de configuração de placeholder abortam antes que o rsync rode. Arquivos-fonte (templates, scripts, configurações) são excluídos de forma rígida, para que nunca cheguem ao webroot público.
5. Verifica depois. Ele busca a homepage ao vivo e procura por um marcador do gerador que o build embute — um simples HTTP 200 pode ser um falso positivo se a hospedagem antiga ainda responder pelo domínio.

O agente tem permissão para rodar o dry run e o preflight sempre que quiser. A flag --go é reservada para mim. Essa única assimetria transforma “uma IA tem acesso quase-SSH ao meu site de produção” de algo aterrorizante em algo entediante.

Passo 3: atualizações semanais agendadas, com guardrails

A última peça torna tudo autossustentável. Um timer do systemd dispara uma vez por semana e entrega ao agente um briefing permanente: revisar o site, atualizar o que estiver desatualizado, apertar posts fracos, verificar links internos, e deixar o resultado em stage — não publicado. Essa mesma tarefa é o que mantém este artigo: parte do briefing é “reler o post da configuração OpenClaw, corrigir o que tiver se distanciado da realidade e carimbar a data em updated:.” A data no topo desta página é esse carimbo.

# ~/.config/systemd/user/site-refresh.timer
[Unit]
Description=Weekly website content refresh
[Timer]
OnCalendar=Sun 06:00
Persistent=true
[Install]
WantedBy=timers.target

O serviço que ele dispara chama a API (ou CLI) do gateway com o briefing, e depois roda as verificações de segurança sobre o que o agente deixou em stage:

• Varredura de segredos. Uma varredura de padrões sobre o diff atrás de qualquer coisa com cara de chave de API, token, senha ou hostname privado. Ferramentas como o gitleaks fazem isso prontas para uso. Qualquer ocorrência aborta a execução — fail-closed, sem exceções.
• Checagem de conteúdo profissional. Uma segunda passada de LLM, com um prompt diferente do escritor, revisa as mudanças em stage contra uma única pergunta: “uma empresa se sentiria confortável publicando isso?” Tom, afirmações, TODOs inacabados, texto de placeholder. Uma reprovação deixa as mudanças em stage para revisão humana em vez de fazer o deploy.
• O build precisa passar, incluindo o checador de links/assets — uma imagem quebrada ou um link interno morto derruba a execução antes mesmo de chegar ao script de deploy.

Só quando os três passam é que a tarefa sequer chega a fazer o dry-run de um deploy — e neste site, a publicação de verdade continua esperando o meu --go. Se um dia eu confiar o suficiente no pipeline para deixar a tarefa semanal publicar de forma autônoma, os guardrails somados ao script de deploy que nunca apaga e sempre faz backup antes limitam o raio de estrago a “um artigo ruim foi ao ar e eu restaurei do backup.”

Replicando isso

Tudo acima pode ser construído a partir desta descrição — não há nada proprietário nisso. A receita, condensada:

1. Escolha uma máquina Linux e instale um servidor de modelo local (LM Studio, Ollama, llama.cpp) como um serviço systemd.
2. Instale um gateway de agentes (OpenClaw ou similar) vinculado ao loopback; crie um agente webmaster com ferramentas de arquivo/shell restritas ao diretório do site.
3. Mova o site para um gerador estático, se ainda não estiver — conteúdo Markdown na entrada, um comando de build na saída.
4. Escreva o script de deploy controlado com as cinco garantias acima: dry-run por padrão, sem exclusões, backup antes, fail-closed, verificação pós-deploy. Essa é a peça que merece mais cuidado; são talvez 150 linhas de bash.
5. Adicione o timer semanal e as duas verificações de segurança (varredura de segredos + revisão de conteúdo por LLM), fail-closed.
6. Mantenha o --go humano até que o pipeline conquiste o contrário.

Seguindo a convenção deste site, o quadro “implemente você mesmo” no topo do artigo significa exatamente o que diz: este texto é deliberadamente detalhado o bastante para você entregar o artigo inteiro ao seu próprio LLM e pedir para ele construir cada peça para o seu site. A lista de garantias do script de deploy é, na prática, sua especificação.

Pegadinhas

• O script de deploy precisa ser o único caminho. Na primeira vez que você (ou um agente) monta um rsync manual “só dessa vez”, você criou o incidente que o script existia para evitar. O meu exclui arquivos-fonte de forma rígida e recusa configurações de placeholder justamente porque um comando avulso não faria isso.
• Um simples HTTP 200 não é um deploy bem-sucedido. Durante minha migração do WordPress, a hospedagem antiga continuou respondendo pelo domínio — toda “verificação” passava enquanto os arquivos novos ficavam parados, sem uso. Embuta um marcador do gerador no seu build e faça um grep dele na página ao vivo.
• Agentes seguem o esquema que você mostra a eles, TODOs inclusive. Se o esqueleto do seu post tem texto de placeholder, um modelo preguiçoso vai publicar TODO: excerpt here ao pé da letra. Essa é metade do motivo pelo qual a checagem de conteúdo profissional existe.
• Não deixe o escritor se autorrevisar. Mesmo modelo, mesmo prompt, mesmos pontos cegos. O revisor precisa, no mínimo, de um prompt diferente — idealmente, de um modelo diferente.
• Tarefas de LLM agendadas precisam de timeouts e de um padrão “em stage, não publicado”. Uma tarefa semanal que pode publicar sem supervisão vai, mais cedo ou mais tarde, publicar algo estranho às 6h de um domingo. Deixar em stage não custa nada além de uma revisão.
• Varreduras de segredos pertencem ao pipeline, não às instruções do agente. “Nunca inclua segredos” em um prompt é um desejo; uma varredura fail-closed sobre o diff é um controle.