Escolha um provedor
Railway
Configuração em um clique, pelo navegador
Northflank
Configuração em um clique, pelo navegador
DigitalOcean
VPS paga simples
Oracle Cloud
Camada ARM Always Free
Fly.io
Fly Machines
Hetzner
Docker em VPS Hetzner
Hostinger
VPS com configuração em um clique
GCP
Compute Engine
Azure
VM Linux
exe.dev
VM com proxy HTTPS
Raspberry Pi
ARM auto-hospedado
Como as configurações em nuvem funcionam
- O Gateway é executado na VPS e gerencia o estado + workspace.
- Você se conecta pelo notebook ou celular via Control UI ou Tailscale/SSH.
- Trate a VPS como a fonte da verdade e faça backup do estado + workspace regularmente.
- Padrão seguro: mantenha o Gateway em local loopback e acesse-o por túnel SSH ou Tailscale Serve.
Se você fizer bind para
lanoutailnet, exijagateway.auth.tokenougateway.auth.password.
Proteja o acesso administrativo primeiro
Antes de instalar o OpenClaw em uma VPS pública, decida como você quer administrar a própria máquina.- Se você quer acesso administrativo somente pela Tailnet, instale o Tailscale primeiro, conecte a VPS à sua tailnet, verifique uma segunda sessão SSH pelo IP do Tailscale ou nome MagicDNS e então restrinja o SSH público.
- Se você não está usando Tailscale, aplique o endurecimento equivalente ao seu caminho SSH antes de expor mais serviços.
- Isso é separado do acesso ao Gateway. Você ainda pode manter o OpenClaw vinculado ao local loopback e usar um túnel SSH ou Tailscale Serve para o painel.
Agente compartilhado da empresa em uma VPS
Executar um único agente para uma equipe é uma configuração válida quando todos os usuários estão no mesmo limite de confiança e o agente é apenas para negócios.- Mantenha-o em um runtime dedicado (VPS/VM/contêiner + usuário/contas de SO dedicados).
- Não conecte esse runtime a contas pessoais Apple/Google ou perfis pessoais de navegador/gerenciador de senhas.
- Se os usuários forem adversários entre si, separe por gateway/host/usuário de SO.
Usar nodes com uma VPS
Você pode manter o Gateway na nuvem e parear nodes nos seus dispositivos locais (Mac/iOS/Android/headless). Nodes fornecem tela/câmera/canvas locais e capacidadessystem.run
enquanto o Gateway permanece na nuvem.
Docs: Nodes, CLI de Nodes.
Ajuste de inicialização para VMs pequenas e hosts ARM
Se comandos da CLI parecerem lentos em VMs de baixa potência (ou hosts ARM), habilite o cache de compilação de módulos do Node:NODE_COMPILE_CACHEmelhora os tempos de inicialização de comandos repetidos.OPENCLAW_NO_RESPAWN=1mantém reinicializações rotineiras do Gateway dentro do processo, o que evita transferências extras entre processos e mantém o rastreamento de PID simples em hosts pequenos.- A primeira execução do comando aquece o cache; as execuções seguintes são mais rápidas.
- Para detalhes específicos do Raspberry Pi, consulte Raspberry Pi.
Lista de verificação de ajustes do systemd (opcional)
Para hosts de VM usandosystemd, considere:
- Adicionar variáveis de ambiente de serviço para um caminho de inicialização estável:
OPENCLAW_NO_RESPAWN=1NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
- Manter o comportamento de reinicialização explícito:
Restart=alwaysRestartSec=2TimeoutStartSec=90
- Prefira discos com SSD para caminhos de estado/cache para reduzir penalidades de inicialização a frio por E/S aleatória.
openclaw onboard --install-daemon, edite a unidade de usuário:
openclaw-gateway.service via sudo systemctl edit openclaw-gateway.service.
Como as políticas Restart= ajudam na recuperação automatizada:
o systemd pode automatizar a recuperação de serviços.
Para comportamento de OOM no Linux, seleção de vítima de processo filho e diagnósticos de exit 137,
consulte pressão de memória no Linux e encerramentos por OOM.