Pular para o conteúdo principal

Servidor Linux

Execute o Gateway do OpenClaw em qualquer servidor Linux ou VPS em nuvem. Esta página ajuda você a escolher um provedor, explica como as implantações em nuvem funcionam e cobre o ajuste fino genérico de Linux que se aplica em qualquer lugar.

Escolha um provedor

Railway

Configuração em um clique, no navegador

Northflank

Configuração em um clique, no navegador

DigitalOcean

VPS pago simples

Oracle Cloud

Camada ARM Always Free

Fly.io

Fly Machines

Hetzner

Docker em VPS da Hetzner

Hostinger

VPS com configuração em um clique

GCP

Compute Engine

Azure

VM Linux

exe.dev

VM com proxy HTTPS

Raspberry Pi

ARM self-hosted
AWS (EC2 / Lightsail / camada gratuita) também funciona muito bem. Um vídeo explicativo da comunidade está disponível em x.com/techfrenAJ/status/2014934471095812547 (recurso da comunidade — pode ficar indisponível).

Como as configurações em nuvem funcionam

  • O Gateway é executado na VPS e mantém o estado + workspace.
  • Você se conecta do seu laptop ou telefone pela Control UI ou por 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 loopback e acesse-o por túnel SSH ou Tailscale Serve. Se você vinculá-lo a lan ou tailnet, exija gateway.auth.token ou gateway.auth.password.
Páginas relacionadas: Acesso remoto ao Gateway, Central de plataformas.

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 é usado 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 nem a perfis pessoais de navegador/gerenciador de senhas.
  • Se os usuários forem adversariais entre si, separe por gateway/host/usuário de SO.
Detalhes do modelo de segurança: Segurança.

Usando nodes com uma VPS

Você pode manter o Gateway na nuvem e parear nodes nos seus dispositivos locais (Mac/iOS/Android/headless). Nodes fornecem recursos locais de tela/câmera/canvas e system.run enquanto o Gateway permanece na nuvem. Documentação: Nodes, CLI de Nodes.

Ajuste fino de inicialização para VMs pequenas e hosts ARM

Se os 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:
grep -q 'NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache' ~/.bashrc || cat >> ~/.bashrc <<'EOF'
export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
mkdir -p /var/tmp/openclaw-compile-cache
export OPENCLAW_NO_RESPAWN=1
EOF
source ~/.bashrc
  • NODE_COMPILE_CACHE melhora os tempos de inicialização de comandos repetidos.
  • OPENCLAW_NO_RESPAWN=1 evita sobrecarga extra na inicialização causada por um caminho de auto-reinicialização.
  • A primeira execução de comando aquece o cache; as execuções seguintes ficam mais rápidas.
  • Para detalhes específicos do Raspberry Pi, consulte Raspberry Pi.

Checklist de ajuste fino do systemd (opcional)

Para hosts de VM que usam systemd, considere:
  • Adicionar variáveis de ambiente ao serviço para um caminho de inicialização estável:
    • OPENCLAW_NO_RESPAWN=1
    • NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
  • Manter o comportamento de reinício explícito:
    • Restart=always
    • RestartSec=2
    • TimeoutStartSec=90
  • Prefira discos com SSD para caminhos de estado/cache para reduzir penalidades de cold start por E/S aleatória.
Para o caminho padrão openclaw onboard --install-daemon, edite a unit de usuário:
systemctl --user edit openclaw-gateway.service
[Service]
Environment=OPENCLAW_NO_RESPAWN=1
Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
Restart=always
RestartSec=2
TimeoutStartSec=90
Se você instalou deliberadamente uma unit de sistema, edite openclaw-gateway.service com sudo systemctl edit openclaw-gateway.service. Como as políticas Restart= ajudam na recuperação automatizada: systemd pode automatizar a recuperação de serviços.