Jak uruchomić bota handlowego 24/7 na VPS

Napisane przez zespół ApexVPS • Ostatnia aktualizacja: lipiec 2026 • 8 min czytania

Automatyczne strategie muszą reagować na rynek, niezależnie od tego, czy śpisz. Aby uruchomić bota handlowego na VPS 24/7 to standardowy sposób na utrzymanie go online: wirtualny serwer prywatny pozostaje włączony, podłączony i fizycznie blisko giełdy przez całą dobę, dzięki czemu Twój bot nigdy nie przegapi sygnału, ponieważ laptop przeszedł w tryb uśpienia lub domowe połączenie zostało przerwane. Ten przewodnik wyjaśnia, dlaczego VPS przewyższa domowy komputer, jak wybrać lokalizację, jak utrzymać proces przy życiu i jak kontrolować swoje klucze i logi. Jest to tylko wskazówka techniczna, a nie porada finansowa, i pozostaje neutralny co do frameworka bota lub strategii, której używasz.

Dlaczego VPS przewyższa domowy komputer dla botów

Bot handlowy to długo działający proces, który nie może się zatrzymać w najmniej odpowiednim momencie. Domowy komputer jest złym gospodarzem z trzech praktycznych powodów.

Czas działania i zawsze włączone wykonanie

Domowe maszyny przechodzą w tryb uśpienia, instalują aktualizacje i uruchamiają się ponownie według własnego harmonogramu. Przerwy w dostawie prądu i restarty routerów dodają kolejne luki. VPS działa w centrum danych z redundantnym zasilaniem i siecią oraz opublikowanym celem dostępności — plany ApexVPS mają SLA od 99,9% do 99,99% w zależności od poziomu — więc proces, który składa i zarządza Twoimi zleceniami, działa dalej, gdy śpisz, podróżujesz lub pracujesz.

Opóźnienie do Twojej giełdy

Każde zlecenie i aktualizacja danych rynkowych podróżuje ścieżką sieciową między Twoim serwerem a giełdą. Im krótsza ta ścieżka, tym szybciej Twój bot widzi wykonania i reaguje. Połączenie domowe najpierw przechodzi przez Twojego dostawcę usług internetowych; dobrze ulokowany serwer znajduje się na szybkich łączach szkieletowych. ApexVPS prowadzi 39 centrów danych z siecią o niskim opóźnieniu w głównych regionach, co skraca czas rundy dla routowania zleceń i aktualizacji kwotowań.

Bez przerw

Na VPS-ie sam kontrolujesz, kiedy odbywa się konserwacja. Nie ma wymuszonych aktualizacji systemu w trakcie sesji, skanów antywirusowych obciążających procesor ani członka rodziny zamykającego pokrywę laptopa. Bot ma stabilne, dedykowane środowisko, które zmienia się tylko wtedy, gdy Ty je zmienisz.

Wybierz lokalizację blisko swojej giełdy

Na opóźnienie dominuje odległość fizyczna, więc największą dźwignią jest wybór centrum danych blisko miejsca, gdzie hostowana jest Twoja giełda lub broker. Wiele platform kryptowalutowych prowadzi swoje silniki dopasowujące w lub w pobliżu kilku hubów, a giełdy akcji i kontraktów skupiają się wokół konkretnych metropolii. Z reguły dopasuj region serwera do giełdy:

• Giełdy zorientowane na Europę: Frankfurt, Londyn lub Amsterdam.
• Rynki amerykańskie: Nowy Jork, Miami lub Los Angeles.
• Azja-Pacyfik: Tokio, Singapur lub Sydney.

Jeśli nie jesteś pewien, przetestuj czas rundy prostym poleceniem ping lub mtr do hosta API giełdy z kilku kandydackich regionów i wybierz najniższy. Nasze dedykowane strony o VPS-ie stworzonym dla botów handlowych i przyjaznym dla kryptowalut VPS-ie z płatnością bez karty szczegółowo wymieniają dostępne regiony.

Utrzymuj bota przy życiu 24/7

Uruchomienie bota w zwykłej sesji SSH nie wystarczy — gdy sesja się zamknie, proces umiera. Użyj jednej z poniższych metod, aby utrzymać go przy życiu i automatycznie restartować po awarii lub ponownym uruchomieniu.

