Solana VPS in Frankfurt, private-networked to the validators

A VPS is a virtual private server: a slice of a physical hypervisor running its own kernel under KVM, with its own IP, root access, and a quota of CPU, memory, and disk. Hetzner sells one for 4 euros a month. So why does “Solana VPS” exist as a category?

Because Solana cares about latency at a level most workloads don't. The slot time is 400ms. A trade decision that takes longer than 50ms to round-trip from your bot to an RPC and back is already uncompetitive. Network distance matters more than raw CPU. A 4-core VPS one rack away from a Jito builder will out-trade a 64-core box sitting in Falkenstein, every time, because the four-core box gets the data first.

So a Solana VPS is a regular VPS with one extra constraint: it has to be in the same room as the Solana validators, and it has to be on a private network to the RPC and gRPC providers you plan to talk to. Our VPS pool runs in Frankfurt, private-networked directly to NLN validator nodes. Spin up a vps.starter, ping rpc.nln.clr3.org, you should see 0.2ms median. That's the floor. Anything below that is the speed of light over a few meters of fiber.

Our VPS pool runs on AMD EPYC hosts with DDR5 ECC, dual NVMe in mdraid1, and 25 Gbps host NICs. Each host carries multiple VPS tenants. We don't oversubscribe vCPU above 1.5x and we publish the ratio per region.

That's the part people forget. The vCPU you buy is a slice. If a noisy neighbor on the same host pegs eight threads at 100%, your bot loses some cycles even on a fair-share scheduler. For most Solana workloads this is fine: the bot is mostly waiting on slots, the indexer is mostly waiting on disk, the webhook is mostly waiting on HTTP. But if your code runs hot, vCPU contention is the failure mode you watch for. The cure is to move up to VDS, where the cores are pinned and yours alone.

NVMe storage is local, not networked. No Ceph, no distributed block store. The tradeoff: if a host fails, we restore your VPS from the most recent nightly snapshot to a different host. Recovery time is typically under 15 minutes. If you need synchronous replication, build it at the application layer or move to bare-metal with two drives.

Network varies by tier: vps.starter gets 1 Gbps with 5 TB egress, vps.pro gets 2.5 Gbps with 10 TB egress, vps.enterprise gets 5 Gbps with no transfer cap. All tiers share a fair-share scheduler on the host uplink.

We sell three host tiers and they exist because the workloads break differently. Don't guess. Walk the tree:

Quick flow: Does your workload need 128+ GB RAM? Yes → bare-metal. Does it run at >60% CPU sustained? Yes → VDS. Does it mostly wait for network events? Yes → VPS. Otherwise → start on VPS and upgrade when monitoring shows the signal.

The thing nobody publishes a number for: where your packets actually go. From a VPS in our Frankfurt pool, traffic to rpc.nln.clr3.org stays inside the building. Median RTT 0.21ms, 99th percentile under 0.4ms.

Why this matters for Solana: a block lasts 400ms. The portion where you can still react to a swap before someone else front-runs you is maybe 100ms. Spending 14ms of that budget on round-trip latency to your data source is throwing away a seventh of your reaction window. Spending 0.2ms is throwing away nothing.

The other piece is jitter. Public-internet RTT distributions have long tails. Inside our building, the 99th percentile is 0.4ms with a median of 0.21ms — a 2x tail. For anything risk-managed, the tail is what kills you.

Three providers come up every time someone asks about Solana hosting on Reddit.

Hetzner is genuinely cheaper. If your workload is latency-insensitive, run there. If you're doing anything trade-adjacent, that 14ms is the difference between a green PnL and a red one. Latitude.sh is the closest direct competitor, similar rooms, but they don't run their own RPC fleet — you pay them for hosting and a separate provider for data. We bundle both.

Get a quote on the pricing page, or talk to sales if you want a configuration that isn't on the menu.

From sign-up to a running bot in under five minutes. This assumes a vps.pro (8 vCPU, 32 GB, $190/mo) with Ubuntu 24.04.

1. Provision. Use the API or dashboard. The VPS boots in 60-90 seconds. You get an IP and a private VLAN address (10.x.x.x) for our RPC and gRPC.

   curl -X POST https://api.nolimitnodes.com/v1/vps \
     -H "Authorization: Bearer $NLN_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"tier":"vps.pro","region":"fra","image":"ubuntu-24.04","ssh_keys":["ssh-ed25519 AAAAC3..."]}'

2. SSH in and verify latency. Ping the private RPC endpoint. You should see under 0.3ms.

   ssh root@185.x.x.x
   ping -c 5 rpc.nln.clr3.org
   # 0.21ms median ✓

3. Install dependencies. For a Node.js bot:

   apt update && apt install -y nodejs npm
   npm install @solana/web3.js @triton-one/yellowstone-grpc

4. Configure the private RPC. Set environment variables to use the private VLAN endpoint, not the public DNS. This is where the 0.2ms latency comes from.

   export NLN_PRIVATE_RPC=https://rpc.nln.clr3.org
   export NLN_PRIVATE_GRPC=grpc.nln.clr3.org:443

5. Deploy with systemd. Drop a unit file into /etc/systemd/system/, enable it, and the bot starts on boot with automatic restarts. See the systemd code sample above for the full template.
6. Monitor. journalctl -u sniper-bot -f for logs. mpstat -P ALL 1 5 for CPU steal time. If steal stays above 1% during peak hours, it's time to move to VDS.