From 244de31263cab8539e1c3955af78068dc6c5cf76 Mon Sep 17 00:00:00 2001 From: Camembear Date: Thu, 8 Jan 2026 09:02:50 -0500 Subject: [PATCH 1/4] add draft of self-managed RPC --- apps/core/content/nodes/self-rpc.md | 88 +++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 apps/core/content/nodes/self-rpc.md diff --git a/apps/core/content/nodes/self-rpc.md b/apps/core/content/nodes/self-rpc.md new file mode 100644 index 00000000..f2c2298b --- /dev/null +++ b/apps/core/content/nodes/self-rpc.md @@ -0,0 +1,88 @@ +## Introduction + +Berachain operates public RPCs at rpc.berachain.com. These serve normal everyday usage by end-users. Even so, some commercial projects route their backend transaction traffic through these public services. This poses reliability and performance risks to those projects. This article explains how to make your systems efficient, and cost-effectively build or rent a substitute for [public RPCs](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers). + +1. How to use an RPC efficiently + +You can transmit queries through two mechanisms. The most common is ETH-RPC, which involves looking up the server address, establishing a TCP connection to the server, negotiating SSL connection parameters, transmitting the RPC call, then closing the connection. If you're transmitting a few queries and then signing a transaction, this is a reasonable approach. + +However, if you are performing dozens or hundreds of queries per second, this connection overhead adds up quickly. There's a better way: [websockets](https://ethereum.org/bs/developers/tutorials/using-websockets/). WebSocket connections are, in principle, permanent. After you establish them, they can last for seconds or hours. + +In addition to regular ETH-RPC queries, a new category of RPC call becomes available: `eth_subscribe`. You can subscribe for a variety of events: + +- when new transactions enter the transaction pool +- when new blocks appear +- when transactions log events matching given criteria + +Putting this together, we can identify anti-patterns and what to replace them with: + +| Antipattern | Do this instead | +| ---------------------------------------- | -------------------------------------------- | +| Dozens or more connections every second | Persistent websocket connection | +| Polling `eth_blockNumber` for new blocks | `eth_subscribe` to `newHeads` over websocket | +| Calling `eth_getLogs` frequently | `eth_subscribe` for events over websocket | + +Using `eth_subscribe` as a substitute for `eth_getLogs` provides immediate notification of events, dramatically more efficient processing, and suffers fewer transient connection failures. + +2. Inexpensive paid services + +Paid services vary in their approach to pricing, but generally work on a model where you purchase a given amount of API credits, and providers price ETH-RPC calls according to their computational cost. You might expect to see costs of around $1-$2 per 100,000 requests. + +We have a useful list of paid RPC providers on our [developer tools page](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers). + +3. Running your own RPC + +Running a Berachain node requires two software components - the consensus layer (Beacon-Kit) and the execution layer (bera-reth or bera-geth). These are separate processes, each with their own database and configuration. Berachain provides simple node setup and launch scripts that support this combination, using one of two approaches: + +1. individual "setup" and "run" commands for each of the chain's components + ``` + ./fetch-berachain-params.sh + ./setup-beacond.sh + ./setup-reth.sh + ./run-beacond.sh & + ./run-reth.sh & + ``` +2. a complete "launch a node for me" command that downloads appropriate executables for Beacon-Kit and the execution layer, configures them, installs a chain-state snapshot, and prepares `systemd` units, ready to start. + ``` + mkberanode.sh --chain mainnet --el reth --mode pruned + sudo systemctl start berachain-el + sudo systemctl start berachain-cl + ``` + +You can find both approaches in the Guides repository, and the Quickstart [describes them](https://docs.berachain.com/nodes/quickstart). + +Another common choice is to operate in Docker/Kubernetes. + +## 4. Reliability + +Berachain is setting its RPCs to commercially normal public RPC use limits. The use case enables end users to send transactions, not for running the backend of a service. + +Use RPCs efficiently by caching receipts and logs, and avoiding repeated `eth_getLogs` / `eth_blockNumber` / `'latest'` calls every N seconds. Instead, use websockets and subscribe. + +--- + + - Berachain is setting its RPCs to commercially normal public RPC use limts + + - Use case enables end users to send transactions. + + - Not for running the backend of a service + +- Use RPCs efficiently + - cache receipts and logs + - repeatede getLogs / eth_blockNumber / ('latest') every N seconds + - use websockets / subscribe + +- Options are: + - Free services from Bera community + https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers + + - Public paid services + $42/mo at Quicknode gets you 40M requests + 30 requests/sec all month long + + - Private RPC service you manage + $100/mo basically unlimited, hundreds of request/sec depending on what you provision + + - What about failover? SKIP THIS + Paid services include a lot of redundancy + Roll your own with eRPC https://github.com/erpc/erpc From 91e08cf3a8735868eca5712565e86b3bbed8c8a4 Mon Sep 17 00:00:00 2001 From: Camembear Date: Fri, 23 Jan 2026 15:16:17 -0500 Subject: [PATCH 2/4] rename self-rpc to self-hosted, add frontmatter and sidebar --- apps/core/.vitepress/sidebar.ts | 1 + .../nodes/{self-rpc.md => self-hosted.md} | 55 ++++++++----------- 2 files changed, 23 insertions(+), 33 deletions(-) rename apps/core/content/nodes/{self-rpc.md => self-hosted.md} (66%) diff --git a/apps/core/.vitepress/sidebar.ts b/apps/core/.vitepress/sidebar.ts index d4b78d54..fc8b365a 100644 --- a/apps/core/.vitepress/sidebar.ts +++ b/apps/core/.vitepress/sidebar.ts @@ -311,6 +311,7 @@ const SIDEBAR = { }, { text: "EVM Execution Layer", link: "/nodes/evm-execution" }, { text: "Quickstart: Run A Node", link: "/nodes/quickstart" }, + { text: "Self-Hosted RPC Guide", link: "/nodes/self-hosted" }, { text: "Production Checklist", link: "/nodes/production-checklist" }, { text: "Monitoring", link: "/nodes/monitoring" }, { diff --git a/apps/core/content/nodes/self-rpc.md b/apps/core/content/nodes/self-hosted.md similarity index 66% rename from apps/core/content/nodes/self-rpc.md rename to apps/core/content/nodes/self-hosted.md index f2c2298b..ef733558 100644 --- a/apps/core/content/nodes/self-rpc.md +++ b/apps/core/content/nodes/self-hosted.md @@ -1,8 +1,23 @@ +--- +head: + - - meta + - property: og:title + content: Self-Hosted RPC Guide + - - meta + - name: description + content: How to efficiently use RPCs and set up self-hosted RPC infrastructure for Berachain + - - meta + - property: og:description + content: How to efficiently use RPCs and set up self-hosted RPC infrastructure for Berachain +--- + +# Self-Hosted RPC Guide + ## Introduction Berachain operates public RPCs at rpc.berachain.com. These serve normal everyday usage by end-users. Even so, some commercial projects route their backend transaction traffic through these public services. This poses reliability and performance risks to those projects. This article explains how to make your systems efficient, and cost-effectively build or rent a substitute for [public RPCs](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers). -1. How to use an RPC efficiently +## 1. How to Use an RPC Efficiently You can transmit queries through two mechanisms. The most common is ETH-RPC, which involves looking up the server address, establishing a TCP connection to the server, negotiating SSL connection parameters, transmitting the RPC call, then closing the connection. If you're transmitting a few queries and then signing a transaction, this is a reasonable approach. @@ -24,13 +39,13 @@ Putting this together, we can identify anti-patterns and what to replace them wi Using `eth_subscribe` as a substitute for `eth_getLogs` provides immediate notification of events, dramatically more efficient processing, and suffers fewer transient connection failures. -2. Inexpensive paid services +## 2. Inexpensive Paid Services Paid services vary in their approach to pricing, but generally work on a model where you purchase a given amount of API credits, and providers price ETH-RPC calls according to their computational cost. You might expect to see costs of around $1-$2 per 100,000 requests. We have a useful list of paid RPC providers on our [developer tools page](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers). -3. Running your own RPC +## 3. Running Your Own RPC Running a Berachain node requires two software components - the consensus layer (Beacon-Kit) and the execution layer (bera-reth or bera-geth). These are separate processes, each with their own database and configuration. Berachain provides simple node setup and launch scripts that support this combination, using one of two approaches: @@ -53,36 +68,10 @@ You can find both approaches in the Guides repository, and the Quickstart [descr Another common choice is to operate in Docker/Kubernetes. -## 4. Reliability - -Berachain is setting its RPCs to commercially normal public RPC use limits. The use case enables end users to send transactions, not for running the backend of a service. - -Use RPCs efficiently by caching receipts and logs, and avoiding repeated `eth_getLogs` / `eth_blockNumber` / `'latest'` calls every N seconds. Instead, use websockets and subscribe. - ---- - - - Berachain is setting its RPCs to commercially normal public RPC use limts - - - Use case enables end users to send transactions. - - - Not for running the backend of a service - -- Use RPCs efficiently - - cache receipts and logs - - repeatede getLogs / eth_blockNumber / ('latest') every N seconds - - use websockets / subscribe - -- Options are: - - Free services from Bera community - https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers +## 4. Reliability and Pricing - - Public paid services - $42/mo at Quicknode gets you 40M requests - 30 requests/sec all month long +Berachain sets its public RPCs to commercially normal use limits. These endpoints are designed for end users sending transactions, not for running the backend of a service. Commercial projects should provision their own infrastructure or use paid services. - - Private RPC service you manage - $100/mo basically unlimited, hundreds of request/sec depending on what you provision +When choosing an RPC solution, you have several options. Free services from the Berachain community are available and listed on our [developer tools page](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers). Public paid services typically cost around $42/month for 40M requests, providing roughly 30 requests per second sustained over the month. For a private RPC service you manage yourself, expect costs around $100/month for essentially unlimited requests, with hundreds of requests per second depending on your infrastructure provisioning. - - What about failover? SKIP THIS - Paid services include a lot of redundancy - Roll your own with eRPC https://github.com/erpc/erpc +Paid providers build redundancy into their offerings, but if you're assembling your own multi-provider setup, you'll want a layer that handles failover automatically. [eRPC](https://github.com/erpc/erpc) is one such tool: a fault-tolerant RPC proxy that sits in front of multiple upstreams and manages retries, circuit breakers, failovers, and hedged requests. It routes traffic to the fastest healthy provider, caches responses to reduce upstream load, and provides a single endpoint for your application regardless of how many backends you're actually using. From aa5206a2ba66cbf0f8a888fb743686e0e40cdc00 Mon Sep 17 00:00:00 2001 From: Camembear Date: Mon, 9 Feb 2026 17:23:34 -0500 Subject: [PATCH 3/4] Improve self-hosted RPC guidance Rewrite to focus on efficient RPC usage, subscriptions/reconnects, and clearer provider/self-hosting tradeoffs; link public RPC as https://rpc.berachain.com/ and drop the EIP-7702 detour. --- apps/core/content/nodes/self-hosted.md | 62 +++++++++++--------------- 1 file changed, 25 insertions(+), 37 deletions(-) diff --git a/apps/core/content/nodes/self-hosted.md b/apps/core/content/nodes/self-hosted.md index ef733558..47c58fdb 100644 --- a/apps/core/content/nodes/self-hosted.md +++ b/apps/core/content/nodes/self-hosted.md @@ -5,73 +5,61 @@ head: content: Self-Hosted RPC Guide - - meta - name: description - content: How to efficiently use RPCs and set up self-hosted RPC infrastructure for Berachain + content: How to efficiently use RPCs and choose paid or self-hosted options for Berachain - - meta - property: og:description - content: How to efficiently use RPCs and set up self-hosted RPC infrastructure for Berachain + content: How to efficiently use RPCs and choose paid or self-hosted options for Berachain --- # Self-Hosted RPC Guide ## Introduction -Berachain operates public RPCs at rpc.berachain.com. These serve normal everyday usage by end-users. Even so, some commercial projects route their backend transaction traffic through these public services. This poses reliability and performance risks to those projects. This article explains how to make your systems efficient, and cost-effectively build or rent a substitute for [public RPCs](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers). +Berachain operates public RPCs at https://rpc.berachain.com/. These serve normal, day-to-day usage by end users. Some commercial projects also route production backend traffic through these public services; that can make it harder to hit strict latency and availability targets on a shared, rate-limited endpoint. This article covers the highest-leverage fixes for app developers. Start with usage patterns, then move on to replacing [public RPCs](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers) when you need dedicated capacity. ## 1. How to Use an RPC Efficiently -You can transmit queries through two mechanisms. The most common is ETH-RPC, which involves looking up the server address, establishing a TCP connection to the server, negotiating SSL connection parameters, transmitting the RPC call, then closing the connection. If you're transmitting a few queries and then signing a transaction, this is a reasonable approach. +You can transmit queries through two common transports. The most common is JSON-RPC over HTTP or HTTPS. Well-behaved clients typically reuse connections with keep-alive enabled, but high request rates still pay per-request overhead from headers, request and response framing, and retry behaviour. That overhead can amplify tail latency. -However, if you are performing dozens or hundreds of queries per second, this connection overhead adds up quickly. There's a better way: [websockets](https://ethereum.org/bs/developers/tutorials/using-websockets/). WebSocket connections are, in principle, permanent. After you establish them, they can last for seconds or hours. +Retry discipline matters at least as much as raw request volume. If you are seeing `429` rate limits or intermittent timeouts, avoid “retry immediately” loops: they create retry storms that make throttling worse and can turn partial degradation into a full outage. Use exponential backoff with jitter, honour `Retry-After` when present, and cap retries. When upstreams stay unhealthy, shed load by queueing work, degrading non-critical reads, or failing fast. Be especially careful retrying write flows; reads are typically safe to retry, but duplicate submissions can surprise you. -In addition to regular ETH-RPC queries, a new category of RPC call becomes available: `eth_subscribe`. You can subscribe for a variety of events: +If you need streaming updates or you are polling aggressively, [WebSockets](https://ethereum.org/developers/tutorials/using-websockets/) are often a better fit. WebSocket connections are long-lived, which makes push workflows viable and reduces churn from repeated connect/reconnect cycles. -- when new transactions enter the transaction pool -- when new blocks appear -- when transactions log events matching given criteria +In addition to regular JSON-RPC queries, a new category of RPC call becomes available over WebSockets: `eth_subscribe`. You can subscribe to a variety of events: when new blocks appear, or when transaction logs match given criteria. Putting this together, we can identify anti-patterns and what to replace them with: -| Antipattern | Do this instead | +| Anti-pattern | Do this instead | | ---------------------------------------- | -------------------------------------------- | -| Dozens or more connections every second | Persistent websocket connection | -| Polling `eth_blockNumber` for new blocks | `eth_subscribe` to `newHeads` over websocket | -| Calling `eth_getLogs` frequently | `eth_subscribe` for events over websocket | +| Short-lived HTTP connections without keep-alive | Enable keep-alive or use a persistent WebSocket | +| Polling `eth_blockNumber` for new blocks | `eth_subscribe` to `newHeads` over WebSocket | +| Calling `eth_getLogs` frequently | `eth_subscribe` for events over WebSocket | -Using `eth_subscribe` as a substitute for `eth_getLogs` provides immediate notification of events, dramatically more efficient processing, and suffers fewer transient connection failures. +Subscriptions provide immediate notification of new data and can dramatically reduce load compared to polling. They do not replace `eth_getLogs` for historical backfills, and they are not a delivery guarantee. Production consumers still need reconnect and resubscribe logic, plus a robust way to detect and repair gaps. A common pattern tracks the last processed block and uses `eth_getLogs` to reconcile after reconnects. + +For event-heavy workloads such as analytics, indexing, and historical backfills, hammering `eth_getLogs` directly from app servers is usually the wrong tool. Prefer an indexing service and query it over a purpose-built API; Goldsky supports Berachain, and their [Berachain docs](https://docs.goldsky.com/chains/berachain) show the current options. Reserve RPC log queries for narrow reconciliation. If you do use `eth_getLogs`, keep queries tight by filtering on contract address and topics, chunk by block range, checkpoint the last processed block, and run it from a single worker to avoid redundant scans. + +If your pain is not reads, but user write flows, reduce round-trips per user action. Where supported, standards like [EIP-5792](https://eips.ethereum.org/EIPS/eip-5792), via `wallet_sendCalls`, can batch multiple calls into a single wallet flow, cutting RPC chatter and wallet friction in multi-step sequences. ## 2. Inexpensive Paid Services -Paid services vary in their approach to pricing, but generally work on a model where you purchase a given amount of API credits, and providers price ETH-RPC calls according to their computational cost. You might expect to see costs of around $1-$2 per 100,000 requests. +Paid services vary in their approach to pricing, but generally work on a model where you purchase API credits and providers price JSON-RPC calls according to their computational cost. Costs vary widely by request mix; simple reads are usually cheaper than log queries, and cacheability and archive access also matter. Treat any single "$X per 100,000 requests" number as an order-of-magnitude estimate, not a budget. We have a useful list of paid RPC providers on our [developer tools page](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers). -## 3. Running Your Own RPC +## 3. Running Your Own RPC When You Need Isolation -Running a Berachain node requires two software components - the consensus layer (Beacon-Kit) and the execution layer (bera-reth or bera-geth). These are separate processes, each with their own database and configuration. Berachain provides simple node setup and launch scripts that support this combination, using one of two approaches: +If you need predictable throughput, hard isolation, or you cannot tolerate multi-tenant rate limits, the next step is operating a private RPC endpoint backed by your own node. A Berachain node has two components: the consensus layer, Beacon-Kit, and the execution layer, bera-reth or bera-geth. For setup instructions, use the node Quickstart, which stays current as tooling changes: [nodes/quickstart](https://docs.berachain.com/nodes/quickstart). -1. individual "setup" and "run" commands for each of the chain's components - ``` - ./fetch-berachain-params.sh - ./setup-beacond.sh - ./setup-reth.sh - ./run-beacond.sh & - ./run-reth.sh & - ``` -2. a complete "launch a node for me" command that downloads appropriate executables for Beacon-Kit and the execution layer, configures them, installs a chain-state snapshot, and prepares `systemd` units, ready to start. - ``` - mkberanode.sh --chain mainnet --el reth --mode pruned - sudo systemctl start berachain-el - sudo systemctl start berachain-cl - ``` +## 4. Reliability and Pricing -You can find both approaches in the Guides repository, and the Quickstart [describes them](https://docs.berachain.com/nodes/quickstart). +Berachain sets its public RPCs to commercially typical usage limits. These endpoints are designed for end users sending transactions, not for running the backend of a service. Commercial projects should provision their own infrastructure or use paid services. -Another common choice is to operate in Docker/Kubernetes. +When choosing an RPC solution, you have several options. Free services from the Berachain community are available and listed on our [developer tools page](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers). Paid services usually price by request credits and redundancy tier; self-hosting shifts cost into compute, storage, and operational overhead. In practice, the "right" choice depends less on raw request count and more on your latency targets, failure tolerance, and whether your workload relies on expensive calls like log queries. -## 4. Reliability and Pricing +Paid providers build redundancy into their offerings. If you are stitching together multiple RPC backends yourself, whether for cost or redundancy, put a single proxy in front so your app talks to one endpoint and the proxy picks an upstream. [eRPC](https://github.com/erpc/erpc) is one option: it can automatically route around slow or erroring providers, retry some requests, and optionally cache common reads to reduce upstream load. -Berachain sets its public RPCs to commercially normal use limits. These endpoints are designed for end users sending transactions, not for running the backend of a service. Commercial projects should provision their own infrastructure or use paid services. +## Summary -When choosing an RPC solution, you have several options. Free services from the Berachain community are available and listed on our [developer tools page](https://docs.berachain.com/developers/developer-tools#rpc-infrastructure-providers). Public paid services typically cost around $42/month for 40M requests, providing roughly 30 requests per second sustained over the month. For a private RPC service you manage yourself, expect costs around $100/month for essentially unlimited requests, with hundreds of requests per second depending on your infrastructure provisioning. +Optimize your usage patterns before you spend money. Persistent WebSocket connections and `eth_subscribe` often reduce load and improve timeliness, but treat subscriptions as best-effort and reconcile after reconnects. For production traffic, use either a paid provider or a dedicated self-hosted node; if you self-host, treat it like a service: add [monitoring](/nodes/monitoring) and alerting, and consider a failover layer like eRPC. -Paid providers build redundancy into their offerings, but if you're assembling your own multi-provider setup, you'll want a layer that handles failover automatically. [eRPC](https://github.com/erpc/erpc) is one such tool: a fault-tolerant RPC proxy that sits in front of multiple upstreams and manages retries, circuit breakers, failovers, and hedged requests. It routes traffic to the fastest healthy provider, caches responses to reduce upstream load, and provides a single endpoint for your application regardless of how many backends you're actually using. From 58c1bdd91da50e7dc91f1a00f9ea37d305cc419e Mon Sep 17 00:00:00 2001 From: Camembear Date: Mon, 9 Feb 2026 17:24:17 -0500 Subject: [PATCH 4/4] pnpm format --- apps/core/content/nodes/self-hosted.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/apps/core/content/nodes/self-hosted.md b/apps/core/content/nodes/self-hosted.md index 47c58fdb..0ca80ee7 100644 --- a/apps/core/content/nodes/self-hosted.md +++ b/apps/core/content/nodes/self-hosted.md @@ -29,11 +29,11 @@ In addition to regular JSON-RPC queries, a new category of RPC call becomes avai Putting this together, we can identify anti-patterns and what to replace them with: -| Anti-pattern | Do this instead | -| ---------------------------------------- | -------------------------------------------- | +| Anti-pattern | Do this instead | +| ----------------------------------------------- | ----------------------------------------------- | | Short-lived HTTP connections without keep-alive | Enable keep-alive or use a persistent WebSocket | -| Polling `eth_blockNumber` for new blocks | `eth_subscribe` to `newHeads` over WebSocket | -| Calling `eth_getLogs` frequently | `eth_subscribe` for events over WebSocket | +| Polling `eth_blockNumber` for new blocks | `eth_subscribe` to `newHeads` over WebSocket | +| Calling `eth_getLogs` frequently | `eth_subscribe` for events over WebSocket | Subscriptions provide immediate notification of new data and can dramatically reduce load compared to polling. They do not replace `eth_getLogs` for historical backfills, and they are not a delivery guarantee. Production consumers still need reconnect and resubscribe logic, plus a robust way to detect and repair gaps. A common pattern tracks the last processed block and uses `eth_getLogs` to reconcile after reconnects. @@ -62,4 +62,3 @@ Paid providers build redundancy into their offerings. If you are stitching toget ## Summary Optimize your usage patterns before you spend money. Persistent WebSocket connections and `eth_subscribe` often reduce load and improve timeliness, but treat subscriptions as best-effort and reconcile after reconnects. For production traffic, use either a paid provider or a dedicated self-hosted node; if you self-host, treat it like a service: add [monitoring](/nodes/monitoring) and alerting, and consider a failover layer like eRPC. -