VPS per bot di trading: cosa conta davvero

Cosa serve a un bot di trading da un VPS

Un VPS per i bot di trading si valuta in base a quattro aspetti: il processo viene riavviato dopo un arresto anomalo, l'orologio è corretto, le chiavi API (application programming interface) sono adeguatamente protette dai furti e si viene informati quando il bot si arresta. Per un bot destinato al trading al dettaglio, la velocità pura ha un'importanza molto inferiore, perché il segmento più lento del percorso dell'ordine è il broker e la distanza che vi separa, non l'host che esegue Python.

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

Il tempo di attività dipende dalla disciplina dei riavvii, non da un numero su una pagina commerciale

Ogni host al mondo pubblicizza un tempo di attività del 99.9 percento. Questo valore descrive l'hypervisor, non il tuo bot. Un bot si arresta a causa di un'eccezione non gestita, di un websocket che non si riconnette mai o dell'OOM (out of memory) killer, mentre il server rimane operativo per tutto il tempo. La domanda utile è quindi che 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 il riavvio. Un file di unità svolge questa funzione 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 rinuncia dopo 5 riavvii in 10 secondi e lascia l'unità nello stato failed per sempre. È esattamente il comportamento che non vuoi alle 03:00. Impostandolo su 0 disabiliti il limite di frequenza, quindi un bot che entra in un ciclo di arresti continua a tentare il riavvio invece di rimanere inattivo. RestartSec=10 interrompe il ciclo prima che sovraccarichi l'exchange con riconnessioni.

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 comportano riavvii. Per verificare se il bot si è arrestato silenziosamente, 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 integro. NRestarts=812 significa che hai fatto trading con un processo che si riconnette per tutta la notte. L'anatomia completa del file di unità, inclusi i timer per i job 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 si verificherà durante una sessione di trading.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu include systemd-timesyncd, che è 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 regola 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 da chronyc tracking è System time, ad esempio System time : 0.000031415 seconds fast of NTP time. Un valore inferiore a pochi millisecondi indica una situazione corretta. Se restituisce 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.

Impedisci che le chiavi API finiscano nei percorsi copiati

Una chiave di exchange esposta è più rischiosa di una chiave SSH esposta, perché il permesso di prelievo può trasformarla immediatamente in denaro. Due abitudini coprono gran parte del rischio.

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

In secondo luogo, tieni il segreto 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 in chiaro, senza virgolette e senza export. La modalità 640 con il gruppo bot consente all'utente del servizio di leggerlo e impedisce l'accesso a chiunque altro. Verifica con sudo -u bot cat /etc/tradingbot/api.env e poi con un altro utente: l'operazione deve fallire con Permission denied.

Il bot non deve essere eseguito come root né come utente con cui accedi al sistema. Crea un account di sistema senza shell e senza directory home in cui effettuare l'accesso:

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 non privilegiato. Il resto della configurazione di base del server, cioè le chiavi SSH e un firewall, è descritto in i primi dieci minuti su un nuovo VPS.

Scopri che è inattivo prima del broker

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

Usa invece un heartbeat. Uptime Kuma supporta i monitor push: prevede che il bot chiami un URL a intervalli prestabiliti 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 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 su circa il doppio della durata del ciclo, in modo che le normali variazioni dei tempi non generino pagine. Esegui il monitor su un server diverso da quello del bot, perché un monitor che termina insieme al processo 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 riempirà il filesystem root in poche settimane e un disco pieno interrompe la scrittura nel database, non la chiamata di rete, quindi i sintomi sono insoliti. journalctl --vacuum-time=14d e una riga SystemMaxUse= in /etc/systemd/journald.conf mantengono il journal entro limiti definiti.

La parte onesta: la latenza dipende soprattutto da fattori esterni all'host