tmux lub screen (szybki start)

Multiplekser terminala utrzymuje proces działający po rozłączeniu. To najszybszy sposób na rozpoczęcie, gdy testujesz:

sudo apt update && sudo apt install -y tmux
tmux new -s bot
# start your bot inside the session, e.g.
python3 main.py
# detach without stopping it: press Ctrl-b, then d
# reattach later:
tmux attach -t bot

tmux świetnie nadaje się do testów interaktywnych, ale nie restartuje awarii bota samodzielnie. Do czegokolwiek, co zostawiasz działające, przejdź do menedżera procesów poniżej.

systemd (zalecany na Linuksie)

systemd jest wbudowany w nowoczesny Ubuntu i Debian i ponownie uruchomi bota po awarii oraz wystartuje go podczas bootowania. Utwórz plik jednostki:

# /etc/systemd/system/tradingbot.service
[Unit]
Description=Trading Bot
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=botuser
WorkingDirectory=/home/botuser/bot
ExecStart=/usr/bin/python3 /home/botuser/bot/main.py
Restart=always
RestartSec=5
EnvironmentFile=/home/botuser/bot/.env

[Install]
WantedBy=multi-user.target

Następnie włącz i uruchom:

sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
sudo systemctl status tradingbot

Restart=always przywraca bota po awarii, a enable sprawia, że startuje automatycznie po każdym ponownym uruchomieniu.

pm2 dla botów Node.js

Jeśli Twój bot jest napisany w JavaScript lub TypeScript, pm2 to prosty menedżer procesów z wbudowanymi logami i restartem po restarcie:

npm install -g pm2
pm2 start bot.js --name trading-bot
pm2 save
pm2 startup   # run the command it prints, then reboot to verify

Docker dla powtarzalnych wdrożeń

Kontenery pakują Twojego bota z jego dokładnymi zależnościami, więc działa tak samo wszędzie. Polityka --restart obsługuje awarie i restarty:

docker run -d --name trading-bot \
  --restart unless-stopped \
  --env-file /home/botuser/bot/.env \
  my-bot:latest

Kontenery ułatwiają również aktualizacje i wycofywanie zmian; oficjalna dokumentacja Docker szczegółowo omawia budowanie obrazów i zarządzanie politykami restartu.

Rotuj i zarządzaj logami

Bot działający przez tygodnie może wypełnić dysk danymi z logów i ostatecznie zawiesić cały serwer. Rotuj logi, aby stare pliki były automatycznie kompresowane i czyszczone. Na Ubuntu i Debianie logrotate jest już zainstalowane — dodaj regułę dla swojego bota:

# /etc/logrotate.d/tradingbot
/home/botuser/bot/logs/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    copytruncate
}

Jeśli używasz systemd, dziennik (journal) już przechwytuje wyjście; ogranicz jego rozmiar w /etc/systemd/journald.conf za pomocą ustawienia takiego jak SystemMaxUse=500M. W obu przypadkach regularnie przeglądaj logi i alertuj o błędach, aby cicha awaria nie pozostała niezauważona przez dni.

Zabezpiecz bota i swoje klucze API

Twój VPS przechowuje poświadczenia, które mogą przesuwać pieniądze, więc traktuj bezpieczeństwo jako część konfiguracji, a nie dodatek. Zasada najmniejszych uprawnień OWASP odnosi się tutaj bezpośrednio.

• Zawęź uprawnienia kluczy do giełdy. Utwórz klucze API tylko z uprawnieniami potrzebnymi strategii. Całkowicie wyłącz możliwość wypłat, a jeśli giełda to obsługuje, przypisz klucz do adresu IP swojego serwera.
• Nigdy nie wpisuj sekretów na sztywno. Przechowuj klucze w pliku środowiskowym ładowanym w czasie działania, nie w kontroli wersji. Ogranicz dostęp do niego tylko dla użytkownika bota: chmod 600 /home/botuser/bot/.env.
• Uruchamiaj jako użytkownik inny niż root. Utwórz dedykowane konto dla bota, aby zainfekowany proces nie mógł przejąć całego serwera.
• Wzmocnij SSH. Loguj się za pomocą kluczy SSH, wyłącz logowanie hasłem i utrzymuj system w aktualności dzięki sudo apt update && sudo apt upgrade.
• Zamknij nieużywane porty. Prosta zapora ogniowa zmniejsza powierzchnię ataku:

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

