Um bot de trading no seu notebook é uma má ideia por uma razão chata: seu notebook não fica online 24/7, e os mercados ficam. Feche a tampa no meio de uma operação e o bot para de gerenciar uma posição aberta. O Freqtrade — o popular bot de trading open-source em Python — é feito para rodar sem supervisão, que é exatamente para o que serve um VPS pequeno. Eis o que ele de fato precisa, como configurá-lo com Docker e os limites honestos que ninguém menciona até você bater neles.
Por que um servidor, e não sua máquina
Duas razões, ambas práticas:
- Uptime. O bot tem que vigiar o mercado e gerenciar posições o tempo todo. Toda vez que seu notebook dorme ou reinicia, o bot fica cego — uma entrada perdida ou, pior, uma posição aberta que ninguém está vigiando.
- Latência e estabilidade. Um VPS fica numa conexão de datacenter com uma rota estável até a exchange. O jitter do wifi de casa e os resets de NAT não ajudam um bot que reage ao preço.
Esta é a mesma lógica por trás de rodar qualquer bot de trading num VPS — o Freqtrade só torna os requisitos concretos.
O que ele de fato precisa
O Freqtrade em si é leve, mas seja realista sobre a carga:
- Bot live / dry-run: 2 GB de RAM é um piso confortável. A imagem Docker, um punhado de pares, indicadores e o banco SQLite de trades querem uma folga. Um Micro de US$5 (2 vCPU / 2 GB / 25 GB) é o ponto de partida certo. 1 GB pode rodar uma única estratégia simples em poucos pares, mas você fica mais perto do limite.
- Muitos pares / múltiplas estratégias: suba para um Small de US$8 (4 vCPU / 4 GB / 35 GB) — mais pares significa mais cálculo concorrente de indicadores e um dataframe maior em memória.
- Disco: modesto. A imagem, seu
user_datae o banco de trades cabem confortavelmente em 25 GB. Dados históricos baixados para backtesting são a única coisa que cresce — e isso mora principalmente na sua máquina local (veja abaixo).
Configure com Docker Compose
O Docker é a forma mantida e menos dolorosa de rodar o Freqtrade. Numa máquina nova:
sudo apt update && sudo apt install -y docker.io docker-compose-v2
mkdir ~/ft && cd ~/ft
docker run --rm -v "$(pwd)/user_data:/freqtrade/user_data" \
freqtradeorg/freqtrade:stable create-userdir --userdir user_data
Pegue o arquivo compose oficial e crie uma config interativamente (ele vai perguntar sobre sua exchange, stake e dry-run):
curl -s https://raw.githubusercontent.com/freqtrade/freqtrade/stable/docker-compose.yml -o docker-compose.yml
docker compose run --rm freqtrade new-config --config user_data/config.json
Dry-run primeiro — sempre
Nunca aponte uma estratégia nova para dinheiro real. O Freqtrade usa dry-run (paper trading) por padrão e você deve deixá-lo aí até a estratégia ter se provado em dados de mercado ao vivo por um tempo. Em config.json:
{
"dry_run": true,
"dry_run_wallet": 1000
}
Inicie-o e observe:
docker compose up -d
docker compose logs -f
A política restart: unless-stopped no arquivo compose é o seu equivalente ao systemd aqui — o Docker traz o bot de volta após uma queda ou um reboot do servidor, sem passo manual. (Se você prefere rodá-lo fora do Docker, uma unit do systemd com Restart=always faz o mesmo trabalho — mesmo princípio de manter qualquer bot vivo.)
Chaves de API da exchange — a parte que morde as pessoas
É aqui que um setup de trading dá errado de forma cara. Duas regras, inegociáveis:
- Só permissão de trade. Nunca habilite saque. Se a chave vazar, o pior caso são trades indesejados — não seus fundos saindo pela porta. O Freqtrade nunca precisa de acesso de saque.
- Faça whitelist de IP da chave. A maioria das exchanges deixa você vincular uma chave de API a IPs específicos. Essa é uma razão concreta para rodar num plano com IP dedicado: a chave só funciona do endereço fixo do seu servidor. Num plano NAT o bot compartilha o IP de saída do nó, que não é só seu — bom para o bot funcionar, mas você não consegue fazer whitelist dele de forma limpa.
Mantenha as chaves em config.json, torne-o não legível por todos (chmod 600) e rode o container como usuário não-root. E tranque a máquina primeiro — o checklist de segurança de VPS novo leva dez minutos e fecha as portas que importam.
Faça backup do user_data
Suas estratégias, config e histórico de trades vivem todos em user_data. Essa é a coisa que você não quer perder:
tar czf ft-backup-$(date +%F).tar.gz user_data
Puxe isso do servidor periodicamente (ou para armazenamento de objetos). Perder o banco de trades significa perder seu histórico de desempenho; perder uma estratégia ajustada significa refazer a otimização.
Os limites honestos
- Backtesting e hyperopt são pesados — faça-os localmente. Eles fixam a CPU por trechos prolongados, e um VPS compartilhado e orientado a burst é feito para cargas em rajada, não horas de carga sustentada de 100% (que também esbarra na política de uso aceitável). Otimize na sua própria máquina, implante o resultado para rodar live. O VPS é para o bot live, não para a pesquisa.
- A CPU é compartilhada/burst. Ótima para um bot live que na maior parte espera por candles e reage; errada para triturar um ano de dados de 1 minuto por hyperopt.
- Uma região, só CPU. O servidor fica na Alemanha sem GPU. Bom para o Freqtrade (é CPU/lógica, não treinamento de ML) — vale saber se sua estratégia se apoia num modelo de ML pesado, que de novo é melhor treinado localmente.
Conclusão
O Freqtrade num VPS é o setup certo para o bot live: um Micro de US$5 para uma estratégia focada, um Small de US$8 se você roda muitos pares, Docker Compose com restart: unless-stopped para uptime, e uma chave de API só de trade e com whitelist de IP para que um vazamento não te esvazie. Mantenha o backtesting e o hyperopt pesados no seu notebook, faça backup do user_data e deixe o servidor fazer a única coisa em que é bom — ficar online enquanto o mercado se mexe. O cadastro é só por e-mail e você paga em USDC ou USDT; um IP dedicado é o único upgrade que vale aqui, puramente pela whitelist da chave de API.
Pronto para implantar? O Freqtrade fica confortável num plano Micro; para backtests mais pesados ou muitos pares, suba para o Small.
Comentários
Nenhum comentário ainda. Seja o primeiro.