VPS per trading bot: cosa conta davvero

Cosa serve a un trading bot da un VPS

Un VPS per trading bot si valuta in base a quattro aspetti: il processo riparte dopo un arresto anomalo, l’orologio è sincronizzato, le chiavi API (application programming interface) sono protette dai furti e ricevi una notifica quando il bot si arresta. Per un bot retail, la velocità pura è molto meno importante. La parte più lenta del percorso dell’ordine dipende dal broker e dalla distanza da esso, non dall’host che esegue il tuo codice Python.

Questa è una guida tecnica. Il contenuto non costituisce consulenza finanziaria e non tratta alcuna strategia.

La disponibilità dipende dalla disciplina dei riavvii, non da un numero su una pagina commerciale

Ogni host al mondo pubblicizza una disponibilità del 99.9 percento. Quel valore descrive l’hypervisor, non il tuo bot. Un bot può arrestarsi a causa di un’eccezione non gestita, di una websocket che non si riconnette mai oppure dell’OOM (out of memory) killer, mentre il server rimane operativo per tutto il tempo. La domanda utile è quindi cosa accade nei dieci secondi successivi all’uscita del processo.

Esegui il bot come servizio systemd e lascia che sia il sistema init a gestire i riavvii. Un file unit realizza questa configurazione in sei righe.