ApexVPS daje Ci pełny dostęp root, ochronę DDoS i opcjonalną sieć prywatną, więc możesz wdrożyć te zabezpieczenia bez walki z platformą.

Dobierz zasoby VPS do swoich potrzeb

Boty zwykle nie obciążają CPU, ale są wrażliwe na jego niedobór w krytycznym momencie, co jest typowe dla wspólnego hostingu o przedatkowaniu sprzedaży (overselling). Ponieważ zasoby ApexVPS są w pełni dedykowane — bez oversellingu, bez hałaśliwych sąsiadów — kupując rdzenie, otrzymujesz dokładnie te rdzenie. Orientacyjnie:

• Jeden bot, kilka rynków: plan Starter Pro (2 dedykowane vCPU, 4 GB RAM, 80 GB NVMe SSD) jest wystarczający.
• Kilka strategii lub backtesting: plan Business (4 vCPU, 8 GB RAM, 160 GB NVMe, 1 dedykowany IPv4) dodaje zapas mocy i adres IP, który możesz dodać do białej listy na giełdzie.
• Zestaw botów z siecią prywatną: plan Enterprise (8 vCPU, 16 GB RAM, NVMe RAID, 2 dedykowane IPv4) sprawdzi się w bardziej rozbudowanych konfiguracjach.

Obserwuj htop i opóźnienia (latency) przez tydzień po uruchomieniu i skaluj tylko w przypadku realnych ograniczeń. Porównaj specyfikacje na naszej stronie planów i cen VPS.

Pierwsze kroki

Konfiguracja jest szybka: wybierz plan, zlokalizowany w pobliżu giełdy region i podaj adres e-mail — bez imienia, adresu czy KYC. Płatność tylko w kryptowalutach przez OxaPay — akceptujemy Bitcoin, Ethereum, USDT i 30+ innych kryptowalut, bez potrzeby karty kredytowej czy konta bankowego. Po potwierdzeniu płatności w sieci, serwer jest automatycznie wdrażany i otrzymujesz pełny dostęp root, aby zainstalować bota, dodać usługę systemd i wystartować.

Często zadawane pytania

Dlaczego uruchamiać bota na VPS zamiast na komputerze domowym?

VPS pozostaje włączony i połączony całą dobę w centrum danych z redundantnym zasilaniem i siecią. W przeciwieństwie do komputera domowego, nie ma na niego wpływu tryb uśpienia, wymuszone restarty systemu, awarie zasilania czy dostawca internetu zrywający połączenie, więc bot działa bez przerw.

Jak utrzymać bota przy życiu, jeśli się zawiesi lub serwer zostanie zrestartowany?

Użyj menedżera procesów zamiast terminala. Usługa systemd z Restart=always ponownie uruchamia bota po awarii i startuje po restarcie. Użytkownicy Node.js mogą użyć pm2 z pm2 startup, a użytkownicy Docker — --restart unless-stopped dla podobnego efektu.

Ile CPU i RAM potrzebuje bot handlowy?

Pojedynczy bot odpytywający kilka rynków jest mało wymagający — 2 dedykowane vCPU i 4 GB RAM wystarczą. Uruchomienie kilku strategii, wskaźników lub backtestów jednocześnie korzysta z 4 vCPU i 8 GB lub więcej. Ponieważ zasoby są dedykowane, otrzymujesz pełną moc obliczeniową bez spowolnień ze strony sąsiadów.

Jak zabezpieczyć klucze API giełdy?

Utwórz klucze z minimalnymi uprawnieniami, jakich potrzebuje strategia, wyłącz możliwość wypłat i dodaj listę dozwolonych IP powiązaną z adresem serwera. Przechowuj klucze w pliku środowiskowym czytelnym tylko dla użytkownika bota, nigdy nie na twardo w kodzie źródłowym, i loguj się przez klucze SSH zamiast haseł.