VPS para bot de trading: o que realmente importa

O que um bot de trading precisa de um VPS

Um VPS para bots de trading é avaliado por quatro fatores: o processo volta a funcionar depois de ser encerrado, o relógio está correto, as chaves de API (application programming interface) são difíceis de roubar e você fica sabendo quando o processo para. A velocidade bruta fica bem abaixo desses fatores para um bot de varejo, porque a parte mais lenta do caminho da ordem é o seu broker e a distância até ele, não o host que executa seu Python.

Este é um guia de engenharia. Nada aqui constitui aconselhamento financeiro, e nenhuma estratégia é discutida.

Uptime é disciplina de reinicialização, não um número em uma página de vendas

Todo host no mundo anuncia 99.9 por cento de uptime. Esse número descreve o hypervisor, não o seu bot. Um bot para por causa de uma exceção não tratada, de um websocket que nunca se reconecta ou do OOM (out of memory) killer, enquanto o servidor permanece ativo durante todo o tempo. Portanto, a pergunta útil é o que acontece nos dez segundos depois que o processo termina.

Execute o bot como um serviço systemd e deixe o sistema init controlar a reinicialização. Um arquivo de unidade faz isso em seis linhas.

[Unit]
Description=Trading bot
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
User=bot
WorkingDirectory=/opt/tradingbot
EnvironmentFile=/etc/tradingbot/api.env
ExecStart=/opt/tradingbot/venv/bin/python -m tradingbot
Restart=always
RestartSec=10
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/tradingbot

[Install]
WantedBy=multi-user.target

StartLimitIntervalSec=0 é a linha que as pessoas ignoram. Por padrão, o systemd desiste depois de 5 reinicializações em 10 segundos e deixa a unidade no estado failed para sempre. Esse é exatamente o comportamento que você não quer às 03:00. Defini-lo como 0 desativa o limite de taxa. Assim, um bot que entra em um loop de falhas continua tentando, em vez de ficar silencioso. RestartSec=10 impede que esse loop sobrecarregue a exchange com reconexões.

Verifique o arquivo antes de confiar nele e depois inicie o serviço:

sudo systemd-analyze verify /etc/systemd/system/tradingbot.service
sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
systemctl status tradingbot

enable é a parte que sobrevive a uma reinicialização, e as atualizações do kernel exigem reinicializações. Para saber se o bot tem parado silenciosamente, peça ao systemd o contador de reinicializações:

systemctl show tradingbot -p NRestarts
journalctl -u tradingbot --since "24 hours ago" | tail -50

NRestarts=0 depois de uma semana indica um bot saudável. NRestarts=812 significa que você está negociando com um processo que se reconecta durante toda a noite. A anatomia completa do arquivo de unidade, incluindo timers para jobs agendados, como um relatório diário, está descrita em executar um programa como um serviço systemd.

Defina o relógio como UTC e confirme que ele está sincronizado

As APIs de exchanges assinam as solicitações com um timestamp e rejeitam qualquer valor fora de uma janela, geralmente de 5 segundos ou menos. Um relógio com desvio produz erros que parecem falhas de autenticação, então as pessoas passam horas alternando chaves antes de verificar o horário. Em APIs no estilo da Binance, a mensagem é literal: Timestamp for this request was 1000ms ahead of the server's time.

Defina o servidor como UTC. Os fusos horários locais introduzem uma mudança de horário de verão que ocorrerá no meio de uma sessão de negociação.

sudo timedatectl set-timezone UTC
timedatectl

O Ubuntu inclui systemd-timesyncd, que é um cliente SNTP (simple network time protocol). Ele é adequado para logs, mas insuficiente para qualquer tarefa que precise permanecer dentro de poucos milissegundos, porque consulta um servidor e não ajusta o relógio continuamente. Use chrony:

sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

A linha que deve ser lida em chronyc tracking é System time, por exemplo System time : 0.000031415 seconds fast of NTP time. Qualquer valor inferior a poucos milissegundos é saudável. Se o valor for Leap status : Not synchronised, o chrony ainda não alcançou um servidor, geralmente porque a saída UDP 123 está bloqueada. Aguarde um minuto e verifique novamente antes de alterar as regras do firewall.

Mantenha as chaves de API fora dos locais que você copia