[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 è la riga che spesso viene trascurata. Per impostazione predefinita, systemd interrompe i tentativi dopo 5 riavvii in 10 secondi e lascia l’unit nello stato failed per sempre. È esattamente il comportamento da evitare alle 03:00. Impostando il valore su 0 disabiliti il limite di frequenza. Un bot che entra in un ciclo di arresti e riavvii continua quindi a riprovare invece di rimanere inattivo. RestartSec=10 impedisce che questo ciclo sovraccarichi l’exchange con nuove connessioni.

Controlla il file prima di considerarlo affidabile, quindi avvialo:

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

enable è la parte che rimane attiva dopo un riavvio, e gli aggiornamenti del kernel richiedono riavvii. Per verificare se il bot si è arrestato ripetutamente senza che tu lo notassi, chiedi a systemd il contatore dei riavvii:

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

NRestarts=0 dopo una settimana indica un bot stabile. NRestarts=812 significa che hai fatto trading con un processo che si riconnette per tutta la notte. L’anatomia completa del file unit, inclusi i timer per i processi pianificati come un report giornaliero, è descritta in eseguire un programma come servizio systemd.

Impostare l'orologio su UTC e verificare la sincronizzazione

Le API degli exchange firmano le richieste con un timestamp e rifiutano quelle che non rientrano in una finestra temporale, spesso di 5 secondi o meno. Un orologio non sincronizzato produce errori che sembrano problemi di autenticazione, quindi si ruotano le chiavi per ore prima di controllare l'ora. Nelle API in stile Binance il messaggio è letterale: Timestamp for this request was 1000ms ahead of the server's time.

Impostare il server su UTC. I fusi orari locali introducono un passaggio all'ora legale che può verificarsi nel corso di una sessione di trading.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu include systemd-timesyncd, un client SNTP (simple network time protocol). È sufficiente per i log, ma non è adatto alle attività che devono restare entro pochi millisecondi, perché interroga un solo server e non corregge continuamente l'orologio. Usare invece chrony:

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

La riga da leggere in chronyc tracking è System time, ad esempio System time : 0.000031415 seconds fast of NTP time. Un valore inferiore a pochi millisecondi indica una sincronizzazione corretta. Se il valore è Leap status : Not synchronised, chrony non ha ancora raggiunto un server, in genere perché UDP 123 in uscita è bloccato. Attendere un minuto, quindi controllare di nuovo prima di modificare le regole del firewall.

Mantieni le chiavi API fuori dalle directory che copi

Una chiave dell'exchange divulgata è più rischiosa di una chiave SSH divulgata, perché il permesso di effettuare prelievi consente di convertire immediatamente la chiave in denaro. Due pratiche coprono la maggior parte del rischio.

Per prima cosa, non concedere mai il permesso di effettuare prelievi a una chiave usata da un bot e, se l'exchange lo supporta, limita la chiave all'indirizzo IP del server. Questo è il singolo controllo che rende quasi inutilizzabile una chiave sottratta.

In secondo luogo, mantieni il secret fuori dalla directory del codice. Prima o poi, tutto ciò che si trova in /opt/tradingbot finisce in un repository git o in un archivio di backup. Inseriscilo in un file di proprietà di root che solo systemd possa leggere:

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

Il file contiene righe KEY=value semplici, senza virgolette e senza export. La modalità 640, con il gruppo bot, consente all'utente del servizio di leggere il file e impedisce l'accesso a chiunque altro. Verifica con sudo -u bot cat /etc/tradingbot/api.env e poi con un altro utente: in questo caso il comando deve fallire con Permission denied.

Il bot non deve essere eseguito come root né come utente con cui effettui il login. Crea un account di sistema senza shell e senza directory home in cui effettuare il login:

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

La motivazione di ciascuno di questi flag e l'effettiva portata di ProtectSystem=strict sono descritte in eseguire i servizi con un utente senza privilegi. Il resto della configurazione di base del server, ovvero chiavi SSH e firewall, è descritto in i primi dieci minuti su un nuovo VPS.

Scoprilo prima che il tuo broker

systemctl status indica che il processo è in esecuzione. Non indica che il bot stia eseguendo operazioni. Un processo bloccato in un ciclo di tentativi contro un websocket non disponibile supera tutti i controlli che systemd può eseguire.

Usa invece un heartbeat. Uptime Kuma supporta i monitor push: si aspetta che il bot chiami un URL secondo una pianificazione e invia un avviso quando le chiamate smettono di arrivare. Inserisci la chiamata alla fine del ciclo principale, dopo la parte che dimostra che il bot è attivo, ad esempio dopo una lettura riuscita dei dati di mercato.

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

Imposta l'intervallo del monitor a circa il doppio della durata del ciclo, in modo che le normali variazioni non generino pagine. Esegui il monitor su un server diverso da quello del bot, perché un monitor che si arresta insieme al componente controllato non segnala nulla. La configurazione è descritta in monitoraggio dello stato self-hosted con Uptime Kuma.

Aggiungi anche un avviso per il disco. Un bot che scrive log dettagliati può riempire il filesystem root in poche settimane. Quando il disco è pieno, si interrompe la scrittura nel database, non la chiamata di rete, quindi i sintomi possono essere anomali. journalctl --vacuum-time=14d e una riga SystemMaxUse= in /etc/systemd/journald.conf mantengono il journal entro limiti definiti.

La parte più importante: la latenza dipende soprattutto da fattori esterni al server

È in questo punto che il mercato dei VPS per il trading smette di essere tecnico. Le pagine di marketing dichiarano valori inferiori al millisecondo e suggeriscono che il server sia ciò che separa l'utente dall'esecuzione dell'ordine. Per quasi tutti i bot retail, non è così.

L'ordine viaggia dal bot all'endpoint dell'exchange o del broker attraverso Internet. Il percorso dipende soprattutto dalla distanza fisica e dal peering tra il provider dell'utente e quello del broker o dell'exchange. Un server a Francoforte che comunica con un endpoint a Tokyo impiega circa 250 millisecondi per un andata e ritorno, indipendentemente dalla velocità della CPU. Inoltre, i sistemi del broker aggiungono le proprie code, i controlli di rischio e i rate limit, che per un account retail richiedono in genere decine o centinaia di millisecondi.

Misura invece di fare supposizioni. curl mostra i tempi di connessione e di ricezione del primo byte per un endpoint reale:

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

Esegui questo comando da un server candidato prima di acquistarlo. Se connect è pari a 0.180 secondi, il server si trova nel continente sbagliato e questo è un problema che vale la pena risolvere. Se connect è pari a 0.004 secondi e ttfb è pari a 0.140 secondi, il ritardo restante dipende dall'elaborazione del broker e nessun cambio di server lo ridurrà.

Quando conta quindi il server? Quando il server è colocato presso la sede di negoziazione oppure collegato tramite una connessione dedicata, e si compete per la posizione nella coda. Si tratta di un'attività diversa, con un budget diverso. Il server conta anche quando il collo di bottiglia è il codice. Un bot che ricalcola gli indicatori sull'intera cronologia a ogni tick può consumare 200 millisecondi di CPU per ciclo. Questa è latenza reale che puoi controllare senza costi aggiuntivi. Esegui il profiling del ciclo prima di cercare un server più veloce.

Nel server scelto contano invece la posizione geografica, una rete stabile e una quantità di memoria sufficiente a impedire che l'OOM killer possa intervenire. A luglio 2026, un bot Python che esegue una sola strategia e mantiene in memoria alcune centinaia di simboli funziona senza problemi con 2 GB di RAM e 2 vCPU. Aumenta la memoria se conservi la cronologia dei tick in un database locale.

Una breve checklist prima della messa in produzione

1. systemctl is-enabled tradingbot restituisce enabled e il servizio resta attivo dopo sudo reboot.
2. chronyc tracking segnala uno scostamento dell'ora di sistema inferiore a pochi millisecondi.
3. La chiave API dispone dell'autorizzazione al trading, non dell'autorizzazione ai prelievi, e di una allowlist di indirizzi IP se l'exchange ne offre una.
4. Terminando il processo con sudo systemctl kill -s SIGKILL tradingbot, questo viene riavviato entro RestartSec.
5. Il monitor dell'heartbeat invia una notifica entro un intervallo quando arresti deliberatamente il bot.
6. I log hanno dimensioni limitate e il filesystem root dispone di spazio libero sufficiente in df -h.

Esegui l'intera configurazione nel sandbox dell'exchange o in paper mode per una settimana prima di usare fondi reali. Durante quella settimana ogni elemento precedente fallirà almeno una volta. È proprio questo lo scopo della settimana.

FAQ

Un bot di trading ha bisogno di un server a bassa latenza o bare metal?

Solo se compete sulla velocità di esecuzione con altri partecipanti automatizzati nella stessa sede, situazione che normalmente richiede la colocation anziché un VPS general purpose. Per un bot retail, il round trip dipende soprattutto dalla posizione geografica e dall'elaborazione del broker. Scegli quindi un server vicino all'endpoint API e misura con curl e mtr prima di pagare per prestazioni superiori.

Quanta RAM e CPU servono a un bot di trading?

La maggior parte dei bot con una singola strategia è vincolata alla rete e resta inattiva tra un evento e l'altro. A luglio 2026, 2 vCPU e 2 GB di RAM sono sufficienti per un bot Python che monitora alcune centinaia di strumenti. La memoria diventa il fattore limitante quando mantieni in memoria la cronologia dei tick o esegui un database locale. Controlla quindi free -h e il journal per rilevare messaggi di OOM kill invece di procedere per supposizioni.

Perché l'API dell'exchange rifiuta le richieste con un errore di timestamp?

L'orologio del server è fuori sincronizzazione rispetto alla finestra temporale prevista per la firma dell'exchange, in genere di alcuni secondi. Installa chrony, verifica che chronyc tracking mostri un offset ridotto System time e uno stato leap sincronizzato, quindi imposta la macchina su UTC per evitare che un passaggio all'ora legale modifichi l'orario. La rotazione della chiave API non risolve un problema dell'orologio.

Come posso impedire che il bot si arresti durante la notte senza che me ne accorga?

Eseguilo con systemd usando Restart=always e StartLimitIntervalSec=0, in modo che un ciclo di crash continui i tentativi di riavvio invece di arrestarsi definitivamente. Aggiungi quindi un heartbeat che il bot invia al termine di ogni ciclo completato correttamente. Il riavvio gestisce il processo. L'heartbeat rileva il caso in cui il processo è attivo ma bloccato.

Posso eseguire il bot e il monitoraggio sullo stesso VPS?

È possibile, ma il monitoraggio ti fornirà informazioni errate proprio quando sarà più importante, perché un'interruzione che arresta il bot arresterà anche il monitoraggio. Mantieni il sistema di alerting su una macchina separata, idealmente presso un provider o in una regione diversa, e usa il server del bot soltanto per il bot e i relativi log.