VPS untuk Trading Bot: Apa yang Sebenarnya Penting?

Kebutuhan trading bot dari VPS

VPS untuk trading bot dinilai berdasarkan 4 hal: apakah proses kembali berjalan setelah berhenti, apakah waktu sistem akurat, apakah API (application programming interface) key sulit dicuri, dan apakah Anda mengetahui saat bot berhenti. Kecepatan mentah berada jauh di bawah prioritas tersebut untuk bot ritel, karena bagian yang paling lambat dalam jalur order Anda adalah broker dan jarak ke broker, bukan host yang menjalankan Python.

Ini adalah panduan rekayasa. Tidak ada bagian di sini yang merupakan nasihat keuangan, dan tidak ada strategi yang dibahas.

Ketersediaan adalah disiplin restart, bukan angka pada halaman penjualan

Setiap host di dunia mengiklankan uptime 99.9 persen. Angka itu menjelaskan hypervisor, bukan bot Anda. Bot dapat berhenti karena unhandled exception, websocket yang tidak pernah terhubung kembali, atau OOM (out of memory) killer, sementara server tetap aktif sepanjang waktu. Jadi, pertanyaan yang berguna adalah apa yang terjadi dalam sepuluh detik setelah proses Anda berhenti.

Jalankan bot sebagai service systemd dan biarkan sistem init menangani restart. File unit dapat melakukannya dalam enam baris.

