Skip to main content
Execute o Gateway do OpenClaw em qualquer servidor Linux ou VPS na nuvem. Esta página ajuda você a escolher um provedor, explica como as implantações na nuvem funcionam e aborda ajustes genéricos do Linux que se aplicam a qualquer ambiente.

Escolha um provedor

Azure

VM Linux

DigitalOcean

VPS pago simples

exe.dev

VM com proxy HTTPS

Fly.io

Máquinas Fly

GCP

Compute Engine

Hetzner

Docker em VPS da Hetzner

Hostinger

VPS com configuração em um clique

Northflank

Configuração pelo navegador em um clique

Oracle Cloud

Camada ARM Sempre Gratuita

Railway

Configuração pelo navegador em um clique

Raspberry Pi

Hospedagem própria em ARM
A AWS (EC2 / Lightsail / camada gratuita) também funciona bem. Um passo a passo em vídeo feito pela comunidade está disponível em x.com/techfrenAJ/status/2014934471095812547 (recurso da comunidade — pode ficar indisponível).

Como funcionam as configurações na nuvem

  • O Gateway é executado no VPS e controla o estado e o espaço de trabalho.
  • Você se conecta pelo laptop ou celular usando a interface de controle ou Tailscale/SSH.
  • Trate o VPS como a fonte da verdade e faça backup regularmente do estado e do espaço de trabalho.
  • Padrão seguro: mantenha o Gateway em local loopback e acesse-o por um túnel SSH ou pelo Tailscale Serve. Se você fizer a associação a lan ou tailnet, o Gateway exigirá um segredo compartilhado (gateway.auth.token ou gateway.auth.password), a menos que a autenticação seja delegada a um proxy confiável.
Páginas relacionadas: acesso remoto ao Gateway, central de plataformas.

Reforce primeiro a segurança do acesso administrativo

Antes de instalar o OpenClaw em um VPS público, decida como você deseja administrar o próprio servidor.
  • Para acesso administrativo somente pela tailnet: primeiro instale o Tailscale, conecte o VPS à sua tailnet, verifique uma segunda sessão SSH pelo IP do Tailscale ou pelo nome do MagicDNS e depois restrinja o SSH público.
  • Sem o Tailscale: aplique o reforço de segurança equivalente ao seu caminho SSH antes de expor mais serviços.
  • Isso é separado do acesso ao Gateway. Você ainda pode manter o OpenClaw associado ao local loopback e usar um túnel SSH ou o Tailscale Serve para o painel.
As opções do Gateway específicas do Tailscale estão em Tailscale.

Agente compartilhado da empresa em um 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 somente para fins profissionais.
  • Mantenha-o em um ambiente de execução dedicado (VPS/VM/contêiner + usuário/contas dedicados do sistema operacional).
  • Não conecte esse ambiente de execução a contas pessoais da Apple/Google nem a perfis pessoais de navegador/gerenciador de senhas.
  • Se os usuários forem hostis entre si, separe-os por Gateway/host/usuário do sistema operacional.
Detalhes do modelo de segurança: Segurança.

Uso de nós com um VPS

Você pode manter o Gateway na nuvem e parear nós nos seus dispositivos locais (Mac/iOS/Android/sem interface gráfica). Os nós fornecem recursos locais de tela/câmera/canvas e system.run, enquanto o Gateway permanece na nuvem. Documentação: Nós, CLI de nós.

Ajustes de inicialização para VMs pequenas e hosts ARM

Se os comandos da CLI parecerem lentos em VMs de baixo consumo de energia (ou hosts ARM), ative o cache de compilação de módulos do Node:
  • NODE_COMPILE_CACHE melhora o tempo de inicialização de comandos repetidos; a primeira execução aquece o cache.
  • OPENCLAW_NO_RESPAWN=1 mantém as reinicializações rotineiras do Gateway dentro do processo, o que evita transferências adicionais entre processos e simplifica o rastreamento de PID em hosts pequenos.
  • Para detalhes específicos do Raspberry Pi, consulte Raspberry Pi.

Lista de verificação de ajustes do systemd (opcional)

Para hosts de VM que usam systemd, considere:
  • Variáveis de ambiente do serviço para um caminho de inicialização estável: OPENCLAW_NO_RESPAWN=1 e NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
  • Comportamento explícito de reinicialização: Restart=always, RestartSec=2, TimeoutStartSec=90
  • Discos SSD para os caminhos de estado/cache, a fim de reduzir as penalidades de inicialização a frio causadas por E/S aleatória.
O caminho padrão openclaw onboard --install-daemon instala uma unidade de usuário do systemd; edite-a com:
Se você instalou deliberadamente uma unidade do sistema, edite-a por meio de 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 saber mais sobre o comportamento de OOM no Linux, a seleção do processo filho a ser encerrado e o diagnóstico de exit 137, consulte pressão de memória e encerramentos por OOM no Linux.

Relacionados