# Sui RPC Node Options: Public, Managed, or Dedicated

> Four ways to get a Sui RPC node, compared: the Foundation's public endpoints, your own full node, a managed RPC node provider, or a dedicated node. Setup, limits, history and cost.

Published 2026-10-08 · Cilooth · https://inodra.com/blog/sui-rpc-node-options

"Sui RPC node" is one phrase for four different things: the Foundation's public endpoints, a full node you run yourself, a managed shared gateway, and a dedicated node someone else operates for you. They differ on almost every axis that matters in production, and the right one changes as an application grows. This post lays the four side by side and gives a rule for choosing.

**TL;DR:**
- **Prototyping:** the Foundation's public gRPC endpoint, or a provider's free tier if you want JSON-RPC, history, or headroom.
- **Most production apps:** a managed shared gateway. One key, every protocol, full history, no node to run.
- **High or latency-sensitive volume:** a dedicated node, kept alongside the shared gateway.
- **Your own full node:** only if you already run chain infrastructure or need a configuration nobody offers.

## The four options at a glance

| | Foundation public endpoint | Your own full node | Managed shared gateway | Dedicated node |
|---|---|---|---|---|
| **Time to first call** | Minutes | Hours to days (snapshot download, restore, catch-up) | Minutes | 6 to 24 hours |
| **Protocols** | gRPC and GraphQL on mainnet and testnet, gRPC only on devnet (JSON-RPC retired) | Whatever you build on top | gRPC, GraphQL, JSON-RPC | gRPC, plus what you configure |
| **Rate limit** | Strict, undocumented | Hardware-bound | Per plan, 10 to 1,000+ req/s | None shared; hardware-bound |
| **History** | Live state, plus a public archival endpoint | Whatever you retain and pay to store | Full, since genesis | Archival mode on request |
| **Who patches it** | Sui Foundation | You | Provider | Provider |
| **Cost shape** | Free, capped | Hardware plus people | Per plan, from free | Flat monthly, per region |
| **Production use** | Not recommended by Sui | Yes, with a team | Yes | Yes |

The gateway and dedicated-node columns describe [Inodra](/sui-rpc-endpoints); other providers on [Mysten's official list](/blog/best-sui-rpc-providers) vary, particularly on history depth and JSON-RPC continuity.

## Option 1: the Foundation's public endpoints

Sui Foundation runs public-good gRPC, GraphQL and archival endpoints on mainnet and testnet, and gRPC only on devnet. The gRPC hosts are `fullnode.mainnet.sui.io:443` and the testnet and devnet equivalents; the [RPC providers page](https://docs.sui.io/develop/accessing-data/rpc-providers) in Sui's docs is the reference for the rest. They are free, they are rate-limited, and Sui's documentation says plainly that they are for development and testing rather than production. JSON-RPC was retired from them in July 2026.

Use them for a first `GetCheckpoint`, a tutorial, or a script you run once. Do not put them behind a product: the limits are not published, they change, and there is no one to call when they do.

## Option 2: your own full node

The full treatment is in [Sui full node requirements in 2026](/blog/sui-full-node-requirements). The short version: 8 cores, 128 GB of RAM and 4 TB of NVMe is the suggested minimum, disk grows past 7 TB without pruning, a new node should be restored from a snapshot rather than synced from genesis, and in our experience the operations budget (upgrades, monitoring, incidents, redundancy) exceeds the hardware budget within a year.

It makes sense when you already run chain infrastructure, when you need a configuration no provider offers, or when read volume is enormous and steady enough that fixed hardware beats per-request pricing and you have the people to keep it healthy. For everyone else it is the most expensive way to get an RPC endpoint.

## Option 3: a managed shared gateway

A shared gateway is a provider's fleet of nodes behind one endpoint per protocol, metered by API key. On Inodra that means gRPC, GraphQL and JSON-RPC on the same key, every request routed to a live node or to archival storage automatically, and full history since genesis on all three. Rate limits and monthly credits scale by plan, starting with a free tier that needs no credit card.

This is the right default for most applications. There is no node to patch, history is someone else's disk, and the endpoint is already redundant across machines. The trade-offs are the ones you would expect from anything shared: a per-plan rate limit, and neighbours on the same hardware. For the large majority of Sui apps neither is ever the bottleneck.

The [endpoints page](/sui-rpc-endpoints) has the URLs, the per-plan limits and a copyable first call for each protocol.

## Option 4: a dedicated node

A dedicated node is a full node reserved for one customer: bare-metal hardware with NVMe, a private endpoint with no shared rate limit, and a configuration you control (archival mode, RPC tuning, custom patches) while the provider keeps it patched and monitored. On Inodra it is priced per region (EU, US and Singapore, with more on request), delivered within 6 to 24 hours, and billed separately from the plan so the two stack.

That last point is the pattern we see most: keep the shared gateway for the bulk of reads and for history, and route the latency-sensitive or highest-volume path to the dedicated node. You get isolation where it matters without giving up the parts of the gateway that are hard to replicate on one machine, such as archival depth across every protocol.

## How to choose

1. **Starting out?** Public endpoint for the first hour, then a free tier on a shared gateway as soon as you want JSON-RPC, history, or a limit you can read about.
2. **Shipping?** Shared gateway. Pick a plan by the requests-per-second you actually need, not the one you might need in a year; plans change in a click, nodes do not.
3. **Hitting the limit, or chasing latency?** Add a dedicated node for the hot path and keep the gateway for the rest. If you are not sure you are hitting it, you are not: it shows up as 429s in your own dashboards before it shows up anywhere else.
4. **Compliance, custom patches, or existing infra?** Run your own, and budget for the operations honestly.

## FAQ

**What is a Sui RPC node?**
A Sui full node that exposes an API (gRPC, GraphQL or JSON-RPC) so applications can read chain state and submit transactions without running a node themselves. On Sui the go-forward interface is gRPC; JSON-RPC is served only by providers that run it on their own infrastructure.

**Is the Sui Foundation public RPC endpoint free?**
Yes, with strict rate limits. Sui's documentation describes the public-good gRPC, GraphQL and archival endpoints as suitable for development and testing, not for production workloads, and they no longer serve JSON-RPC.

**Do I need a dedicated Sui RPC node?**
Only when a shared gateway's rate limit or latency profile is the bottleneck, or when you need a custom node configuration such as archival mode or a patch. Most applications never reach that point; those that do usually see it in their own request graphs first.

## Related posts

- [Sui full node requirements in 2026](/blog/sui-full-node-requirements) - the hardware, the disk, the sync and the real cost of running your own
- [Best Sui RPC providers in 2026](/blog/best-sui-rpc-providers) - every provider on Mysten's official list compared
- [Dedicated Sui nodes](/products/dedicated-nodes) - hardware reserved for your traffic alone