Solana RPC Server: Endpoints, Config & Scaling

A Solana RPC server is the service your application talks to when it needs to read blockchain state or submit a transaction. Instead of running a validator or an RPC node yourself, you point your client at an HTTP endpoint (and usually a WebSocket endpoint) that speaks Solana's JSON-RPC dialect. Everything from a wallet balance check to a token swap starts with a request to that server.

This page is written for developers who already know they need a Solana RPC server and want to connect one correctly, then decide whether a shared endpoint is enough or whether a dedicated node is the better fit. If you are still comparing providers at a high level, start with how to choose an RPC provider and come back here for the Solana-specific configuration.

Choosing between public, managed, and dedicated Solana RPC

The fastest way to decide is to match your workload to the endpoint type. Most teams start on a public or shared endpoint, then move up when they hit a specific limit rather than a vague feeling that things are slow.

Your situation	Endpoint type that usually fits	What to watch for
Prototyping, scripts, low request volume	Public endpoint	Shared capacity, aggressive rate limits, no SLA
A production dApp with steady read traffic	Managed RPC API (shared, keyed)	Per-method limits, WebSocket connection caps
Indexers, bots, high getProgramAccounts use	Dedicated node	Memory and disk for account scans, archive needs
Trading or latency-sensitive submission	Dedicated node close to your infra	Slot lag, transaction landing rate, failover
Need historical state or full ledger	Archive-capable dedicated node	Storage growth, snapshot restore time

OnFinality provides Solana RPC through a managed RPC API service and through dedicated nodes when you need isolated capacity. The managed endpoint is the right starting point for most apps; dedicated nodes are for teams that have outgrown shared throughput or need predictable resources.

A quick rule of thumb: if your errors are mostly 429 responses, you need a keyed managed plan or a dedicated node. If your errors are timeouts on heavy calls like getProgramAccounts, you need more memory and a dedicated node rather than a bigger shared plan.

Solana RPC server settings at a glance

When you configure a wallet, a framework, or a backend service, you need the network parameters, not just the URL. For Solana mainnet these are the values to use.

Setting	Value
Chain name	Solana Mainnet
Native currency	SOL (9 decimals)
HTTP RPC URL	https://solana.api.onfinality.io/public
WebSocket RPC URL	wss://solana.api.onfinality.io/public-ws
Block explorer	https://explorer.solana.com
Transports supported	HTTP and WebSocket

For development and testing, use a devnet endpoint instead of mainnet so you are not spending real SOL. OnFinality exposes a separate Solana Devnet endpoint, and you can request devnet SOL from the standard Solana faucet to fund test transactions. Keep devnet and mainnet configuration in separate environment variables so a test key never points at mainnet by accident.

A common pattern is to store the endpoint in an environment variable and read it at startup:

SOLANA_RPC_URL=https://solana.api.onfinality.io/public
SOLANA_WS_URL=wss://solana.api.onfinality.io/public-ws

Connecting with curl and JavaScript

The simplest way to confirm a Solana RPC server is responding is a JSON-RPC call over HTTP. Solana uses the same JSON-RPC 2.0 envelope as other chains, but with Solana-specific methods.

curl https://solana.api.onfinality.io/public \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getLatestBlockhash",
    "params": [{"commitment": "confirmed"}]
  }'

A healthy response returns a result object containing a blockhash and lastValidBlockHeight. If you get an error object instead, the endpoint is reachable but the request was rejected, which usually points to a malformed method or parameter rather than a network problem.

In JavaScript, the @solana/web3.js library wraps these calls. Point the connection at your endpoint and pass a commitment level:

import { Connection, PublicKey, clusterApiUrl } from "@solana/web3.js";

const connection = new Connection(
  process.env.SOLANA_RPC_URL,
  { commitment: "confirmed", wsEndpoint: process.env.SOLANA_WS_URL }
);

const balance = await connection.getBalance(
  new PublicKey("11111111111111111111111111111111")
);
console.log("lamports:", balance);

Commitment levels matter on Solana. processed is fastest but can be rolled back, confirmed is the common default for most apps, and finalized is the safest for settlement logic. Choose the level that matches the risk of the action, not the fastest one available.

WebSocket subscriptions and when to use them

Solana RPC servers also expose a WebSocket transport for push-based updates. Instead of polling getSlot or getAccountInfo in a loop, you subscribe and receive notifications when state changes.

const subId = connection.onAccountChange(
  new PublicKey("11111111111111111111111111111111"),
  (accountInfo, context) => {
    console.log("slot", context.slot, "lamports", accountInfo.lamports);
  },
  "confirmed"
);

WebSocket subscriptions are efficient, but they hold a connection open, and shared endpoints often cap concurrent subscriptions. If you run many subscriptions across many users, track your connection count and plan for reconnects. Subscriptions can drop during network congestion, so always handle the disconnect event and resubscribe rather than assuming the stream is permanent.

For high-frequency use, a dedicated node gives you a stable subscription budget and avoids competing with other tenants for notification delivery.

Common failure modes and how to read them

Most Solana RPC problems fall into a small set of symptoms. Matching the symptom to the cause saves a lot of guessing.

