Jaki VPS wybrać pod boty handlowe i na co uważać

Czego bot handlowy wymaga od VPS

VPS dla botów handlowych oceniany jest pod kątem czterech czynników: czy proces wznawia działanie po awarii, czy zegar jest zsynchronizowany, czy klucze API (application programming interface) są odpowiednio zabezpieczone przed kradzieżą oraz czy użytkownik otrzymuje powiadomienie o zatrzymaniu bota. Surowa wydajność procesora ma drugorzędne znaczenie dla bota detalicznego, ponieważ wąskim gardłem ścieżki zlecenia jest broker oraz odległość sieciowa do niego, a nie host uruchamiający kod w języku Python.

Niniejszy dokument stanowi przewodnik inżynieryjny. Treść nie stanowi porady finansowej i nie omawia żadnych strategii inwestycyjnych.

Uptime to dyscyplina restartów, a nie liczba w materiałach marketingowych

Każdy host na świecie deklaruje dostępność na poziomie 99,9 procent. Ta wartość opisuje hypervisor, a nie Twojego bota. Bot może przestać działać z powodu nieobsłużonego wyjątku, zerwanego połączenia websocket, które nie zostało wznowione, lub mechanizmu OOM (out of memory) killer, podczas gdy serwer pozostaje włączony. Dlatego istotne jest pytanie, co dzieje się w ciągu dziesięciu sekund po zakończeniu procesu.

Uruchom bota jako usługę systemd i pozwól systemowi init zarządzać restartami. Plik jednostki (unit file) realizuje to w sześciu liniach.

