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 aspetos: o processo volta a arrancar depois de terminar, o relógio está certo, as chaves da API (application programming interface) estão protegidas contra roubo e é detetada uma paragem. Para um bot de retalho, a velocidade bruta fica muito abaixo desses fatores, porque a parte mais lenta do percurso da ordem é o seu broker e a distância até ele, não o host que executa o seu Python.

Este é um guia de engenharia. Nada do que está aqui constitui aconselhamento financeiro e nenhuma estratégia é discutida.

Disciplina de reinício define a disponibilidade, não um número numa página comercial

Todos os hosts do mundo anunciam 99.9 por cento de disponibilidade. Esse valor descreve o hypervisor, não o seu bot. Um bot termina devido a uma exceção não tratada, a um websocket que nunca restabelece a ligação ou ao OOM (out of memory) killer, enquanto o servidor permanece disponível durante todo o tempo. Por isso, a pergunta útil é o que acontece nos dez segundos depois de o processo terminar.

Execute o bot como um serviço systemd e deixe o sistema init gerir o reinício. Um ficheiro 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 muitas pessoas esquecem. Por predefinição, o systemd desiste depois de 5 reinícios em 10 segundos e deixa a unidade permanentemente no estado failed, que é exatamente o comportamento que não pretende às 03:00. Definir esse valor como 0 desativa o limite de frequência. Assim, um bot que entra num ciclo de falhas continua a tentar em vez de ficar silencioso. RestartSec=10 impede que esse ciclo sobrecarregue a exchange com tentativas de restabelecimento da ligação.

Verifique o ficheiro antes de confiar nele e, em seguida, 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 um reboot, e as atualizações do kernel implicam reboots. Para verificar se o bot tem terminado silenciosamente, peça ao systemd o contador de reinícios:

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 tem negociado com um processo que restabelece a ligação durante toda a noite. A anatomia completa do ficheiro de unidade, incluindo timers para tarefas agendadas, como um relatório diário, é apresentada em executar um programa como serviço systemd.

Configure o relógio para UTC e confirme que está sincronizado

As APIs de exchanges assinam os pedidos com um timestamp e rejeitam valores fora de uma janela, muitas vezes de 5 segundos ou menos. Um relógio com desvio produz erros que parecem falhas de autenticação. Por isso, é comum rodar as chaves durante horas antes de verificar a hora. Nas APIs do tipo Binance, a mensagem é literal: Timestamp for this request was 1000ms ahead of the server's time.

Configure o servidor para UTC. Os fusos horários locais introduzem uma mudança para o horário de verão que pode ocorrer a 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). É suficiente para logs, mas inadequado para qualquer tarefa que precise de se manter dentro de poucos milissegundos, porque consulta um servidor e não corrige 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 a consultar 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 apresentar Leap status : Not synchronised, o chrony ainda não alcançou um servidor, normalmente porque o UDP 123 de saída está bloqueado. Aguarde um minuto e verifique novamente antes de alterar as regras da firewall.

Mantenha as chaves da API fora dos locais que copia

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

Primeiro, nunca conceda permissão de levantamento a uma chave de bot e, quando a exchange permitir, associe a chave ao endereço IP do seu servidor. Este é o único controlo que torna uma chave roubada praticamente inútil.

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

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 ficheiro contém linhas simples de KEY=value, sem aspas e sem export. O modo 640, com o grupo bot, permite que o utilizador do serviço leia o ficheiro e impede o acesso de qualquer outra pessoa. Verifique com sudo -u bot cat /etc/tradingbot/api.env e depois com outro utilizador, caso em que o comando tem de falhar com Permission denied.

O bot não deve ser executado como root nem como o seu utilizador de login. Crie uma conta de sistema sem shell e sem diretório inicial para executar o serviço:

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

A explicação de cada uma dessas flags e do alcance efetivo de ProtectSystem=strict está em executar serviços como um utilizador sem privilégios. O resto da configuração base do servidor, incluindo chaves SSH e uma firewall, está em os primeiros dez minutos num VPS novo.

Descubra que está inativo antes do seu broker

systemctl status indica que o processo está em execução. Isso não significa que o bot esteja a fazer alguma coisa. Um processo preso num ciclo de novas tentativas contra um websocket indisponível passa todas as verificações que o systemd consegue fazer.

Use um heartbeat. O Uptime Kuma tem monitores push: espera que o seu bot chame um URL periodicamente e envia um alerta quando essa chamada deixa de chegar. Coloque a chamada no fim 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 pequenas variações normais não gerem alertas. Execute o monitor num servidor diferente do bot, porque um monitor que termina com o processo que supervisiona não comunica nada. A configuração está descrita em monitorização de estado self-hosted com Uptime Kuma.

Adicione também um alerta de disco. Um bot que escreve logs detalhados pode encher o sistema de ficheiros raiz em poucas semanas. Um disco cheio impede a escrita na base de dados, mas não a chamada de rede, pelo que os sintomas são estranhos. journalctl --vacuum-time=14d e uma linha SystemMaxUse= em /etc/systemd/journald.conf mantêm o journal dentro de limites.