Symptom	Likely cause	First fix
HTTP 429 responses	Rate limit on a shared endpoint	Add a keyed plan or move to dedicated
Request timeouts on getProgramAccounts	Large account scan, memory pressure	Use filters, or move to a dedicated node
Blockhash not found on send	Blockhash expired before landing	Fetch a fresh blockhash and retry
Transaction lands slowly	Congestion or fee too low	Add priority fee, resubmit
WebSocket disconnects	Idle timeout or connection cap	Implement reconnect and resubscribe
Stale slot data	Node behind the tip	Check slot lag, consider a different node

Two of these deserve more detail. First, getProgramAccounts without filters is one of the heaviest calls on Solana. It can scan a large amount of account data, and on a shared endpoint it is often the first call to be throttled. Add data-size and memcmp filters to narrow the result set before you blame the endpoint.

Second, transaction landing is not just about the RPC server. Solana uses a blockhash that expires after a short window, so a transaction built with an old blockhash will fail even on a perfectly healthy endpoint. Fetch a fresh blockhash, set a reasonable priority fee, and retry with backoff.

Production readiness checklist

Before you send real traffic to a Solana RPC server, work through these items. They are the difference between a demo and something that survives a busy day.

• Separate environments. Keep devnet and mainnet endpoints and keys in distinct configuration.
• Set commitment levels deliberately. Use confirmed for most reads and finalized for settlement.
• Handle rate limits. Detect 429 responses and back off instead of retrying immediately.
• Plan for failover. Configure a secondary endpoint so a single outage does not take down your app.
• Monitor slot lag. Track how far your node is behind the cluster tip.
• Watch WebSocket health. Log disconnects and resubscription success.
• Budget for heavy calls. Know which methods your app uses most and size accordingly.

If several of these items are already painful on a shared endpoint, that is the signal to evaluate a dedicated node. You can compare plans on the RPC pricing page and see the full list of supported RPC networks if you also operate on other chains.

Running your own Solana RPC server vs renting one

You can run a Solana RPC node yourself. The tradeoff is operational, not just financial. A Solana RPC node needs substantial RAM, fast NVMe storage, and ongoing attention to snapshots, upgrades, and monitoring. The ledger grows continuously, so storage planning is a recurring task, not a one-time setup.

Renting a managed endpoint or a dedicated node shifts that operational load to the provider. You still choose the region, the capacity, and the transport, but you are not patching the node or restoring snapshots at 2am. For most product teams, that is the better use of engineering time. For teams with strict data-locality or compliance requirements, self-hosting may still be the right call, and a hybrid approach (self-hosted primary, managed failover) is common.

OnFinality sits in the managed camp: you get a Solana RPC endpoint and, when needed, a dedicated node without running the infrastructure yourself. The Solana network page lists the current endpoint details and transports.

Migrating from a public endpoint without breaking things

Moving from a public Solana RPC server to a managed or dedicated one should be a configuration change, not a rewrite. The steps are straightforward if you prepare them.

1. Add the new endpoint alongside the old one. Do not delete the public URL yet.
2. Route a small percentage of traffic to the new endpoint and compare error rates and latency.
3. Update WebSocket configuration separately, since HTTP and WS endpoints are distinct.
4. Verify commitment levels behave the same on the new endpoint.
5. Switch the default once error rates are stable, keeping the old endpoint as failover.
6. Remove the public endpoint only after a full traffic cycle with no regressions.

Because Solana RPC is JSON-RPC over HTTP, the migration is usually a URL swap in your environment variables plus a redeploy. The risk is in the details: forgetting the WebSocket URL, or changing commitment levels at the same time as the endpoint, which makes it hard to tell what caused a change in behavior.

Key Takeaways

• A Solana RPC server is the HTTP and WebSocket interface your app uses to read state and submit transactions.
• Mainnet uses chain name Solana Mainnet, SOL with 9 decimals, and the explorer at explorer.solana.com.
• Start on a shared or public endpoint, then move to a managed or dedicated node when you hit rate limits or heavy-call timeouts.
• Commitment levels (processed, confirmed, finalized) should match the risk of each action.
• WebSocket subscriptions are efficient but need reconnect and resubscription handling.
• getProgramAccounts and expired blockhashes are two of the most common sources of confusion.
• Migration is usually a configuration change, but update HTTP and WebSocket endpoints together.

Frequently Asked Questions

What is a Solana RPC server?

It is a service that exposes Solana's JSON-RPC API over HTTP and WebSocket, letting your application read accounts, submit transactions, and subscribe to events without running a node yourself.

What is the Solana RPC URL for mainnet?

OnFinality exposes Solana mainnet at https://solana.api.onfinality.io/public for HTTP and wss://solana.api.onfinality.io/public-ws for WebSocket. Always confirm current endpoints on the Solana network page.

Why am I getting 429 errors from my Solana RPC endpoint?

A 429 means you hit a rate limit, which is common on shared or public endpoints. A keyed managed plan or a dedicated node removes that shared ceiling.

Should I use HTTP or WebSocket for Solana?

Use HTTP for request-response calls and WebSocket for push updates such as account or slot changes. Most production apps use both.

Can I use a public Solana RPC endpoint in production?

You can, but public endpoints are shared and often rate limited. For steady production traffic, a managed or dedicated endpoint gives you more predictable behavior and a clear upgrade path.

How do I test without spending SOL?

Use a devnet endpoint and request devnet SOL from the faucet. Keep devnet configuration separate from mainnet so keys never cross over.

Related resources

• Solana RPC network page
• Solana Devnet RPC
• RPC pricing
• Supported RPC networks
• Dedicated nodes
• How to choose an RPC provider

Originally published at OnFinality.