OpenClaw 24/7 em um VPS: instalação segura

No notebook, o OpenClaw fica mudo assim que a tampa fecha: as mensagens do WhatsApp se acumulam e as tarefas agendadas esperam você voltar. Em um servidor, ele continua respondendo. O problema é que o gateway não é um widget de chat. Ele guarda as credenciais dos seus canais e, a menos que você ative uma sandbox, executa ferramentas direto no host. Mudá-lo para uma máquina sempre ligada só vale a pena se o modelo de segurança mudar junto.

Este guia faz isso em uns 20 minutos em um VPS Ubuntu 24.04 recém-criado.

Última verificação em 2026-10-04 com OpenClaw 2026.9.8 (npm), Node 24.21 LTS e Ubuntu 24.04.

O que você precisa

• Um VPS Linux. Usamos o nosso plano AI-Agent: 4 vCPU, 4 GB de RAM, 40 GB de disco, US$ 10 por mês. A documentação do OpenClaw fala em 6 GB de RAM, mas isso é para compilar a imagem Docker deles a partir do código-fonte; o pacote npm não precisa de build.
• Uma chave de API do seu provedor de modelos e as contas de mensagem que você quer conectar.
• Uma chave SSH no notebook. Se ainda não tem: login com chave SSH.

Um plano com NAT serve bem aqui, e talvez até combine mais. O gateway nunca precisa de uma porta de entrada aberta: WhatsApp, Discord e Telegram (long polling por padrão) se conectam para fora, e você chega ao painel por SSH. Contrate IPv4 dedicado só se algum canal que você precisa entrega por webhook ou se pretende colocar um proxy reverso público na frente.

1. Um usuário que não seja root

O OpenClaw executa as ferramentas como o usuário dono do gateway. Se esse usuário for root, também será root cada comando que um modelo confuso ou manipulado por prompt injection decidir rodar. A documentação do OpenClaw chama rodar o gateway como root de inseguro e não suportado. Crie um usuário dedicado, sem sudo:

# como root
apt update && apt -y upgrade
adduser --disabled-password --gecos "" claw
install -d -m 700 -o claw -g claw /home/claw/.ssh
install -m 600 -o claw -g claw ~/.ssh/authorized_keys /home/claw/.ssh/authorized_keys   # a chave adicionada no pedido
loginctl enable-linger claw

A última linha importa mais do que parece. O OpenClaw instala um serviço systemd de usuário, e sem lingering esse serviço para quando você sai. É o «ontem funcionava» mais comum em servidor.

2. Node 24 e OpenClaw

O OpenClaw 2026.9.8 exige Node >=24.16.0 <25 ou >=26.1.0. O pacote nodejs do Ubuntu é mais antigo, então pegamos a 24 LTS da NodeSource:

# como root
curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs
node -v          # v24.16.0 ou mais recente
npm install -g openclaw@latest
openclaw --version