Uma chave de exchange vazada é pior que uma chave SSH vazada, porque a permissão de saque a transforma instantaneamente em dinheiro. Dois hábitos cobrem a maior parte do risco.

Primeiro, nunca conceda permissão de saque a uma chave de bot e, quando a exchange oferecer esse recurso, vincule a chave ao endereço IP do servidor. Esse é o único controle que torna uma chave roubada praticamente inútil.

Segundo, mantenha o segredo fora do diretório do código. Tudo que estiver dentro de /opt/tradingbot acabará em um repositório git ou em um arquivo de backup mais cedo ou mais tarde. Coloque-o em um arquivo pertencente a root que somente o systemd possa ler:

sudo install -d -m 750 -o root -g bot /etc/tradingbot
sudo install -m 640 -o root -g bot /dev/null /etc/tradingbot/api.env
sudo nano /etc/tradingbot/api.env

O arquivo contém linhas simples de KEY=value, sem aspas e sem export. O modo 640, com o grupo bot, significa que o usuário do serviço pode ler o arquivo e ninguém mais pode. Verifique com sudo -u bot cat /etc/tradingbot/api.env e depois com qualquer outro usuário; nesse caso, a operação deve falhar com Permission denied.

O próprio bot não deve ser executado como root nem como seu usuário de login. Crie uma conta de sistema sem shell e sem diretório home para fazer login:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /var/lib/tradingbot --create-home bot

A justificativa para cada uma dessas flags e até onde ProtectSystem=strict realmente funciona está em executar serviços como um usuário sem privilégios. O restante da configuração básica do servidor, incluindo chaves SSH e um firewall, deve ser feito em os primeiros dez minutos em uma nova VPS.

Descubra que ele está parado antes da sua corretora

systemctl status informa que o processo está em execução. Isso não informa que o bot está fazendo alguma coisa. Um processo preso em um loop de novas tentativas contra um websocket indisponível passa por todas as verificações que o systemd pode fazer.

Use um heartbeat. O Uptime Kuma tem monitores push: ele espera que o bot chame uma URL em uma programação definida e envia um alerta quando as chamadas deixam de chegar. Coloque a chamada no final do loop principal, depois da parte que comprova que o bot está ativo, como uma leitura bem-sucedida de dados de mercado.

curl -fsS "http://monitor.example.com:3001/api/push/YOUR_TOKEN?status=up&msg=loop_ok"

Defina o intervalo do monitor para aproximadamente o dobro do tempo do loop, para que variações normais não gerem alertas. Execute o monitor em um servidor diferente do bot, porque um monitor que para junto com o componente que monitora não informa nada. A configuração está descrita em monitoramento de status self-hosted com Uptime Kuma.

Adicione também um alerta de disco. Um bot que grava logs detalhados pode ocupar o sistema de arquivos root em algumas semanas. Um disco cheio impede a gravação no banco de dados, mas não a chamada de rede. Por isso, os sintomas são estranhos. journalctl --vacuum-time=14d e uma linha SystemMaxUse= em /etc/systemd/journald.conf mantêm o journal dentro de um limite.

A parte honesta: a latência depende principalmente de fatores externos ao seu host

É aqui que o mercado de produtos VPS para trading deixa de ser técnico. As páginas de marketing citam valores inferiores a 1 milissegundo e dão a entender que o host é o que separa você da execução da ordem. Para quase todo bot de varejo, isso não é verdade.

Sua ordem percorre o caminho entre o bot e o endpoint da exchange ou da corretora pela internet pública. Esse caminho é determinado principalmente pela distância física e pelo peering entre o seu provedor e o provedor da exchange ou corretora. Um servidor em Frankfurt que se comunica com um endpoint em Tóquio terá aproximadamente 250 milissegundos de ida e volta, independentemente da velocidade da CPU. Depois, os próprios sistemas da corretora acrescentam a fila, as verificações de risco e os limites de taxa. Para uma conta de varejo, esses atrasos geralmente são medidos em dezenas ou centenas de milissegundos.

Faça a medição em vez de tentar adivinhar. curl informa os tempos de conexão e do primeiro byte para um endpoint real:

curl -s -o /dev/null -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s\n' \
  https://api.kraken.com/0/public/Time
mtr -rwzc 100 api.kraken.com

