Solana Clusters and Public RPC Endpoints: Which One Should Your App Connect To?

Solana is not one network but a set of independent clusters, each with its own ledger, RPC endpoints, and purpose. If you are wiring up a wallet, a dApp, or a backend indexer, the cluster you connect to determines which accounts, programs, and tokens you can actually see. This page covers the cluster settings you need, the public endpoints that are available, and how to decide when a public endpoint stops being the right tool.

Which Solana cluster should you connect to?

The choice comes down to three questions: are you moving real value, are you testing program logic, or are you validating validator/client changes? The table below maps each cluster to its typical use and the practical implications.

If your app handles real funds, you belong on mainnet-beta. If you are iterating on program logic or UI flows, devnet is the right sandbox. Testnet is primarily for validator operators and core protocol testing — using it for app development usually leads to confusion because tooling and data assumptions differ from mainnet.

A frequent source of bugs is a mismatch between the cluster your frontend thinks it is using and the cluster your backend or wallet is actually connected to. Always log the genesis hash at startup and compare it against the expected value for the cluster.

Cluster settings at a glance

Each cluster is identified by a genesis hash. Checking this hash is the fastest way to confirm you are on the right network.

You can verify the genesis hash of any endpoint with a single RPC call:

curl -s https://solana.api.onfinality.io/public -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"getGenesisHash"}'

The response should match the table above for the cluster you intend to use. If it does not, you are pointed at the wrong environment.

Public RPC endpoints: what they are and when they are enough

A public RPC endpoint is a shared, unauthenticated URL that anyone can call. Solana's official documentation lists public endpoints for each cluster, and many infrastructure providers — including OnFinality — also expose public endpoints for Solana mainnet and devnet. These are convenient for quick tests, tutorials, and low-volume scripts.

Public endpoints typically come with tradeoffs you should plan around:

• Shared capacity: your requests compete with everyone else's, so latency and throughput can vary.
• Rate limits: most public endpoints apply some form of request throttling, though the exact policy varies.
• No SLA: there is usually no commitment to availability or support.
• Limited method access: some heavy or specialized methods may be restricted.

For a hackathon demo or a local script, a public endpoint is fine. For a production app with real users, you will quickly hit the limits of what a shared public endpoint can offer.

OnFinality provides a public Solana mainnet endpoint at https://solana.api.onfinality.io/public and a matching WebSocket endpoint at wss://solana.api.onfinality.io/public-ws. These are useful for development and light usage; for production workloads you can move to a managed or dedicated plan through RPC pricing.

Connecting a wallet or dApp to a Solana cluster

Most Solana tooling lets you specify the cluster or RPC endpoint directly. In JavaScript, the @solana/web3.js library takes a connection endpoint:

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

// Public devnet endpoint (for testing)
const devnetConnection = new Connection(clusterApiUrl('devnet'), 'confirmed');

// OnFinality public mainnet endpoint (for light production use)
const mainnetConnection = new Connection('https://solana.api.onfinality.io/public', 'confirmed');

// Always confirm the cluster before sending transactions
const genesisHash = await mainnetConnection.getGenesisHash();
console.log('Connected to genesis hash:', genesisHash);

For wallets that support custom RPC configuration, the settings usually ask for an RPC URL and sometimes a WebSocket URL. Use the mainnet endpoint above for mainnet-beta, and the devnet endpoint from the Solana docs for devnet. Keep the WebSocket URL separate if your app subscribes to account or program changes.

A common pitfall is hardcoding a devnet endpoint in a build that later ships to production. Use environment variables and assert the genesis hash at startup so this fails loudly rather than silently.

Requesting an airdrop on devnet or testnet

Devnet and testnet provide faucets so you can obtain SOL for testing. On devnet, you can request an airdrop via the CLI:

solana airdrop 2 --url https://api.devnet.solana.com

Or programmatically:

const signature = await devnetConnection.requestAirdrop(publicKey, 1_000_000_000); // 1 SOL
await devnetConnection.confirmTransaction(signature);

