Solana VPS in Frankfurt, sized for trading workloads
KVM servers in Frankfurt, validator-adjacent and private-networked to the NLN RPC and gRPC fleet — <0.5 ms to every NLN Solana service. Sized for chain-adjacent workloads: trading bots, webhook handlers, indexers. NVMe storage, generous egress, full root with your choice of OS, and a straight upgrade path to pinned-core VDS. From $100/mo.
$ ssh root@185.x.x.xWelcome to Ubuntu 24.04 LTS · vps.pro · fra$ apt install -y nodejs npm && npm i @solana/web3.jsadded 42 packages in 6s$ systemctl enable --now sniper-bot.serviceCreated symlink → /etc/systemd/system/sniper-bot.service$ journalctl -u sniper-bot -fslot 367201442 · processedslot 367201443 · processed# order to running bot, same day
Configure a VPS
The smallest box that runs a real Solana workload.
- ·Own kernel, own IP, full root
- ·Fair-share vCPU and network scheduling
- ·Local NVMe storage, nightly snapshots
- ·Key-only SSH from first boot, any OS
- ·Provisioning: Same-day · most within the hour (EU business hours)
- ·SLO: 99.99% monthly · automatic credits
Not for: Sustained CPU above ~60%; move to VDS before tail latency bites.
The production default for trading bots that wait on the network.
- ·Own kernel, own IP, full root
- ·Fair-share vCPU and network scheduling
- ·Local NVMe storage, nightly snapshots
- ·Key-only SSH from first boot, any OS
- ·Provisioning: Same-day · most within the hour (EU business hours)
- ·SLO: 99.99% monthly · automatic credits
Not for: Hot decode loops at full gRPC volume: that is vds.standard territory.
Headroom for fanout, simulation, and testnet validator work.
- ·Own kernel, own IP, full root
- ·Fair-share vCPU and network scheduling
- ·Local NVMe storage, nightly snapshots
- ·Key-only SSH from first boot, any OS
- ·Provisioning: Same-day · most within the hour (EU business hours)
- ·SLO: 99.99% monthly · automatic credits
Not for: Workloads where consistent tail performance has a direct PnL.
Cross-shopFor $105 less, vds.standard trades 8 shared vCPU for 8 pinned cores.
View vds.standard →A working box for chain-adjacent workloads
A Solana VPS is a regular KVM virtual server bought for one reason: running chain-adjacent workloads (trading bots, webhook handlers, indexers) without babysitting hardware. Ours ship from Frankfurt, validator-adjacent and on a dedicated private VLAN to the NLN RPC, gRPC, and validator fleet — under 0.5 ms to every NLN Solana service — with KVM virtualization, shared vCPU, NVMe storage, 1 Gbps network, and 2 TB of included egress on every tier. Three tiers: vps.starter at $100/mo (4 vCPU, 16 GB, 160 GB NVMe), vps.pro at $190/mo (8 vCPU, 32 GB, 320 GB NVMe), and vps.enterprise at $350/mo (16 vCPU, 64 GB, 640 GB NVMe). These are shared-CPU instances: the hypervisor fairly schedules vCPU time across tenants, which is fine for bursty workloads but means you should not run a mainnet validator or a 24/7 hot loop here. For that, see VDS or bare-metal, where the cores are pinned and steal time is 0.00% by contract.
What you are buying here is a working box, honestly described: KVM with full root, NVMe storage, 2 TB of included egress on every tier, and sizes shaped around how bots and indexers actually consume resources: short CPU bursts between long network waits. No inflated promises stapled to a commodity VM.
And because the workload rarely stays the same size, the exit is part of the product: when monitoring says you've outgrown shared vCPU, the same dashboard moves you to a pinned-core VDS, where the cores are yours alone and steal time is 0.00% by contract.
Shared vCPU, fairly scheduled, with a one-liner to measure steal time yourself and a clear trigger for when to move up.
We don’t publish latency numbers for VPS. Your first-boot checklist benchmarks the box in five minutes; your numbers are the real ones.
The RPC, gRPC, and WebSocket fleet your bot consumes is ours too. Hosting and data on one bill, with an upgrade path to VDS and metal.
What shared vCPU means, and when to leave it
Shared vCPU is the part most hosting pages mumble through, so here it is plainly: your cores are scheduled time on silicon other tenants also use. If a neighbor pegs eight threads, you can lose cycles to context switching and cache pollution. For a bot that idles between slots, this is invisible. For a hot decode loop, it shows up exactly where it hurts: the 99th percentile.
The signal to watch is CPU steal time. Under 1% during peak Solana hours (13:00–17:00 UTC), you are fine on VPS. Consistently above 2–3%, the honest fix is not a bigger VPS. It is VDS, where the cores are pinned and steal time is 0.00% by contract.
# Steal-time check: 5 samples, all cores
mpstat -P ALL 1 5 | awk '/Average/ \
{print "CPU " $2 " steal=" $6}'
# healthy VPS: steal < 2%
# move to VDS: steal > 3% sustainedWe put the upgrade trigger in the docs on purpose. Mis-sold workloads churn; measured ones stay.
Tell us the workload, we’ll tell you the box
Bursts CPU on signals, idles between slots. Network-bound 95% of the time.
The bot spends its life waiting on the wire. 8 shared vCPU covers the duty cycle with room to spare, and the money stays in the strategy.
Step up ifmpstat shows steal > 1% in peak hours, or your loop decodes every transaction.
Hot loop on the gRPC feed, decode everything, race a single thread to the trigger.
Pinned cores keep the decode loop consistent: a tail event during your neighbor's burst is a missed trade.
Step up ifthe race comes down to one thread: 4.3 GHz Ryzen metal beats 3.0 GHz virtualized.
Constant ingestion from Yellowstone into Postgres on the same box. Never idles.
16 pinned cores and NUMA-local RAM let ingest and Postgres share a box without sharing tails. Unix-socket DB writes, zero network hop.
Step up ifyou index more than a couple of programs or keep > 40 GB hot in Postgres.
Receive events, transform, fan out over HTTP. Spiky concurrency, light CPU.
16 vCPU absorbs concurrency spikes; shared vCPU is irrelevant when the work is mostly I/O.
Step up ifconcurrency is modest, same architecture, $160 less.
Your own read-only RPC node, ledger and accounts on separate volumes.
32 pinned cores, 128 GB, and four NVMe namespaces handle a non-voting mirror, virtualized, so you can resize as it grows.
Step up ifthe mirror is permanent: a full 64-core physical box, physical drives, no hypervisor.
Learning the operator workflow: vote, restart, snapshot, monitor.
16 vCPU / 64 GB carries a testnet validator. The point is the runbook practice, not the hardware.
Step up ifyou want the exact I/O behavior you will see on mainnet.
Voting on mainnet. Skipped slots cost stake. Hypervisor jitter is disqualifying.
64 high-frequency EPYC 9575F cores, 256 GB, and dual 3.84 TB NVMe is the field-standard build. The vote pipeline never crosses a hypervisor.
Step up ifyou prefer a dual-socket 64-core layout with the same 256 GB.
Custom Geyser plugin feeding your own downstream: full-chain firehose in, structured data out.
Full-chain Geyser is a sustained-everything workload: real drives for the sink, real cores for the decode, 128 GB to breathe.
Step up ifyou want more RAM headroom for the working set: 192 GB on the EPYC 9555P.
The next validator client: tile architecture, AF_XDP, large memory appetite.
Built for it: 64 high-frequency cores, 256 GB, and a Firedancer-tuned image (governor, IRQ affinity, AF_XDP) on request. Need more RAM? We quote custom builds.
How the fleet is run
- ·VPS pools run fair-share vCPU scheduling with headroom held in reserve
- ·VDS and metal capacity is never shared; pinned capacity is held hot
- ·Spare capacity stays racked and powered, so orders never wait for a host to be carved
- ·AMD EPYC platforms, DDR4 ECC across the fleet
- ·Datacenter-grade storage with redundancy (mdraid1) on virtualized pools
- ·Every metal box burn-in tested before handover: CPU, RAM, drive surface, NIC
- ·VPS: nightly snapshots, restore to a healthy host < 15 min
- ·VDS: live migration off a failing host, target < 8 min
- ·Metal: IPMI / KVM-over-IP always on, hardware MTTR < 4 h in the business window
- ·Committed QoS bandwidth on VDS; 10–100 Gbps dedicated ports on metal
- ·Dedicated private VLAN to the NLN RPC / gRPC / WS fleet included on every VDS and bare-metal server
- ·Fair-share scheduler on shared uplinks; one tenant cannot saturate a host
- ·Full root. No locked kernels, no restricted outbound ports, no inspection
- ·Key-only SSH from first boot; password auth ships disabled
- ·Bring your own ISO: Ubuntu, Debian, Rocky, Arch, NixOS all routine
- ·99.99% monthly rolling, fleet-wide
- ·Credits applied automatically on breach, no ticket required
- ·Only enforcement on your box: outbound SMTP abuse limits
Frequently asked questions
Related products
Step up from VPS when you need guaranteed CPU cores and RAM, no hyperthread sharing.
Full physical machines for validators, MEV pipelines, and 128+ GB RAM workloads.
The endpoint your VPS will spend most of its time hitting. Same provider, one bill.
Streaming layer for sniper bots and MEV searchers running on VPS hardware.
Programmatic Solana wallet creation. Pairs well with VPS-hosted custody and CEX onboarding flows.
Managed Geyser plugin slots on production validators.
From order to running bot, same day
vps.starter $100/mo · vps.pro $190/mo · vps.enterprise $350/mo. Validator-adjacent in Frankfurt on a private VLAN to the NLN RPC, gRPC, and validator fleet. Root SSH same day, most orders within the hour during EU business hours. Full root, your choice of OS.
Custom images, extra IPs, or bespoke regions on committed contracts? An engineer answers, not a quota-carrying rep.
- 01Create an accountEmail and a password. No card required to look around.
- 02Pick tier + paste your SSH keyThe exact specs and prices on this page. No checkout surprises.
- 03Root SSH lands in your inboxKey-only auth, your chosen OS image, ready for the NLN data fleet.