VPS untuk Bot Trading: Faktor yang Benar-Benar Penting

Hal yang dibutuhkan bot trading dari VPS

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

Panduan ini membahas aspek teknis. Tidak ada bagian di sini yang merupakan nasihat keuangan, dan tidak ada strategi yang dibahas.

Uptime adalah disiplin restart, bukan angka di 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 layanan systemd dan biarkan sistem init menangani restart. Unit file 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 persis seperti yang tidak Anda inginkan pada pukul 03:00. Mengaturnya ke 0 akan menonaktifkan batas laju, sehingga bot yang terus mengalami crash-loop tetap mencoba, bukan menjadi diam. RestartSec=10 menghentikan loop tersebut agar tidak membebani 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 membuatnya tetap aktif setelah reboot, dan pembaruan kernel berarti reboot. Untuk mengetahui apakah bot diam-diam terus berhenti, 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 melakukan trading dengan proses yang terhubung kembali sepanjang malam. Anatomi unit file lengkap, termasuk timer untuk tugas terjadwal seperti laporan harian, dibahas dalam menjalankan program sebagai layanan systemd.

Atur jam ke UTC dan buktikan bahwa jam telah disinkronkan

API bursa menandatangani permintaan dengan stempel waktu dan menolak permintaan di luar jendela waktu, yang sering kali 5 detik atau kurang. Jam yang menyimpang menghasilkan galat yang terlihat seperti kegagalan autentikasi, sehingga orang mengganti kunci 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 waktu musim panas 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 andal untuk kebutuhan yang harus tetap berada dalam rentang beberapa milidetik karena hanya melakukan polling ke satu server dan tidak terus-menerus mengatur jam. Gunakan chrony sebagai gantinya:

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

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

Jangan menyimpan kunci API di lokasi yang Anda salin

Kunci exchange yang bocor lebih berbahaya daripada kunci SSH yang bocor karena izin penarikan dapat langsung digunakan untuk mengambil dana. Dua kebiasaan mencakup sebagian besar risikonya.

Pertama, jangan pernah memberikan izin penarikan kepada kunci bot. Jika exchange mendukungnya, batasi kunci tersebut ke alamat IP server Anda. Ini adalah kontrol tunggal yang membuat kunci 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 grup bot memungkinkan pengguna layanan membacanya, tetapi mencegah pengguna lain membacanya. Verifikasi dengan sudo -u bot cat /etc/tradingbot/api.env, lalu verifikasi menggunakan pengguna lain. Perintah tersebut harus gagal dengan Permission denied.

Bot itu sendiri tidak boleh berjalan sebagai root atau sebagai pengguna yang Anda gunakan untuk login. Buat akun sistem tanpa shell dan tanpa direktori home untuk login:

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

Penjelasan tentang setiap flag tersebut dan batas penerapan ProtectSystem=strict tersedia di menjalankan layanan sebagai pengguna tanpa hak istimewa. Baseline server lainnya, termasuk kunci SSH dan firewall, dibahas di sepuluh menit pertama pada VPS baru.

Ketahui bahwa layanan berhenti sebelum broker Anda mengetahuinya

systemctl status menunjukkan bahwa proses sedang berjalan. Namun, ini tidak menunjukkan bahwa bot melakukan sesuatu. Proses yang macet dalam loop percobaan ulang terhadap websocket yang tidak aktif akan lolos dari semua pemeriksaan yang dapat dilakukan systemd.

Sebagai gantinya, gunakan heartbeat. Uptime Kuma memiliki monitor push: monitor ini mengharapkan bot memanggil URL sesuai jadwal dan mengirimkan peringatan ketika panggilan tersebut berhenti diterima. Letakkan panggilan itu di akhir loop utama, setelah bagian yang membuktikan bahwa bot masih aktif, seperti pembacaan data pasar yang berhasil.

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

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

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

Bagian yang jujur: latensi sebagian besar bukan berasal dari server Anda

