Solana Devnet RPC: Endpoint Settings, Airdrops, and Debugging

Solana devnet is a separate cluster from mainnet-beta and testnet. It runs the same runtime as mainnet, but the ledger is disposable, tokens have no value, and the network is explicitly allowed to reset. That makes it the right place to deploy a program, run integration tests, and reproduce bugs before you ship.

The query "solana rpc devnet" usually comes from a developer who needs one of three things: a working endpoint URL, test SOL to pay for transactions, or a way to diagnose a failing request. This page answers all three, then explains when a public devnet endpoint stops being enough.

Which devnet endpoint should you use?

Pick your endpoint based on what you are doing, not on habit. Most developers start on a public endpoint and move to a managed or dedicated one when tests become part of a pipeline.

If you only need to read accounts and send occasional transactions, a public devnet endpoint is fine. If your tests fail intermittently and you cannot tell whether the cause is your code or the endpoint, that is the signal to move to a managed service.

OnFinality exposes Solana devnet as a supported network alongside Solana mainnet. You can review the Solana Devnet network page for connection details, and compare plans on the RPC pricing page if you need a keyed endpoint for CI.

Solana devnet chain settings at a glance

When you configure a wallet, an SDK, or a framework, you are choosing a cluster and an RPC URL. Solana does not use an EVM-style numeric chain ID for devnet in the same way Ethereum does; the cluster identity is what matters.

Keep devnet and mainnet configuration in separate files or environment variables. A large share of "it worked locally" incidents come from a build that silently pointed at the wrong cluster.

Connecting with curl and JavaScript

A minimal JSON-RPC call confirms the endpoint is reachable and returns the current slot.

curl https://your-devnet-endpoint.example \
  -X POST -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getSlot",
    "params": []
  }'

In JavaScript, the common pattern is to create a connection object and pass the cluster or an explicit endpoint.

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

// Option A: use the built-in devnet cluster URL
const connection = new Connection(clusterApiUrl("devnet"), "confirmed");

// Option B: use your own managed devnet endpoint
// const connection = new Connection(process.env.SOLANA_DEVNET_RPC, "confirmed");

const slot = await connection.getSlot();
console.log("current devnet slot:", slot);

const balance = await connection.getBalance(connection.publicKey ?? undefined);

For WebSocket subscriptions, construct the connection with the ws endpoint and use onAccountChange or onLogs:

const wsConnection = new Connection(process.env.SOLANA_DEVNET_WS, {
  commitment: "confirmed",
  wsEndpoint: process.env.SOLANA_DEVNET_WS,
});

const subId = wsConnection.onLogs(programId, (logs) => {
  console.log(logs.signature, logs.logs);
});

If subscriptions drop silently, log the subscription id and re-subscribe on error rather than assuming the endpoint is broken.

Getting test SOL from the devnet faucet

The faucet is rate limited and shared. Treat it as a convenience, not a guarantee.

• Request a small amount first and confirm the balance before running a large test.
• If a request fails, wait and retry rather than hammering the endpoint.
• For repeatable tests, fund a known keypair once and reuse it, or run a local validator where you can mint SOL freely.
• Never reuse a devnet keypair on mainnet. Generate a fresh keypair for anything that holds real value.

When a faucet request appears to succeed but the balance does not change, check the transaction signature on the explorer and confirm you are querying the same cluster you requested from.

Common devnet failures and how to read them

Most devnet errors fall into a small number of categories. The table below maps the symptom to the likely cause.

Devnet resets are normal. If your tests depend on pre-existing state, build a setup step that recreates it rather than assuming it persists.

When a public devnet endpoint is not enough

Public endpoints are shared, and devnet traffic is unpredictable. Two things tend to push teams toward managed infrastructure.

First, CI. If every commit triggers a test suite that sends transactions, you want a stable endpoint with its own credentials so one noisy job does not affect another. Second, observability. When a test fails, you need to know whether the request reached the node, what the node returned, and how long it took. A managed RPC service gives you per-key usage and clearer error responses.

OnFinality provides RPC API access and dedicated node options across many networks, including Solana. If your devnet usage is light, the shared service is usually sufficient. If you are running sustained load or need isolation, a dedicated node removes the noisy-neighbour problem. You can see the full list of supported chains on the supported RPC networks page.

A practical devnet workflow

A repeatable workflow saves more time than any single optimisation.

1. Keep cluster configuration in environment variables, never hard-coded.
2. Run a local validator for unit tests where you control the ledger.
3. Use devnet for integration tests that need realistic network conditions.
4. Fund a dedicated test keypair and reuse it across runs.
5. Log request ids, signatures, and slot numbers so failures are reproducible.
6. Add a health check that calls getSlot before a test suite starts.
7. Move to a keyed managed endpoint once tests run in CI.

This sequence keeps the cheap, fast feedback loop local and reserves network access for the cases that actually need it.

Key Takeaways

• Solana devnet is a separate cluster with no-value SOL, used for testing programs and clients before mainnet.
• The cluster name is devnet; keep it in environment variables and never mix it with mainnet-beta.
• The devnet faucet is rate limited, so fund a reusable test keypair instead of requesting repeatedly.
• Most devnet errors are blockhash expiry, wrong cluster, or rate limiting, not node faults.
• Devnet resets are expected; build setup steps that recreate state.
• Move from a public endpoint to a managed or dedicated RPC service when tests run in CI or need isolation.

Frequently Asked Questions

What is the Solana devnet RPC URL?

There is no single canonical URL. You can use the cluster URL provided by your SDK, or a managed endpoint from a provider. OnFinality lists Solana devnet as a supported network; see the Solana Devnet network page for connection details.

Is Solana devnet the same as testnet?

No. Devnet and testnet are separate clusters. Devnet is the more commonly used testing environment and is more likely to be reset. Always confirm which cluster your endpoint points to.

Why does my devnet transaction fail with "blockhash not found"?

The blockhash expired before the transaction was processed. Fetch a fresh blockhash immediately before sending and retry. On a busy or throttled endpoint this happens more often.

Can I use a public devnet endpoint in production?

Devnet is for testing, not production. For production workloads you should use mainnet with a managed or dedicated RPC service. See RPC pricing for plan options.

Does OnFinality support Solana devnet?

Yes. Solana devnet is listed among OnFinality's supported networks. Check the Solana Devnet network page and the RPC API service page for current details.

How do I test WebSocket subscriptions on devnet?

Use a ws endpoint, subscribe with onLogs or onAccountChange, and add reconnect logic. Public endpoints may drop idle connections, so handle re-subscription explicitly.