Private vs Public RPC: Access, Capacity and Production Requirements
Compare private and public RPC endpoints by access control, history, capacity, privacy and failover. Learn why private access does not mean dedicated nodes.
Private access does not mean dedicated infrastructure
In this guide, public RPC means an endpoint that lets applications send requests without customer-specific credentials. A private endpoint restricts access, usually through an API key, network rules, or both. That distinction tells you who can connect. It does not tell you whether the underlying nodes are shared, how much history they retain, or what happens during an outage.
An API key can identify your account on a shared service. A dedicated RPC node reserves node resources for your workload. You may need private access without needing dedicated capacity, or both. Before choosing a provider, separate three questions: who can access the endpoint, what infrastructure serves it, and what operating commitments come with it. Our dedicated vs shared RPC comparison covers the infrastructure decision.
When a public endpoint is enough
A public endpoint can work well for testing a wallet integration, checking a transaction, or building a prototype. It gives developers a way to start without deploying a node. For a background task that can pause and resume, occasional throttling may also be acceptable.
The decision changes when another service depends on the result. An exchange monitoring deposits needs to detect missing blocks and recover them. An indexer rebuilding history needs a known starting height and enough capacity to finish. A public endpoint is not automatically unsuitable, but its documented capabilities must match those requirements. A successful request during development is not a production acceptance test.
What to check before relying on an endpoint
Start with your actual methods. Can the endpoint submit transactions, return the historical data you need, and maintain your expected WebSocket subscriptions? Test the earliest required block rather than assuming that a node near the chain tip also retains old data. Blocks, receipts, historical state and traces are different requirements; archive-node coverage explains why.
Next, check the service policy. Look for request quotas, concurrency limits, query-range restrictions and support arrangements. Establish whether maintenance comes with notice and whether a failed node is replaced behind the same endpoint. If several nodes serve one URL, test for differences in block height and retained history between responses.
Private RPC is not a privacy guarantee
Authentication restricts endpoint access, but the operator can still process requests and may log their contents. Ask what is logged, how long logs are retained, and who can access them. Using a private endpoint does not make information recorded on the blockchain confidential.
Keep credentials out of public frontend code when they grant access to infrastructure intended only for your backend. Separate production and development credentials where supported, and make rotation possible without rebuilding the application.
Plan for a failed connection
A second endpoint is useful only if it supports the same methods and required history. Test it with production-shaped requests before an incident. For historical reads, a fallback that serves only recent state may be reachable but unusable.
Transaction submission needs separate handling. A timeout does not prove that the first endpoint rejected the transaction. Preserve the signed transaction and its hash, then check its status before deciding whether to rebroadcast. Do not create a new transaction merely because an HTTP request timed out.
Request a dedicated RPC node from DTEAM
DTEAM dedicated nodes have no artificial request-rate limits or usage quotas. Sustainable throughput depends on the hardware, node client and workload. Access controls, enabled methods and historical coverage should be agreed for the deployment.
Send DTEAM your network and RPC requirements: the methods you call, peak concurrency, application region, WebSocket usage and earliest required block. Networks listed on our site are not the limit of our coverage. Additional networks can be scoped on request.