O comando oficial de uma linha (curl -fsSL https://openclaw.ai/install.sh | bash) também funciona e instala o Node para você. Em servidor preferimos os dois passos explícitos: dá para ver o que vai para onde, e o binário fica em /usr/bin em vez de numa pasta pessoal onde o agente pode escrever.

3. Onboarding como o usuário do agente

Entre como claw por SSH, não com su. Só um login de verdade inicia o gerenciador de usuário do systemd de que o serviço precisa:

# do notebook (plano NAT: acrescente -p <sua porta SSH>)
ssh claw@<server>

openclaw onboard --install-daemon
openclaw gateway status

O assistente verifica o acesso ao modelo, grava ~/.openclaw/openclaw.json, gera um token do gateway e instala o serviço. Se o systemctl --user reclamar do barramento, rode export XDG_RUNTIME_DIR=/run/user/$(id -u) e tente de novo.

Depois, feche os arquivos. A recomendação do próprio OpenClaw é 700 no diretório de estado e 600 na configuração:

chmod 700 ~/.openclaw && chmod 600 ~/.openclaw/openclaw.json
openclaw security audit --deep

openclaw security audit --fix aplica a parte segura das correções: permissões mais restritas e listas de permissão no lugar de políticas de grupo abertas. Ele não muda onde o gateway escuta nem configura firewall; a exposição de rede continua sendo tarefa sua.

4. Mantenha o gateway em loopback

O gateway serve sua API WebSocket e o painel em uma única porta, 18789, ligada a 127.0.0.1 por padrão. Deixe assim. Uma configuração mínima que deixa isso por escrito:

// ~/.openclaw/openclaw.json
{
  gateway: {
    mode: "local",
    bind: "loopback",
    port: 18789,
    auth: { mode: "token", token: "paste-output-of-openssl-rand-hex-32" },
  },
}

Gere o token com openssl rand -hex 32 ou openclaw doctor --generate-gateway-token. O gateway recusa tokens vazios e os valores de exemplo, e a auditoria avisa abaixo de 24 caracteres.

O que não fazer: colocar bind em "lan" e abrir a porta. A documentação é direta: nunca exponha o gateway sem autenticação em 0.0.0.0 e não redirecione a porta de forma ampla nem com token. Quem conseguir esse token vira operador de um processo que executa comandos no seu servidor.

No firewall, libere SSH e mais nada:

# como root
ufw allow OpenSSH
ufw enable
ufw status verbose

Nos nossos planos NAT o painel mostra uma porta SSH externa, mas dentro do servidor o sshd continua escutando na 22. Libere OpenSSH (porta 22), não o número da porta externa, senão o ufw enable tranca você do lado de fora. Mais no guia de UFW.

5. Acesse o painel por SSH

Do notebook, abra um túnel e deixe aberto:

ssh -N -L 18789:127.0.0.1:18789 claw@<server>
# plano NAT: ssh -N -p <sua porta SSH> -L 18789:127.0.0.1:18789 claw@<host>

Abra http://127.0.0.1:18789/ e cole o token do gateway. O sshd padrão do Ubuntu permite encaminhamento local; se você endureceu a configuração, AllowTcpForwarding local é o ajuste que libera -L e bloqueia encaminhamentos remotos. Se o túnel falhar com administratively prohibited, confira essa linha.

Uma tailnet também resolve: o Tailscale Serve mantém o gateway em loopback e cuida do acesso. As duas opções servem. Porta pública, não.

6. Pareamento, sandbox e quem pode falar com ele

Os canais de chat são a outra porta de entrada. Por padrão, canais com mensagens diretas exigem que remetentes desconhecidos se pareiem primeiro; você aprova pelo servidor:

openclaw pairing approve <channel> <code>

Em grupos, exija menção para o agente não responder a cada mensagem da sala. A configuração endurecida do OpenClaw usa dmPolicy: "pairing" e groups: { "*": { requireMention: true } } por canal.

Duas ressalvas honestas. Primeira: o pareamento controla quem pode iniciar uma rodada, não o que entra no contexto do modelo; uma mensagem encaminhada ou uma página baixada ainda pode direcionar uma rodada que você iniciou. Segunda: as ferramentas da sessão principal rodam no host até você ativar a sandbox (agents.defaults.sandbox.mode: "non-main" isola tudo menos a sua própria sessão principal). A sandbox vem desligada e o backend padrão é o Docker, então instale o Docker antes de ativá-la: Docker em um VPS. Se pessoas em quem você não confia dividem um canal com o bot, use um gateway separado, de preferência em outro servidor.

7. Atualizações e backups

openclaw update
openclaw gateway status
openclaw backup create --output ~/backups/openclaw --verify

~/.openclaw guarda a configuração, as credenciais dos canais (inclusive a sessão do WhatsApp), os perfis de autenticação dos modelos e as transcrições das sessões. Perder isso significa parear tudo de novo; vazar significa outra pessoa sendo você no WhatsApp. Faça backup e guarde a cópia fora do servidor: baixe com scp ou use o restic com criptografia.

Checklist

Onde a EQVPS entra

Muitos provedores rodam um processo Node. O que acrescentamos é pagamento em cripto sem KYC, um plano NAT que combina com um gateway só em loopback e um servidor MCP que o seu agente pode usar para gerenciar os próprios servidores. Se você conectar o OpenClaw a ele, leia antes as proteções MCP: um token que pode pedir servidores merece o mesmo cuidado que o token do gateway. Para uma visão mais ampla de agentes em VPS, veja o guia de agentes de IA.

Nossa opinião: esses 20 minutos são a diferença entre um assistente e um shell aberto com interface de chat. Faça pelo menos os passos 1, 4 e 5, mesmo que pule o resto.