> ## Documentation Index > Fetch the complete documentation index at: https://docs.novacula.io/llms.txt > Use this file to discover all available pages before exploring further. # Novacula vs Infura Infura provides managed blockchain APIs that remove the need to operate the underlying node infrastructure. Novacula is built for teams that want to deploy and manage blockchain nodes on infrastructure they control, with direct visibility into node health and operations. ## **Novacula vs Infura: Compare Infrastructure, APIs and Operations** | Feature | Novacula | Infura | What this means for you | | :- | :- | :- | :- | | Infrastructure and deployment | Nodes run on infrastructure your team controls: bare metal, virtual machines or Kubernetes. The Hub deploys, configures and monitors them; Agents and Operators on your side run them. | Infura provides managed API access to supported networks and describes its RPC layer as progressively decentralizing through its Decentralized Infrastructure Network (DIN). There is no dedicated, self-hosted or bring-your-own-infrastructure option. | Novacula is for teams that want to own the node environment. Infura removes the need to operate nodes. | | Where your requests go | Requests are served by your own nodes. The Hub receives per-request metadata only: method, outcome, byte counts and duration. Request bodies never leave your infrastructure. | Every request and response passes through Infura’s infrastructure. | With Novacula the request path is your nodes and your clients; only per-request metadata reaches the Hub. | | Client choice and upgrades | You choose the client and the pinned version per node, for example geth or reth on Ethereum. Every version change is a checked transition: in place, resync or blocked, and security-urgent, recommended or optional. An automatic upgrade policy applies a channel inside a daily window, and a failed in-place upgrade rolls back on its own. | IInfura does not document which clients run behind its endpoints or any way to choose or pin a version. web3\_clientVersion returns the serving client's version string. | Novacula gives you control over what runs and when it changes. With Infura you can read the client version but not choose or pin it. | | Debug and trace access | Read-only debug tracers and trace methods are served from your own nodes on every network the client supports. Method and range limits are your node's own. | debug methods are documented only for HyperEVM, Linea, Mantle and Scroll, not for Ethereum. trace methods are documented for Ethereum, Linea and HyperEVM, in open beta for paying customers. eth\_getLogs is capped at 10,000 results and 10 seconds per query. | Novacula serves whatever your client supports. Infura’s method surface depends on the network and the plan. | | Endpoint reliability | A pool puts several of your own nodes behind one domain and one TLS certificate. Unhealthy or unsynced members leave rotation automatically, and a request that never reached a member is retried on the next one. The pool endpoint serves HTTP JSON-RPC only. | Endpoints are backed by Infura’s fleet. Failover protection to a partner provider is available only on Arbitrum, Avalanche C-Chain, Optimism and Polygon, on paid plans, and only per request through an opt-in HTTP header. | Novacula’s failover is built into every pool. Infura’s is a per-request option on four networks. | | Rate-limit behavior | A throttled request gets 429 with Retry-After and X-RateLimit headers that name the limit, the remaining budget and the reset time. | Throughput limits return 429 with an Infura event code; exhausting the daily credit quota returns 402, halts service for the rest of the day and severs WebSocket connections. No Retry-After header is documented. | Novacula tells the client exactly when to retry. | | Endpoint access control | Pool keys, an optional guest allowance with pool-wide and per-IP limits, per-key rate limits, node-control RPC methods blocked at the gateway, on your own domain with automatic ACME certificate issuance. | Per-key allowlists for origins, user agents, contract addresses and methods, up to 30 entries each, and per-key credit limits. No IP allowlist. | Novacula lets you publish an RPC endpoint under your own domain, with or without keys. | | Operational visibility and alerts | Node health, synchronization, peers, resource usage, metrics and process logs in the Hub. Preset alerts, no query language to learn, delivered to Slack, Microsoft Teams, Telegram or a webhook. | Dashboard stats on request volume, the busiest methods and successful and failed requests, for up to the last 30 days. Alerts by email only, at 75, 85 and 100 percent of the daily credit quota. | Novacula watches the nodes themselves and alerts you where your team already works. Infura watches your usage of its service. | ## **Novacula vs Infura FAQs** Novacula is designed for teams that want to run and manage blockchain nodes on infrastructure they control. Infura provides managed blockchain APIs without requiring teams to operate the underlying node infrastructure. Not necessarily. Novacula and Infura use different infrastructure models, and teams can use self-managed nodes alongside third-party managed RPC services when that architecture fits their requirements. Your team controls the infrastructure where the blockchain nodes run. Novacula provides the Hub for deployment, monitoring and supported lifecycle operations. Novacula focuses on node-level health, synchronization, peers, resources, metrics and process logs, with preset alerts delivered to Slack, Microsoft Teams, Telegram or a webhook. Infura focuses on request volumes and method-level activity through its managed service, with email alerts on credit usage. Infura uses plan-based daily credit quotas: 3 million credits a day on Core, 15 million on Developer and 75 million on Team, with custom quotas on Enterprise. API requests consume different amounts of credits depending on their computational complexity. Figures are as published in September 2026. Novacula may be a better fit for teams that want direct control over where nodes run, need node-level operational visibility, want RPC traffic to stay inside their own infrastructure, or need debug and trace methods on networks where Infura does not offer them. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.