Execute esse comando em um servidor candidato antes de contratá-lo. Se connect for 0.180 segundos, você está no continente errado, e isso vale a pena corrigir. Se connect for 0.004 segundos e ttfb for 0.140 segundos, o atraso restante vem do processamento da corretora, e nenhuma mudança de host vai reduzi-lo.

Então, quando o host importa? Quando você está colocalizado ou conectado diretamente à venue e compete pela posição na fila. Esse é um negócio diferente, com um orçamento diferente. O host também importa quando o seu próprio código é o gargalo: um bot que recalcula indicadores sobre todo o histórico a cada tick pode consumir 200 milissegundos de CPU por loop. Essa é uma latência real que você pode controlar sem custo. Analise o desempenho do loop antes de procurar um servidor mais rápido.

O que importa na escolha do host é a localização geográfica, uma rede estável e memória suficiente para que o OOM killer nunca tenha influência. Em julho de 2026, um bot Python de estratégia única com algumas centenas de símbolos na memória funciona confortavelmente com 2 GB de RAM e 2 vCPU. Adicione memória se você mantiver o histórico de ticks em um banco de dados local.

Uma breve lista de verificação antes da entrada em produção

1. systemctl is-enabled tradingbot exibe enabled, e o serviço permanece em execução após sudo reboot.
2. chronyc tracking informa uma diferença no horário do sistema inferior a alguns milissegundos.
3. A chave de API tem permissão para negociar, não tem permissão para sacar, e usa uma lista de permissões de IP se a exchange oferecer esse recurso.
4. Encerrar o processo com sudo systemctl kill -s SIGKILL tradingbot faz com que ele volte a ser executado em até RestartSec.
5. O monitor de heartbeat envia um alerta para você dentro de um intervalo quando você interrompe o bot deliberadamente.
6. Os logs têm tamanho limitado, e o sistema de arquivos raiz tem espaço disponível em df -h.

Execute tudo no sandbox da exchange ou em modo de simulação durante uma semana antes de usar fundos reais. Cada item acima falha pelo menos uma vez durante essa semana. Esse é o objetivo da semana.

FAQ

Um bot de trading precisa de um servidor de baixa latência ou bare metal?

Somente se você estiver competindo pela velocidade de execução com outros participantes automatizados no mesmo local de negociação. Nesse caso, normalmente você precisa de colocation, e não de um VPS de uso geral. Para um bot de varejo, o tempo de ida e volta é determinado principalmente pela distância geográfica e pelo processamento do próprio broker. Escolha um servidor próximo ao endpoint da API e faça medições com curl e mtr antes de pagar por algo mais rápido.

De quanta RAM e CPU um bot de trading precisa?

A maioria dos bots de estratégia única é limitada pela rede e fica ociosa entre os eventos. Em julho de 2026, 2 vCPU e 2 GB de RAM são suficientes para um bot em Python que acompanha algumas centenas de instrumentos. A memória se torna o fator limitante quando você mantém o histórico de ticks no processo ou executa um banco de dados local. Por isso, monitore free -h e o journal em busca de mensagens de encerramento por OOM, em vez de fazer suposições.

Por que minha API da exchange rejeita solicitações com erro de timestamp?

O relógio do servidor se desviou além da janela de assinatura da exchange, normalmente por alguns segundos. Instale o chrony, confirme que chronyc tracking mostra um pequeno deslocamento de System time e um status de salto sincronizado. Configure a máquina para usar UTC, para que uma mudança de horário de verão nunca altere o horário. A rotação da API key não corrige um problema no relógio.

Como faço para impedir que meu bot pare durante a noite sem que eu saiba?

Execute-o sob o systemd com Restart=always e StartLimitIntervalSec=0. Assim, um loop de falhas continuará tentando executar o processo, em vez de parar permanentemente. Depois, adicione um heartbeat enviado pelo bot ao final de cada loop concluído com sucesso. O restart trata do processo. O heartbeat identifica o caso em que o processo está ativo, mas travado.

Posso executar o bot e meu monitoramento no mesmo VPS?

Você pode, mas o monitoramento fornecerá informações incorretas no dia em que isso for importante. Uma indisponibilidade que derrube o bot também derrubará o monitoramento. Mantenha os alertas em uma máquina separada, de preferência com outro provedor ou em outra região. Use o servidor do bot somente para o bot e seus logs.