Private Filecoin RPC Endpoints on a Dedicated Node

A Filecoin RPC node is a server running a Filecoin client such as Lotus or Forest that exposes APIs your app uses to read chain data and broadcast messages. In practice, teams rely on a Filecoin node to serve dApps, wallets, indexers, explorers, and storage-deal tooling with stable, predictable access.

Both. Filecoin nodes expose the native Filecoin JSON-RPC (Filecoin.* methods) for chain, message, and storage operations, and through the FEVM they also expose the Ethereum JSON-RPC (eth_* methods). That means standard Ethereum tools like Hardhat, Foundry, and MetaMask work against your dedicated node alongside Filecoin-native tooling.

The FEVM uses chain ID 314 for Filecoin mainnet and 314159 for the Calibration testnet. Calibration is the most production-like testnet and is the recommended place to stage smart contracts and network upgrades before mainnet. A dedicated node can serve either network.

Either. Lotus is the Go reference implementation and the most production-tested. Forest is the Rust implementation from ChainSafe and is compatible with most of the Lotus JSON-RPC API. We deploy the client that fits your workload and can advise on the trade-offs for your read patterns and resource budget.

Choose a full node when you mainly need recent state, receipts, and current reads; it runs on a snapshot-pruned chain to keep storage manageable. Choose an archive node when you need deep historical state for analytics, explorers, or long-range backfills. A dedicated setup lets you pick the right tier without sharing limits.

Shared RPC endpoints throttle, vary in latency, and change policies without warning. A dedicated Filecoin node runs on single-tenant CPU, RAM, and NVMe, so your throughput and response times depend on your hardware headroom, not other tenants or shared quotas. You also control which Filecoin and FEVM methods are exposed.

Most failures trace back to storage I/O saturation, CPU contention, or too many concurrent WebSocket sessions. Filecoin chain state is large and grows continuously, so disk speed matters. Dedicated hardware removes noisy-neighbor contention, and local NVMe reduces read and write stalls, which is why teams move to a dedicated node when usage becomes production-grade.

Yes. You can scale up resources as load grows, add NVMe capacity for archive needs, and move to higher core counts for heavy concurrency. Because Filecoin chain and archive data grow continuously, we size storage with headroom and refresh snapshots so your endpoint stays stable as your product grows.

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.