[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 adalah baris yang sering terlewat. Secara default, systemd berhenti mencoba setelah 5 restart dalam 10 detik dan membiarkan unit dalam status failed selamanya. Perilaku ini tentu tidak Anda inginkan pada pukul 03:00. Mengaturnya ke 0 akan menonaktifkan rate limit, sehingga bot yang terus crash-loop tetap mencoba alih-alih berhenti tanpa pesan. RestartSec=10 menghentikan loop tersebut agar tidak membanjiri exchange dengan reconnect.

Periksa file tersebut sebelum mempercayainya, lalu jalankan:

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

enable adalah bagian yang tetap berlaku setelah reboot, dan pembaruan kernel berarti reboot. Untuk mengetahui apakah bot berhenti secara diam-diam, minta systemd menampilkan penghitung restart:

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

NRestarts=0 setelah seminggu menunjukkan bot yang sehat. NRestarts=812 berarti Anda telah trading menggunakan proses yang terus reconnect sepanjang malam. Anatomi lengkap file unit, termasuk timer untuk job terjadwal seperti laporan harian, dibahas dalam menjalankan program sebagai service systemd.

Atur jam ke UTC dan buktikan bahwa jam telah tersinkronisasi

API bursa menandatangani permintaan dengan timestamp dan menolak permintaan yang berada di luar rentang waktu tertentu, sering kali 5 detik atau kurang. Jam yang menyimpang menghasilkan error yang tampak seperti kegagalan autentikasi. Akibatnya, orang dapat mengganti key selama berjam-jam sebelum memeriksa waktu. Pada API bergaya Binance, pesannya bersifat literal: Timestamp for this request was 1000ms ahead of the server's time.

Atur server ke UTC. Zona waktu lokal dapat menyebabkan perubahan daylight saving yang terjadi di tengah sesi perdagangan.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu menyertakan systemd-timesyncd, yaitu klien SNTP (simple network time protocol). Klien ini memadai untuk log, tetapi kurang sesuai untuk kebutuhan yang harus tetap berada dalam selisih beberapa milidetik. Klien ini melakukan polling ke satu server dan tidak terus-menerus mengoreksi jam. Sebagai gantinya, gunakan chrony:

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

Baris yang perlu dibaca dari chronyc tracking adalah System time, misalnya System time : 0.000031415 seconds fast of NTP time. Nilai di bawah beberapa milidetik menunjukkan kondisi yang baik. Jika nilainya Leap status : Not synchronised, chrony belum terhubung ke server, biasanya karena UDP 123 keluar diblokir. Tunggu satu menit, lalu periksa kembali sebelum mengubah aturan firewall.

Jauhkan API key dari lokasi yang Anda salin

Exchange key yang bocor lebih berbahaya daripada SSH key yang bocor karena izin penarikan dapat langsung mengubahnya menjadi uang. Dua kebiasaan mencakup sebagian besar risikonya.

Pertama, jangan pernah memberikan izin penarikan kepada bot key. Jika exchange mendukungnya, batasi key tersebut ke alamat IP server Anda. Ini adalah kontrol tunggal yang membuat key curian hampir tidak berguna.

Kedua, simpan secret di luar direktori kode. Apa pun yang berada di dalam /opt/tradingbot pada akhirnya akan masuk ke repositori git atau arsip cadangan. Simpan secret dalam file yang dimiliki root dan hanya dibaca oleh 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

File tersebut berisi baris KEY=value biasa tanpa tanda kutip dan tanpa export. Mode 640 dengan group bot berarti service user dapat membacanya, sedangkan pengguna lain tidak. Verifikasi dengan sudo -u bot cat /etc/tradingbot/api.env, lalu verifikasi menggunakan pengguna lain. Pemeriksaan kedua harus gagal dengan Permission denied.

Bot itu sendiri tidak boleh berjalan sebagai root atau sebagai pengguna yang Anda gunakan untuk login. Buat system account tanpa shell dan tanpa home directory untuk login:

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

Penjelasan tentang setiap flag tersebut dan sejauh mana ProtectSystem=strict benar-benar berlaku tersedia di menjalankan service sebagai pengguna tanpa hak istimewa. Baseline server lainnya, yaitu SSH key dan firewall, dibahas di sepuluh menit pertama pada VPS baru.

Ketahui saat layanan berhenti sebelum broker Anda mengetahuinya

systemctl status menunjukkan bahwa proses sedang berjalan. Itu tidak berarti bot sedang melakukan apa pun. Proses yang terjebak dalam loop percobaan ulang terhadap websocket yang tidak aktif akan lolos dari semua pemeriksaan yang dapat dilakukan systemd.

Gunakan heartbeat sebagai gantinya. Uptime Kuma memiliki monitor push: monitor ini mengharapkan bot memanggil URL pada jadwal tertentu, lalu mengirimkan peringatan jika panggilan tersebut berhenti diterima. Letakkan panggilan itu di akhir loop utama, setelah bagian yang membuktikan bot masih aktif, misalnya setelah pembacaan data pasar berhasil.

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

Atur interval monitor kira-kira dua kali durasi loop agar jitter normal tidak memicu peringatan. Jalankan monitor pada server yang berbeda dari bot, karena monitor yang berhenti bersama layanan yang dipantaunya tidak akan melaporkan apa pun. Konfigurasinya dibahas dalam pemantauan status yang di-host sendiri dengan Uptime Kuma.

Tambahkan juga peringatan disk. Bot yang menulis log secara mendetail dapat memenuhi filesystem root dalam hitungan minggu. Disk yang penuh akan menghentikan penulisan database, bukan panggilan jaringan, sehingga gejalanya dapat membingungkan. journalctl --vacuum-time=14d dan baris SystemMaxUse= dalam /etc/systemd/journald.conf menjaga ukuran journal tetap terbatas.

Bagian yang sebenarnya: latensi sebagian besar bukan disebabkan oleh host

Di sinilah pasar produk trading VPS berhenti bersifat teknis. Halaman pemasaran mencantumkan angka submilidetik dan memberi kesan bahwa host menjadi penghambat antara Anda dan eksekusi order. Untuk hampir semua bot ritel, anggapan itu tidak benar.

Order Anda bergerak dari bot ke endpoint exchange atau broker melalui Internet publik. Jalur tersebut terutama dipengaruhi oleh jarak fisik dan peering antara provider Anda dan provider mereka. Server di Frankfurt yang berkomunikasi dengan endpoint di Tokyo memerlukan waktu pulang-pergi sekitar 250 milidetik, secepat apa pun CPU-nya. Setelah itu, sistem broker menambahkan waktu untuk antrean, pemeriksaan risiko, dan pembatasan laju. Untuk akun ritel, proses ini biasanya berlangsung selama puluhan atau ratusan milidetik.

Lakukan pengukuran, bukan perkiraan. curl melaporkan waktu koneksi dan waktu hingga byte pertama untuk endpoint nyata:

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

Jalankan perintah tersebut dari server kandidat sebelum Anda memilihnya. Jika connect bernilai 0.180 detik, server berada di benua yang salah, dan hal itu perlu diperbaiki. Jika connect bernilai 0.004 detik dan ttfb bernilai 0.140 detik, sisa latensi berasal dari pemrosesan broker, sehingga perubahan host tidak akan menguranginya.

Jadi, kapan host berpengaruh? Saat Anda menggunakan colocated atau cross-connected ke venue dan bersaing berdasarkan posisi dalam antrean. Itu merupakan bisnis yang berbeda dengan anggaran yang berbeda. Host juga berpengaruh saat kode Anda sendiri menjadi bottleneck. Bot yang menghitung ulang indikator berdasarkan seluruh histori pada setiap tick dapat menggunakan CPU selama 200 milidetik per loop. Itu adalah latensi nyata yang dapat Anda kendalikan tanpa biaya tambahan. Lakukan profiling pada loop sebelum mencari server yang lebih cepat.

Faktor yang penting dalam memilih host adalah lokasi geografis, jaringan yang stabil, dan memori yang cukup agar OOM killer tidak pernah perlu menghentikan proses. Per Juli 2026, bot Python dengan satu strategi dan beberapa ratus simbol dalam memori dapat berjalan dengan baik pada 2 GB RAM dan 2 vCPU. Tambahkan memori jika Anda menyimpan histori tick dalam database lokal.

Daftar periksa singkat sebelum produksi

1. systemctl is-enabled tradingbot menampilkan enabled, dan service tetap berjalan setelah sudo reboot.
2. chronyc tracking melaporkan selisih waktu sistem kurang dari beberapa milidetik.
3. API key memiliki izin trading, tidak memiliki izin penarikan dana, dan menggunakan daftar izin IP jika exchange menyediakannya.
4. Menghentikan proses dengan sudo systemctl kill -s SIGKILL tradingbot membuatnya berjalan kembali dalam waktu RestartSec.
5. Monitor heartbeat mengirimkan alert kepada Anda dalam satu interval setelah Anda sengaja menghentikan bot.
6. Ukuran log dibatasi, dan filesystem root memiliki ruang yang cukup di df -h.

Jalankan seluruh sistem di sandbox exchange atau dalam mode paper selama seminggu sebelum menggunakan dana nyata. Setiap item di atas akan gagal setidaknya sekali selama minggu tersebut. Itulah tujuan pengujian selama seminggu.

FAQ

Apakah trading bot memerlukan server latensi rendah atau bare metal?

Hanya jika Anda bersaing dalam kecepatan eksekusi dengan peserta otomatis lain di venue yang sama. Dalam kondisi tersebut, colocation biasanya lebih sesuai daripada VPS untuk keperluan umum. Untuk bot ritel, round trip lebih banyak dipengaruhi oleh lokasi geografis dan pemrosesan di pihak broker. Pilih server yang dekat dengan endpoint API, lalu ukur menggunakan curl dan mtr sebelum membayar layanan yang lebih cepat.

Berapa kebutuhan RAM dan CPU trading bot?

Sebagian besar bot dengan satu strategi bergantung pada jaringan dan idle di antara event. Per Juli 2026, 2 vCPU dan 2 GB RAM cukup untuk menjalankan bot Python yang memantau beberapa ratus instrumen. Memori menjadi kendala jika Anda menyimpan riwayat tick di dalam proses atau menjalankan database lokal. Karena itu, pantau free -h dan journal untuk mencari pesan OOM kill, bukan memperkirakannya.

Mengapa exchange menolak permintaan API saya dengan error timestamp?

Jam server telah menyimpang melewati jendela penandatanganan exchange, biasanya beberapa detik. Instal chrony. Pastikan chronyc tracking menunjukkan offset System time yang kecil dan status leap yang tersinkronisasi. Atur mesin ke UTC agar perubahan daylight saving tidak pernah menggeser waktu tersebut. Mengganti API key tidak memperbaiki masalah jam.

Bagaimana cara menghentikan bot agar tidak mati semalaman tanpa saya ketahui?

Jalankan bot di bawah systemd dengan Restart=always dan StartLimitIntervalSec=0 agar crash loop terus dicoba ulang, bukan berhenti secara permanen. Tambahkan heartbeat yang dikirim bot pada akhir setiap loop yang berhasil. Restart menangani proses yang berhenti. Heartbeat mendeteksi kondisi ketika proses masih hidup, tetapi macet.

Dapatkah saya menjalankan bot dan monitoring pada VPS yang sama?

Bisa, tetapi monitoring akan memberikan informasi yang menyesatkan saat paling dibutuhkan. Outage yang menghentikan bot juga akan menghentikan monitoring. Tempatkan sistem alerting pada mesin terpisah, idealnya pada provider atau region yang berbeda. Gunakan server bot hanya untuk bot dan log-nya.