Professional Drift Trading Stack (Own Solana RPC + Own DLOB + Vast ML)

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.

On the third box (Vast GPU) — model / research plane

What lives here

Training (Transformer / ML)
Train on datasets exported from your VPS (orderbook stats, trades, features).
(Optional) Inference endpoint
Serve model decisions back to VPS. The VPS still owns execution.

Security rule: Vast should never hold private keys nor get access to your funds. Treat it as a “signal generator”; execution and signing must remain on the VPS.

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.