A parte honesta: a latência depende sobretudo de fatores que não estão no seu host

É aqui que o mercado de produtos VPS para trading deixa de ser técnico. As páginas de marketing apresentam valores inferiores a 1 milissegundo e sugerem que o host é o que separa o utilizador de uma execução. Para quase todos os bots de retalho, não é.

A sua ordem viaja do bot até ao endpoint da exchange ou do broker através da Internet pública. Esse percurso é determinado sobretudo pela distância física e pelo peering entre o seu fornecedor e o fornecedor do endpoint. Um servidor em Frankfurt a comunicar com um endpoint em Tóquio tem uma latência de aproximadamente 250 milissegundos de ida e volta, independentemente da velocidade do CPU. Depois, os próprios sistemas do broker acrescentam a fila, as verificações de risco e os limites de pedidos. Numa conta de retalho, estes tempos são normalmente medidos em dezenas ou centenas de milissegundos.

Meça em vez de adivinhar. curl apresenta os tempos de ligaçã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 num servidor candidato antes de o contratar. Se connect for 0.180 segundos, está no continente errado, e vale a pena corrigir isso. Se connect for 0.004 segundos e ttfb for 0.140 segundos, o atraso restante é causado pelo processamento do broker, e mudar de host não o vai reduzir.

Quando é que o host importa? Quando está numa instalação colocalizada ou ligado por uma ligação dedicada à venue e compete pela posição na fila. Isso é uma atividade 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 ciclo. Essa é uma latência real que pode controlar sem custos. Faça o profiling do ciclo antes de procurar um servidor mais rápido.

No host escolhido, o que importa é a localização geográfica, uma rede estável e memória suficiente para que o OOM killer nunca intervenha. Em julho de 2026, um bot Python de estratégia única com algumas centenas de símbolos em memória funciona confortavelmente com 2 GB de RAM e 2 vCPU. Adicione memória se mantiver o histórico de ticks numa base de dados local.

Uma lista de verificação curta antes de colocar em produção

1. systemctl is-enabled tradingbot mostra enabled, e o serviço continua em execução depois de sudo reboot.
2. chronyc tracking indica uma diferença inferior a alguns milissegundos no relógio do sistema.
3. A chave da API tem permissão para negociar, não tem permissão para levantamentos e usa uma lista de permissões de IP, se a exchange disponibilizar essa opção.
4. Terminar o processo com sudo systemctl kill -s SIGKILL tradingbot faz com que ele volte a arrancar no prazo de RestartSec.
5. O monitor de heartbeat envia-lhe um alerta dentro de um intervalo quando interrompe deliberadamente o bot.
6. Os logs têm limites definidos, e o sistema de ficheiros root tem espaço livre suficiente 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 do período de teste.

FAQ

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

Apenas se estiver a competir pela velocidade de execução com outros participantes automatizados no mesmo mercado, o que normalmente significa colocation, e não um VPS de uso geral. Num bot de retalho, o tempo de ida e volta é dominado pela distância geográfica e pelo processamento do próprio broker. Por isso, escolha um servidor próximo do 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 precisa um bot de trading?

A maioria dos bots de estratégia única é limitada pela rede e fica inativa entre eventos. Em julho de 2026, 2 vCPU e 2 GB de RAM são suficientes para um bot Python que acompanhe algumas centenas de instrumentos. A memória torna-se o fator limitante quando mantém o histórico de ticks no processo ou executa uma base de dados local. Nesse caso, monitorize free -h e o journal à procura de mensagens de OOM kill, em vez de tentar adivinhar.

Porque é que a minha API da exchange rejeita pedidos com um erro de timestamp?

O relógio do servidor desviou-se para além da janela de assinatura da exchange, normalmente por alguns segundos. Instale chrony, confirme que chronyc tracking apresenta um desvio pequeno em System time e um estado de leap sincronizado. Configure também a máquina para UTC, para que uma mudança para o horário de verão nunca a desloque. Rodar a API key não resolve um problema de relógio.

Como posso impedir que o meu bot pare durante a noite sem eu saber?

Execute-o com systemd usando Restart=always e StartLimitIntervalSec=0, para que um ciclo de falhas continue a tentar reiniciar em vez de parar permanentemente. Depois, adicione um heartbeat que o bot envie no final de cada ciclo concluído com sucesso. O reinício trata do processo. O heartbeat deteta o caso em que o processo está ativo, mas bloqueado.

Posso executar o bot e o sistema de monitorização no mesmo VPS?

Pode, mas o sistema de monitorização irá fornecer informações erradas no dia em que isso for importante, porque uma falha que derrube o bot também derrubará o monitor. Mantenha os alertas numa máquina separada, idealmente com outro fornecedor ou noutra região, e utilize o servidor do bot apenas para o bot e os respetivos logs.