Solana Public Node: Free RPC Endpoints vs Production Infrastructure

Solana Public Node Decision Checklist

Before choosing between a public node and a dedicated RPC provider, evaluate these factors:

Criterion	What to check	Why it matters
Request volume	Estimate daily RPC calls	Public nodes rate-limit aggressively (e.g., 100 req/10s per IP)
SLA requirement	Do you need uptime guarantees?	Public nodes have no SLA; dedicated providers offer high+ uptime
Data freshness	Need recent block data?	Public nodes may lag behind the tip
WebSocket support	Real-time subscriptions?	Public WebSocket endpoints often have tighter limits
Privacy	Transaction data exposure	Public nodes see all requests; dedicated nodes isolate your traffic
Geographic latency	Where are your users?	Public nodes have limited regions; dedicated providers offer global PoPs
Archive data	Need historical state?	Public nodes typically only serve recent slots
Custom configuration	Need specific RPC methods or flags?	Public nodes are fixed; dedicated nodes can be tuned

What Is a Solana Public Node?

A Solana public node is a JSON-RPC endpoint operated by the Solana Foundation or a third party, available for anyone to use without authentication. These endpoints allow developers to send transactions, query account balances, and fetch block data without running their own validator or RPC node.

Solana currently offers three public clusters:

• Mainnet Beta: https://api.mainnet-beta.solana.com
• Devnet: https://api.devnet.solana.com
• Testnet: https://api.testnet.solana.com

These endpoints are free and open, but they come with significant constraints that make them unsuitable for production applications.

How Public Nodes Work

Public nodes are typically run by the Solana Foundation or community members as a service to the ecosystem. They accept incoming HTTP and WebSocket connections and relay them to the Solana cluster. Because they are shared among all users, they enforce rate limits to prevent abuse and ensure fair usage.

A typical interaction with a public node looks like this:

curl https://api.mainnet-beta.solana.com -X POST -H "Content-Type: application/json" -d '
  {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getSlot"
  }
'

This returns the current slot number. While simple, relying on this endpoint for production traffic is risky.

Rate Limits and Restrictions

Public Solana nodes enforce rate limits that vary by cluster and endpoint. As of writing, common limits include:

• 100 requests per 10 seconds per IP for Mainnet Beta
• 200 requests per 10 seconds per IP for Devnet
• 500 requests per 10 seconds per IP for Testnet

These limits are subject to change without notice. Exceeding them results in HTTP 429 responses or dropped connections. For any application with more than a handful of users, these limits become a bottleneck.

Additionally, public nodes may:

• Throttle heavy methods like getProgramAccounts or getSignaturesForAddress
• Disallow WebSocket subscriptions for long periods
• Serve stale data if the node is behind the cluster tip

When to Use a Public Node

Public nodes are appropriate for:

• Quick prototyping: Testing a script or smart contract during development
• Low-volume queries: Checking account balances or transaction statuses manually
• Learning and experimentation: Understanding Solana's RPC API without committing to infrastructure
• Hackathons and demos: Short-lived projects where uptime is not critical

For example, fetching the latest block hash for a one-off script:

const web3 = require('@solana/web3.js');
const connection = new web3.Connection('https://api.mainnet-beta.solana.com');
connection.getRecentBlockhash().then(console.log);

This works fine for a local test, but deploying it in production would quickly hit rate limits.

When to Upgrade to a Dedicated RPC Provider

If your application serves real users, processes more than a few hundred requests per day, or requires reliable performance, you need a dedicated RPC provider. Here are the signs it's time to switch:

• Rate limit errors: Your app receives 429 responses frequently
• Inconsistent latency: Response times vary wildly
• WebSocket disconnects: Subscriptions drop unexpectedly
• Data staleness: Queries return outdated slot information
• No support: You cannot get help when the endpoint goes down

Dedicated providers offer:

• Higher or clear rate limits: Tailored to your traffic
• Global load balancing: Multiple nodes in different regions
• SLA-backed uptime: Guaranteed availability
• Dedicated infrastructure: Isolated nodes for consistent performance
• Archive and trace data: Access to historical state
• Custom configurations: Tune RPC flags for your use case

How to Choose a Solana RPC Provider

When evaluating providers, consider:

1. Throughput: Can they handle your peak request volume?
2. Latency: Where are their nodes located relative to your users?
3. Reliability: What is their historical uptime? Do they publish status pages?
4. Data access: Do they support archive, WebSocket, and gRPC?
5. Pricing: Is it predictable and scalable?

OnFinality offers Solana RPC endpoints with both shared and dedicated options, supporting Mainnet, Devnet, and Testnet. You can start with a free tier and scale up as needed. Check our RPC pricing for details.

Common Pitfalls with Public Nodes

1. Assuming Availability

Public nodes can go down without warning. The Solana Foundation endpoints have experienced outages during network congestion. Always have a fallback endpoint.

2. Ignoring Rate Limits

Even a simple dApp can exceed 100 requests per 10 seconds if it polls frequently. Implement caching and backoff strategies.

3. Using Public Nodes in Production

Public nodes are explicitly not designed for production. The Solana documentation warns: "These endpoints are subject to rate limits and are not guaranteed to be available."

4. Not Monitoring Latency

Public node latency can spike during high traffic. Use a monitoring tool to track response times and switch providers if needed.

Setting Up a Reliable Solana Connection

For production, configure your application to use a dedicated RPC endpoint with fallback logic:

const connection = new web3.Connection(
  'https://solana.api.onfinality.io/public',
  {
    commitment: 'confirmed',
    confirmTransactionInitialTimeout: 60000
  }
);

This example uses OnFinality's public endpoint, which offers higher limits than the default Solana Foundation endpoint. For even better performance, consider a dedicated node.

Key Takeaways

• Solana public nodes are free but have strict rate limits and no SLA.
• They are suitable for prototyping and low-volume testing only.
• Production applications require a dedicated RPC provider with guaranteed throughput and uptime.
• When choosing a provider, evaluate throughput, latency, reliability, and pricing.
• Always implement fallback endpoints and caching to minimize reliance on any single node.

Frequently Asked Questions

Q: Can I use a Solana public node for a production dApp?
A: It is not recommended. Public nodes have rate limits, no SLA, and may become unavailable during network congestion. Use a dedicated RPC provider for production.

Q: What is the rate limit for Solana public nodes?
A: Approximately 100 requests per 10 seconds per IP for Mainnet Beta, but limits can change. Check the official Solana docs for the latest information.

Q: How do I find a list of Solana public nodes?
A: The Solana Foundation publishes endpoints for each cluster. Community-maintained lists like the extrnode GitHub repo aggregate many public endpoints.

Q: What is the difference between a public node and a dedicated node?
A: A public node is shared among all users, with rate limits and no guarantees. A dedicated node is provisioned for your exclusive use, offering higher throughput, lower latency, and an SLA.

Q: Does OnFinality offer Solana public nodes?
A: Yes, OnFinality provides public endpoints for Solana Mainnet, Devnet, and Testnet. For production workloads, we recommend our dedicated node service. See our supported networks for details.

Related resources

• Solana RPC endpoints
• RPC pricing
• Dedicated vs shared Solana RPC

Originally published at OnFinality.