Private Flow RPC Endpoints on a Dedicated Node

A Flow RPC node is the server layer your application uses to read chain data and submit requests on Flow. On this network, that can mean a Flow Access Node for native Flow access, an Observer Node for lighter local read access, or an EVM Gateway for Ethereum JSON-RPC on Flow EVM. We treat a dedicated Flow RPC node as private infrastructure for teams that want their own resources, their own control path, and fewer limits than shared public endpoints.

They solve different jobs. An Access Node is Flow's main external gateway for transactions and state queries. An Observer Node gives you a verified local copy of block data and can help scale endpoint reads without staking. The EVM Gateway is the only Flow node type that accepts EVM client connections and serves Ethereum JSON-RPC for Flow EVM applications. We usually recommend the role based on your app path, read pattern, and traffic shape, not by forcing one generic build.

Choose dedicated when public limits start shaping your product. Shared endpoints are useful for testing and early development, but Flow's own docs say high-call-volume apps may hit rate limits and can benefit from running their own EVM Gateway to remove them. Your app gets isolated CPU, RAM, disk, and networking instead of competing inside a public pool. That is where a serious Flow RPC provider starts to differ from free or shared access.

Move when your users start feeling the limits. That usually shows up as slower reads, burst-time instability, retries, timeout handling, or a need for stricter control over uptime and recovery. We also suggest moving once you need environment separation, region placement, or custom security rules around your RPC path. Public endpoints are good for getting started. A dedicated Flow RPC node is the better fit once the node becomes part of your production path.

If your app speaks native Flow through the Access API, you are usually looking at an Access Node or an Observer-led setup. If your app speaks Ethereum JSON-RPC through MetaMask, ethers, viem, or Solidity tooling, you are usually looking at the EVM Gateway. We help you map that choice to your product before you deploy. That matters because Flow is not a one-role chain, and your server plan should match the real request path.

Yes, that is the main idea behind Flow EVM. Flow's docs describe it as EVM-equivalent, and the official quickstart uses Hardhat. The EVM Gateway implements Ethereum JSON-RPC, and Flow also provides an FCL Ethereum Provider that handles wallet-facing methods such as eth_requestAccounts, eth_accounts, and eth_sendTransaction. Method support is broad, but not every JSON-RPC method is available, so we advise checking method fit before launch if your app depends on edge cases.

It depends on the role. Flow's current provisioning guide starts Access Nodes at 8 CPU cores, 32 GB RAM, and 750 GB disk, Observer Nodes at 2 CPU cores, 4 GB RAM, and 300 GB disk, and EVM Gateway at 2 CPU cores, 32 GB RAM, and 30 GB disk. Flow also says bare metal should be provisioned above the minimum CPU and memory where possible. That is why we usually steer production buyers toward NVMe storage, RAM headroom, and stronger uplinks when sizing a Flow RPC node for live traffic.

Yes. We expose root, KVM, and IPMI access on dedicated infrastructure, and we include DDoS protection at the server layer on our dedicated RPC offer. That gives your team direct control over reboots, recovery work, reinstalls, boot-level checks, and day-to-day node operations. If you do not want that much hands-on work, we also offer managed and unmanaged paths so you can choose the right operating model for your team.

No. Unlike shared RPC providers that bill per "compute unit" and throttle you past a quota, a dedicated node is a flat monthly price with unlimited requests and zero overages. One node equals all the throughput your hardware can serve. That makes budgeting predictable and removes the surprise bills that come with usage-based RPC pricing.

Shared RPC pools serve thousands of customers from pooled infrastructure, so you inherit rate limits, noisy-neighbor latency, and compute-unit billing. A RedSwitches node runs on single-tenant bare metal that is yours alone: reserved CPU, RAM, and NVMe, a dedicated 10/25 Gbps port, and a private endpoint you control. Performance tracks your hardware, not another tenant's traffic.

No. We provision from current snapshots so your node is live in hours rather than syncing from genesis for days. You can run it yourself with full root access, or choose our fully managed option where our engineers handle the sync, updates, and monitoring. Either way you receive a working private endpoint, not an empty server.

Yes. With 20+ Tier III locations across the US, EU, Asia, and Australia you can place your node in the same region as your users or a chain's sequencer to cut round-trip latency. Tell us your target region and we will recommend the closest facility. You can also run multi-region nodes for redundancy and split read and write endpoints.