È qui che il mercato dei prodotti VPS per il trading smette di essere tecnico. Le pagine di marketing citano valori inferiori al millisecondo e lasciano intendere che l'host 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 tramite Internet pubblico. Questo percorso dipende soprattutto dalla distanza fisica e dal peering tra il provider dell'utente e quello dell'exchange o del broker. Un server a Francoforte che comunica con un endpoint a Tokyo ha un tempo di andata e ritorno di circa 250 millisecondi, indipendentemente dalla velocità della CPU. A questo si aggiungono i sistemi del broker, con le rispettive code, verifiche del rischio e limitazioni della frequenza delle richieste, che per un account retail si misurano generalmente in decine o centinaia di millisecondi.

Eseguire una misurazione è meglio che fare supposizioni. curl restituisce i tempi di connessione e 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

Eseguire il comando da un server candidato prima di procedere. Se connect è pari a 0.180 secondi, il server si trova nel continente sbagliato e questo problema va risolto. Se connect è pari a 0.004 secondi e ttfb è pari a 0.140 secondi, il ritardo restante è dovuto all'elaborazione del broker e nessuna modifica all'host lo ridurrà.

Quando conta quindi l'host? Quando il server è colocato o connesso tramite cross-connect alla sede di negoziazione e si compete per la posizione nella coda. Si tratta di un'attività diversa, con un budget diverso. L'host conta anche quando il collo di bottiglia è nel proprio 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 è possibile ridurre senza costi. Analizzare le prestazioni del ciclo prima di cercare un server più veloce.

Per scegliere l'host contano 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 con un'unica strategia e alcune centinaia di simboli in memoria funziona senza problemi con 2 GB di RAM e 2 vCPU. Aggiungere memoria se si conserva la cronologia dei tick in un database locale.

Una breve checklist prima dell'uso in produzione

1. systemctl is-enabled tradingbot stampa enabled e il servizio continua a funzionare dopo sudo reboot.
2. chronyc tracking segnala uno scarto dell'orario di sistema inferiore a pochi millisecondi.
3. La chiave API dispone dell'autorizzazione al trading, ma non di quella ai prelievi. Configura anche una lista di indirizzi IP consentiti, se l'exchange la offre.
4. Terminare il processo con sudo systemctl kill -s SIGKILL tradingbot lo riavvia entro RestartSec.
5. Il monitor dell'heartbeat invia una notifica entro un intervallo quando arresti deliberatamente il bot.
6. Le dimensioni dei log sono limitate e il filesystem root dispone di spazio libero sufficiente in df -h.

Esegui l'intera procedura nel sandbox dell'exchange o in modalità paper per una settimana prima di utilizzare fondi reali. Durante quella settimana ogni voce precedente fallisce almeno una volta. È proprio questo lo scopo della settimana di test.

FAQ

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

Solo se competi sulla velocità di esecuzione con altri partecipanti automatizzati sulla stessa sede di trading. In genere, questo richiede la colocation, non un VPS generico. Per un bot retail, il tempo di andata e ritorno dipende soprattutto dalla distanza 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 dalla rete e rimane 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 limite quando mantieni la cronologia dei tick nel processo o esegui un database locale. Monitora quindi free -h e il journal per rilevare i messaggi relativi all'uccisione del processo per esaurimento della memoria (OOM), invece di procedere per supposizioni.

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

L'orologio del server si è discostato oltre la finestra di firma dell'exchange, che normalmente è di pochi secondi. Installa chrony, verifica che chronyc tracking mostri un offset ridotto System time e uno stato dei leap sincronizzato, quindi configura la macchina per usare UTC, così un cambiamento all'ora legale non potrà mai spostare l'orologio. La rotazione della chiave API non risolve un problema dell'orologio.

Come posso impedire che il mio bot si arresti durante la notte senza che io lo sappia?

Eseguilo con systemd usando Restart=always e StartLimitIntervalSec=0, così un ciclo di arresti e riavvii continuerà a ritentare invece di fermarsi 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?

Sì, ma il monitoraggio ti fornirà informazioni errate proprio quando sarà importante, perché un'interruzione che arresta il bot arresta anche il monitoraggio. Mantieni il sistema di alerting su una macchina separata, idealmente con un provider o una regione diversi, e usa il server del bot solo per il bot e i relativi log.