[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 to linia, którą często pomija się w konfiguracji. Domyślnie systemd poddaje się po 5 restartach w ciągu 10 sekund i pozostawia jednostkę w stanie failed na stałe, co jest zachowaniem niepożądanym o godzinie 03:00. Ustawienie tej wartości na 0 wyłącza limit częstotliwości, dzięki czemu bot w pętli awarii będzie ponawiał próby zamiast przejść w stan uśpienia. RestartSec=10 zapobiega przeciążeniu giełdy przez zbyt częste próby ponownego połączenia.

Sprawdź plik przed jego użyciem, a następnie uruchom usługę:

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

enable to parametr, który przetrwa restart systemu, a aktualizacje jądra wymagają restartów. Aby sprawdzić, czy bot nie ulegał cichym awariom, zapytaj systemd o licznik restartów:

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

NRestarts=0 po tygodniu oznacza poprawnie działającego bota. NRestarts=812 oznacza, że proces przez całą noc wielokrotnie nawiązywał połączenie. Pełna struktura pliku jednostki, w tym timery dla zadań zaplanowanych, takich jak raport dzienny, została opisana w uruchamianie programu jako usługi systemd.

Ustawienie czasu UTC i weryfikacja synchronizacji

Interfejsy API giełd podpisują żądania znacznikiem czasu i odrzucają każde, które wykracza poza określone okno czasowe, często wynoszące 5 sekund lub mniej. Rozbieżność czasu powoduje błędy przypominające problemy z uwierzytelnianiem, co prowadzi do wielogodzinnej rotacji kluczy przed sprawdzeniem ustawień zegara. W przypadku API typu Binance komunikat jest dosłowny: Timestamp for this request was 1000ms ahead of the server's time.

Ustaw serwer na czas UTC. Lokalne strefy czasowe wprowadzają przesunięcia wynikające z czasu letniego, które mogą wystąpić w trakcie sesji handlowej.

sudo timedatectl set-timezone UTC
timedatectl

System Ubuntu dostarczany jest z systemd-timesyncd, czyli klientem SNTP (Simple Network Time Protocol). Jest on wystarczający dla logów, ale zbyt mało precyzyjny dla zadań wymagających dokładności rzędu kilku milisekund, ponieważ odpytuje jeden serwer i nie koryguje zegara w sposób ciągły. Zamiast tego należy użyć chrony:

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

Wiersz do odczytania z chronyc tracking to System time, na przykład System time : 0.000031415 seconds fast of NTP time. Każda wartość poniżej kilku milisekund jest prawidłowa. Jeśli wyświetla się Leap status : Not synchronised, oznacza to, że chrony nie połączyło się jeszcze z serwerem, zazwyczaj z powodu zablokowanego ruchu wychodzącego UDP 123. Należy odczekać minutę i sprawdzić ponownie przed modyfikacją reguł zapory sieciowej.

Przechowywanie kluczy API poza miejscami, które kopiujesz

Wyciek klucza giełdowego jest groźniejszy niż wyciek klucza SSH, ponieważ uprawnienia do wypłat pozwalają na natychmiastową kradzież środków. Dwa nawyki eliminują większość ryzyka.

Po pierwsze, nigdy nie nadawaj uprawnień do wypłat kluczom botów, a jeśli giełda na to pozwala, powiąż klucz z adresem IP swojego serwera. Jest to pojedyncze zabezpieczenie, które sprawia, że skradziony klucz staje się niemal bezużyteczny.

Po drugie, przechowuj sekret poza katalogiem z kodem. Wszystko, co znajduje się w /opt/tradingbot, prędzej czy później trafi do repozytorium git lub archiwum kopii zapasowej. Umieść go w pliku należącym do root, który odczytuje tylko systemd:

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

Plik zawiera zwykłe linie KEY=value bez cudzysłowów i bez export. Tryb 640 z grupą bot oznacza, że użytkownik usługi może go odczytać, a nikt inny nie ma do niego dostępu. Zweryfikuj to za pomocą sudo -u bot cat /etc/tradingbot/api.env, a następnie sprawdź z poziomu innego użytkownika, gdzie operacja musi zakończyć się błędem Permission denied.

Sam bot nie powinien działać jako root ani jako Twój użytkownik systemowy. Utwórz konto systemowe bez powłoki i bez katalogu domowego, do którego można się zalogować:

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

Uzasadnienie użycia każdej z tych flag oraz zakres działania ProtectSystem=strict znajduje się w uruchamianie usług jako użytkownik bez uprawnień. Reszta podstawowej konfiguracji serwera, klucze SSH oraz firewall, zostały opisane w pierwsze dziesięć minut na nowym VPS.

Wykryj awarię, zanim zrobi to broker

systemctl status wskazuje, że proces działa. Nie oznacza to jednak, że bot wykonuje jakiekolwiek zadania. Proces zawieszony w pętli ponawiania prób połączenia z niedziałającym websocketem przechodzi każdą kontrolę systemd.

Zastosuj mechanizm heartbeat. Uptime Kuma oferuje monitory typu push: oczekuje, że bot wywoła adres URL zgodnie z harmonogramem, a w przypadku braku wywołania wysyła alert. Umieść wywołanie na końcu głównej pętli, po fragmencie potwierdzającym aktywność bota, na przykład po poprawnym odczycie danych rynkowych.

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

Ustaw interwał monitorowania na około dwukrotność czasu trwania pętli, aby uniknąć fałszywych alarmów spowodowanych typowymi opóźnieniami. Uruchom monitor na innym serwerze niż bot, ponieważ monitor, który ulegnie awarii wraz z monitorowaną usługą, nie wyśle żadnego powiadomienia. Konfiguracja została opisana w samodzielnym monitorowaniu statusu za pomocą Uptime Kuma.

Dodaj również alert dotyczący miejsca na dysku. Bot zapisujący szczegółowe logi zapełni system plików root w ciągu kilku tygodni, a pełny dysk wstrzymuje zapis do bazy danych, nie przerywając wywołań sieciowych, co prowadzi do nietypowych objawów. journalctl --vacuum-time=14d oraz linia SystemMaxUse= w /etc/systemd/journald.conf pozwalają ograniczyć rozmiar dziennika.

Szczera prawda: opóźnienia zazwyczaj nie wynikają z winy hosta

W tym miejscu rynek usług VPS dla tradingu przestaje być techniczny. Strony marketingowe podają wartości opóźnień rzędu ułamków milisekund, sugerując, że to host stanowi barierę w realizacji zlecenia. W przypadku niemal każdego bota detalicznego tak nie jest.

Zlecenie przesyłane jest z bota do punktu końcowego giełdy lub brokera przez publiczny Internet. O tej ścieżce decyduje odległość fizyczna oraz polityka peeringowa między dostawcą usług a brokerem. Serwer we Frankfurcie komunikujący się z punktem końcowym w Tokio generuje opóźnienie rzędu 250 milisekund w obie strony, niezależnie od szybkości procesora. Następnie systemy brokera dodają własną kolejkę, kontrole ryzyka oraz limity szybkości, które dla kont detalicznych zazwyczaj mierzy się w dziesiątkach lub setkach milisekund.

Należy to zmierzyć, zamiast zgadywać. curl raportuje czas połączenia oraz czas otrzymania pierwszego bajta dla rzeczywistego punktu końcowego:

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

Uruchom to polecenie na serwerze testowym przed podjęciem decyzji. Jeśli connect wynosi 0.180 sekundy, serwer znajduje się na niewłaściwym kontynencie i warto to zmienić. Jeśli connect wynosi 0.004 sekundy, a ttfb wynosi 0.140 sekundy, pozostałe opóźnienie wynika z przetwarzania po stronie brokera i żadna zmiana hosta tego nie zmieni.

Kiedy zatem host ma znaczenie? Gdy korzystasz z kolokacji lub bezpośredniego połączenia z giełdą i rywalizujesz o pozycję w kolejce, co jest inną działalnością o innym budżecie. Ma to znaczenie również wtedy, gdy wąskim gardłem jest własny kod: bot, który przy każdym ticku przelicza wskaźniki dla całej historii, może zużywać 200 milisekund czasu procesora na pętlę. Jest to realne opóźnienie, które można wyeliminować bez ponoszenia kosztów. Przed zakupem szybszego serwera należy przeprowadzić profilowanie pętli.

Wybierając hosta, należy zwrócić uwagę na lokalizację geograficzną, stabilność sieci oraz ilość pamięci RAM, aby mechanizm OOM killer nigdy nie musiał interweniować. Według stanu na lipiec 2026 roku, pojedynczy bot w języku Python, obsługujący kilkaset symboli w pamięci, działa stabilnie przy 2 GB pamięci RAM i 2 vCPU. Pamięć należy zwiększyć, jeśli historia ticków jest przechowywana w lokalnej bazie danych.

Krótka lista kontrolna przed uruchomieniem produkcyjnym

1. systemctl is-enabled tradingbot wyświetla enabled, a usługa pozostaje aktywna po sudo reboot.
2. chronyc tracking wskazuje przesunięcie czasu systemowego mniejsze niż kilka milisekund.
3. Klucz API posiada uprawnienia do handlu, nie posiada uprawnień do wypłat oraz korzysta z listy dozwolonych adresów IP, jeśli giełda oferuje taką funkcjonalność.
4. Zatrzymanie procesu za pomocą sudo systemctl kill -s SIGKILL tradingbot powoduje jego przywrócenie w czasie RestartSec.
5. Monitor aktywności (heartbeat) wysyła powiadomienie w ciągu jednego interwału po celowym zatrzymaniu bota.
6. Logi mają ograniczony rozmiar, a system plików root posiada wolne miejsce w df -h.

Przed użyciem rzeczywistych środków należy uruchomić całość w środowisku testowym (sandbox) giełdy lub w trybie paper trading przez tydzień. Każdy z powyższych punktów zawiedzie przynajmniej raz w ciągu tego tygodnia i właśnie temu służy ten okres testowy.

FAQ

Czy bot transakcyjny wymaga serwera o niskich opóźnieniach lub typu bare metal?

Tylko w przypadku rywalizacji o szybkość egzekucji z innymi zautomatyzowanymi uczestnikami na tej samej giełdzie, co zazwyczaj oznacza kolokację, a nie uniwersalny serwer VPS. W przypadku bota detalicznego czas obiegu żądania zależy głównie od lokalizacji geograficznej oraz czasu przetwarzania po stronie brokera. Należy wybrać serwer znajdujący się blisko punktu końcowego API i przeprowadzić pomiary za pomocą curl oraz mtr przed zakupem droższych rozwiązań.

Ile pamięci RAM i mocy CPU potrzebuje bot transakcyjny?

Większość botów realizujących pojedynczą strategię jest ograniczona przepustowością sieci i pozostaje w stanie bezczynności między zdarzeniami. Według stanu na lipiec 2026 roku, 2 vCPU oraz 2 GB pamięci RAM wystarczają do obsługi bota w języku Python śledzącego kilkaset instrumentów. Pamięć staje się wąskim gardłem w momencie przechowywania historii ticków w procesie lub korzystania z lokalnej bazy danych. Należy monitorować free -h oraz dziennik systemowy pod kątem komunikatów o zakończeniu procesu przez mechanizm OOM, zamiast polegać na domysłach.

Dlaczego API giełdy odrzuca żądania z błędem znacznika czasu?

Zegar serwera uległ rozsynchronizowaniu poza okno czasowe podpisywania żądań, które zazwyczaj wynosi kilka sekund. Należy zainstalować chrony, potwierdzić za pomocą chronyc tracking, że System time wykazuje niewielkie przesunięcie oraz zsynchronizowany status leap, a następnie ustawić czas systemowy na UTC, aby zmiany czasu letniego/zimowego nie powodowały przesunięć. Rotacja kluczy API nie rozwiązuje problemów z zegarem.

Jak zapobiec nieoczekiwanemu wyłączeniu bota w nocy?

Należy uruchomić bota za pomocą systemd z użyciem Restart=always oraz StartLimitIntervalSec=0, aby pętla awaryjna ponawiała próby zamiast trwałego zatrzymania procesu. Następnie należy dodać mechanizm heartbeat, który bot wysyła po zakończeniu każdej udanej pętli. Restart obsługuje proces, natomiast heartbeat wykrywa sytuację, w której proces działa, ale jest zawieszony.

Czy mogę uruchomić bota i monitorowanie na tym samym serwerze VPS?

Jest to możliwe, jednak monitorowanie będzie niewiarygodne w krytycznym momencie, ponieważ awaria wyłączająca bota wyłączy również monitor. Należy utrzymywać system powiadomień na oddzielnej maszynie, najlepiej u innego dostawcy lub w innym regionie, a serwer bota wykorzystywać wyłącznie do jego działania oraz logów.