Di sinilah pasar produk VPS untuk trading berhenti bersifat teknis. Halaman pemasaran mencantumkan angka di bawah satu milidetik dan menyiratkan bahwa server adalah faktor yang menentukan apakah Anda mendapatkan eksekusi order. Untuk hampir semua bot ritel, itu tidak benar.

Order Anda berjalan dari bot ke endpoint bursa atau broker melalui internet publik. Jalur tersebut terutama dipengaruhi oleh jarak fisik dan hubungan peering antara penyedia Anda dan penyedia 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 antrean, pemeriksaan risiko, dan batas laju mereka sendiri. Untuk akun ritel, proses ini biasanya berlangsung dalam puluhan atau ratusan milidetik.

Lakukan pengukuran, bukan perkiraan. curl melaporkan waktu koneksi dan waktu 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 adalah 0.180 detik, server berada di benua yang salah, dan hal itu perlu diperbaiki. Jika connect adalah 0.004 detik dan ttfb adalah 0.140 detik, sisa latensi berasal dari pemrosesan broker, dan mengganti server tidak akan menguranginya.

Kapan server berpengaruh? Saat Anda menggunakan colocation atau cross-connection ke venue dan bersaing untuk mendapatkan posisi dalam antrean. Itu adalah bisnis yang berbeda dengan anggaran yang berbeda. Server juga berpengaruh saat kode Anda sendiri menjadi hambatan. Bot yang menghitung ulang indikator berdasarkan seluruh riwayat pada setiap tick dapat menggunakan CPU selama 200 milidetik pada setiap loop. Itu adalah latensi nyata yang dapat Anda kendalikan tanpa biaya. Lakukan profiling pada loop sebelum mencari server yang lebih cepat.

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

Daftar periksa singkat sebelum masuk produksi

1. systemctl is-enabled tradingbot mencetak enabled, dan layanan 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, dan menggunakan daftar IP yang diizinkan jika exchange menyediakannya.
4. Menghentikan proses dengan sudo systemctl kill -s SIGKILL tradingbot membuatnya berjalan kembali dalam waktu RestartSec.
5. Monitor heartbeat mengirimkan halaman kepada Anda dalam satu interval setelah Anda sengaja menghentikan bot.
6. Ukuran log dibatasi, dan sistem berkas root memiliki ruang kosong yang cukup di df -h.

Jalankan seluruh sistem dalam 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 bot trading memerlukan server dengan 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 serbaguna. Untuk bot ritel, waktu pulang-pergi terutama dipengaruhi oleh lokasi geografis dan pemrosesan broker. Karena itu, pilih server yang dekat dengan endpoint API, lalu ukur menggunakan curl dan mtr sebelum membayar layanan yang lebih cepat.

Berapa RAM dan CPU yang diperlukan bot trading?

Sebagian besar bot dengan satu strategi bergantung pada jaringan dan tidak aktif di antara kejadian. Hingga 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 API saya menolak permintaan dengan kesalahan timestamp?

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

Bagaimana cara mencegah bot berhenti pada malam hari tanpa saya ketahui?

Jalankan bot dengan systemd menggunakan Restart=always dan StartLimitIntervalSec=0 agar loop kerusakan terus mencoba kembali, bukan berhenti secara permanen. Kemudian, tambahkan heartbeat yang dikirim bot pada akhir setiap loop yang berhasil. Restart menangani prosesnya. Heartbeat mendeteksi kondisi ketika proses masih aktif, tetapi macet.

Dapatkah saya menjalankan bot dan pemantauan di VPS yang sama?

Anda dapat melakukannya, tetapi pemantauan akan memberikan informasi yang keliru saat paling dibutuhkan. Penyebabnya, gangguan yang menghentikan bot juga akan menghentikan pemantauan. Simpan sistem peringatan di mesin terpisah, idealnya pada provider atau region yang berbeda, dan gunakan server bot hanya untuk bot serta log-nya.