Professional Drift Trading Stack

Overview

Yes — you can build a professional Drift trading stack with your own Solana RPC + your own DLOB, but you’ll want a few supporting services around them. The main rule: keep the RPC box lean, put “trading services” on your second VPS.

On the Solana RPC server (dedicated) — keep it lean

Must-have

• Solana validator/RPC node
  The base RPC your whole stack reads from / sends transactions through.
• WireGuard
  So RPC is reachable only privately (your second VPS + your admin).
• Firewall (nftables/ufw)
  Block RPC ports on public NIC; allow them only on WireGuard.
• Time sync (chrony)
  For stable networking, logs, and trading timestamps.
• Monitoring exporters
  • node_exporter (CPU/RAM/disk/iowait/network)
  • solana-exporter (RPC/validator health via RPC)
• Log + disk hygiene
  • logrotate/journald limits
  • NVMe health (smartmontools/nvme-cli)
  • alerts on disk filling / iowait

Optional but “pro”

• Geyser streaming (Yellowstone gRPC plugin)
  This gives ultra-low-latency streams of accounts/tx/slots compared to polling RPC. Useful if you build your own real-time analytics pipeline.
  For Drift specifically, you can run without Geyser at the beginning, but it’s the next step when you want “faster-than-RPC” feeds.

On the second VPS (your trading / app box) — where “pro trading” lives

Must-have

• Drift DLOB server (self-hosted)
  This maintains the Drift decentralized orderbook view “fresh off your RPC” and exposes REST + WS + gRPC/polling, plus health/metrics.
• (Optional but common) Drift Gateway
  A self-hosted API gateway to interact with Drift; handy for standardized API endpoints around trading / market info.
• Cache (Redis)
  Cache top-of-book, funding, oracle snapshots, risk checks; protects your DLOB + RPC from bursty bot load.
• Metrics + dashboards
  Prometheus + Grafana + Alertmanager
  Keep Grafana off the validator box; common ops guidance is to separate monitoring UI for safety.
• Your trading services
  • strategy engine(s)
  • execution service (transaction builder/sender)
  • risk service (position limits, kill-switch, circuit breakers)

Optional, depending on how “institutional” you want

• Database (Postgres/Timescale)
  Persist fills, order events, PnL series, backtesting datasets.
• Message bus (NATS/Kafka/Redis Streams)
  Decouple ingestion (orderbook/events) from strategies/execution.

Cost model (since you asked “cost per request”)

With your own RPC, there is no per-request billing. The “cost” is:

• fixed monthly servers (your €149/m + the second VPS),
• and capacity (CPU/RAM/NVMe/bandwidth) consumed by:
  • DLOB syncing from RPC,
  • number of WS subscriptions,
  • how many markets you track.

DLOB exists specifically to reduce RPC load by serving orderbook/trade views to clients instead of every client rebuilding it from chain.

Minimal “pro” starting set (recommended)

• RPC box: Solana RPC + WireGuard + firewall + node_exporter + solana-exporter
• App VPS: DLOB server + Redis + Prometheus/Grafana + your bot services

For min 10 markets, expect the first scaling pressure to come from continuous streaming + decoding + caching (DLOB + Redis + your strategy/execution), and from your RPC’s WS load. Next step after the minimal set is usually: better streaming (Geyser) or more RAM/NVMe depending on bottleneck.