Faucet limits apply, and devnet may reset, wiping test state. Do not rely on devnet for anything you need to persist. If you need a stable, isolated environment for integration tests, a dedicated node or a managed RPC plan with a private endpoint can give you more predictable behavior than a shared public faucet-backed cluster.

Production readiness checklist

Before you point real users at a Solana endpoint, work through these checks:

• Cluster confirmed: genesis hash matches the intended cluster at startup and in health checks.
• Endpoint capacity: the endpoint can handle your expected request rate, including bursts during popular mints or market events.
• WebSocket support: if you use subscriptions, confirm the endpoint supports wss and that your client reconnects cleanly.
• Failover: you have at least one backup endpoint and a strategy for switching when the primary degrades.
• Observability: you log request latency, error rates, and rate-limit responses so you can detect problems before users do.
• Method coverage: the methods you rely on (for example getProgramAccounts, getSignaturesForAddress, or simulateTransaction) are available and perform acceptably.

If several of these are uncertain on a public endpoint, that is a signal to evaluate a managed or dedicated RPC service. OnFinality offers Solana RPC through its API service and dedicated node options, with endpoints you can test before committing. See the Solana network page for current endpoint details.

Debugging cluster and endpoint problems

When something breaks, the symptom often points to a specific cause. The table below maps common symptoms to likely fixes.

A useful first debugging step is to run getGenesisHash and getHealth against the endpoint your app is using. If those succeed but your application still fails, the issue is likely in how the client is configured rather than the endpoint itself.

Moving from a public endpoint to managed or dedicated RPC

Public endpoints are a starting point, not a production strategy. As your app grows, you will want more predictable throughput, clearer limits, and support when something goes wrong. Managed RPC services provide authenticated endpoints with defined capacity, while dedicated nodes give you isolated infrastructure for workloads that need consistent performance or access to heavier methods.

OnFinality provides both managed RPC API access and dedicated node infrastructure across a range of networks, including Solana. You can review supported RPC networks to see what is available, and compare plans on the RPC pricing page. If you are still deciding between providers, the guide on how to choose an RPC provider covers the evaluation criteria in more detail.

When migrating, keep the old endpoint configured as a fallback until you have verified the new one under real traffic. Test WebSocket subscriptions, heavy read methods, and error handling before cutting over.

Key Takeaways

• Solana has three main clusters: mainnet-beta (production), devnet (app development), and testnet (validator/protocol testing).
• Each cluster has its own genesis hash; checking it is the fastest way to confirm you are on the right network.
• Public RPC endpoints are convenient for development and light use but are shared, often rate-limited, and not designed for production traffic.
• Devnet and testnet provide faucets; mainnet-beta does not.
• For production apps, evaluate managed or dedicated RPC services such as OnFinality for more predictable capacity and support.
• Always implement failover, logging, and genesis-hash checks before going live.

Frequently Asked Questions

What is the difference between a Solana cluster and an RPC endpoint?

A cluster is the network itself — a set of validators maintaining a shared ledger (mainnet-beta, devnet, or testnet). An RPC endpoint is the HTTP or WebSocket URL your application uses to talk to a node in that cluster. One cluster can have many endpoints.

Can I use a public RPC endpoint for a production Solana app?

You can start with one, but public endpoints are shared and often rate-limited. For production traffic, a managed or dedicated RPC service gives you more predictable performance and a clearer support path.

How do I know which cluster my app is connected to?

Call getGenesisHash on your endpoint and compare the result to the known genesis hash for mainnet-beta, devnet, or testnet. Log this at startup so mismatches are caught early.

Does OnFinality provide a public Solana RPC endpoint?

Yes. OnFinality exposes a public Solana mainnet endpoint at https://solana.api.onfinality.io/public and a WebSocket endpoint at wss://solana.api.onfinality.io/public-ws. For production workloads, managed and dedicated options are available.

What should I do if my Solana transactions fail with "blockhash not found"?

This usually means you are on the wrong cluster or using a stale blockhash. Confirm your genesis hash, fetch a fresh blockhash immediately before signing, and retry.

Where can I find Solana devnet and testnet endpoints?

Solana's official documentation lists public endpoints for devnet and testnet. OnFinality also offers a Solana Devnet endpoint for development and testing.