What is a managed RPC?
A managed RPC provider runs blockchain nodes and gives your application an endpoint.
You use that endpoint to read balances, query transactions, retrieve logs or submit signed transactions. The provider handles the infrastructure behind it, including node synchronization, software updates, monitoring and capacity.
Infura, QuickNode and Alchemy are common examples. Their products may include shared endpoints, usage-based plans, fixed-capacity services or dedicated clusters. The exact model differs, but the provider operates the underlying nodes.
Managed RPC works well when you need to launch quickly, traffic is still small or unpredictable, or your team does not want to maintain blockchain software.
The trade-off involves both control and risk management. The provider decides which chains, clients, versions, methods, regions and limits are available.
What changes when you self-host?
Self-hosting means the node runs on infrastructure controlled by your company. That may be a bare-metal server, a virtual machine (VM) on DigitalOcean, Amazon Web Services (AWS), or Google Cloud, or a Kubernetes cluster. Your applications connect to your own endpoint instead of infrastructure operated by an RPC provider.
You gain control over the client, version, configuration, data, network access and upgrade timing. Your team also oversees the node throughout its lifecycle.
Your team must deploy the client, allocate resources, secure the endpoint and complete the initial sync. After that, it must monitor block height, peer count, storage, memory, process health and sync status across different tools and chains.
A running process is not always a healthy node. It can fall behind the network, lose peers, exhaust disk space or keep returning stale data without crashing.
Hard forks add deadlines. Every affected node must run a compatible client version before the network changes. Across several blockchains, this becomes a separate operating process for every client.
Ethereum shows how a multi-process node can add operational complexity. In Novacula, each Ethereum node runs two roles: Geth as the execution-layer (EL) client and Lighthouse as the consensus-layer (CL) client. Novacula deploys and manages them together, including the authenticated Engine API connection between them.
Self-hosting gives you more control, while your team also manages the node’s operational lifecycle.
Where does Novacula fit?
Novacula is an automated self-hosted node-management platform.
The nodes run on your infrastructure. Novacula manages supported deployment and operational tasks through its control plane and customer-side executors, without visibility into your RPC traffic, private keys, or blockchain data inside your perimeter.
There are two executor types:
- Agent runs node processes as systemd services on Linux servers or virtual machines.
- Operator runs them as pods in Kubernetes.
You choose the blockchain, network, client version, resources, configuration and RPC exposure in the Novacula control plane. The executor then keeps the real workload aligned with that desired state.
This is the central difference between the three models:
- Managed RPC moves both the nodes and their operation to a provider.
- Traditional self-hosting keeps both the nodes and the operational work with your team.
- Novacula keeps the nodes on your infrastructure while standardizing supported operations.
What stays inside your infrastructure?
The executor connects outbound to the Novacula control plane, so you do not need to open an inbound port for node management. The control plane can be hosted by Novacula in the cloud or deployed as a standalone system inside your environment under an Enterprise plan.
The executor sends operational information such as health, sync status, resource usage and logs you choose to stream. RPC traffic, private keys and blockchain data remain on your hosts.
If the control plane becomes unavailable, existing nodes continue running and serving RPC. New deployments, configuration changes, version updates and lifecycle actions resume when the executor reconnects.
The control plane coordinates the workload. It does not host the node processes.
What does Novacula manage today?
Novacula handles supported parts of node operations, including deployment, process management, resource defaults, sync monitoring, metrics, logs, snapshots where available, alerts and incident tracking.
It supports full, light and archive node deployments, depending on the chain and client. Validator node support is planned.
For Ethereum, Novacula manages Geth and Lighthouse together, including the Engine API, JSON Web Token setup and checkpoint sync.
The current support matrix covers nine chains: Bitcoin, BNB Smart Chain, Ethereum, HyperLiquid, Igra, Ink, Monad, Sui and Tron. Available node types and deployment options depend on the chain, executor and release version.
How do the three models compare?
| Area | Managed RPC | Traditional self-hosting | Novacula | What it means for you |
| Infrastructure | Provider-operated | Customer-controlled | Customer-controlled | You decide whether the nodes must stay inside infrastructure you choose |
| Deployment | Provider | Internal team | Novacula executor | You avoid manual client setup within Novacula’s supported matrix |
| Monitoring | Provider | Internal team | Novacula | Sync and resource health appear in one operating interface |
| Client control | Depends on provider and plan | Full | Within supported clients and versions | You gain more control than standard RPC without taking on every client |
| Operational workload | Low | High | Lower than manual self-hosting | Your team still owns infrastructure, but not every chain-specific task |
| Chain coverage | Provider catalogue | Any chain your team can operate | Novacula support matrix | Coverage must match your current and planned workloads |
| RPC endpoint | Provider endpoint | Your endpoint | Your node, with configurable exposure | Applications can connect to infrastructure under your control |
Is Novacula an alternative to Infura, QuickNode or Alchemy?
It can address part of the same data consuming need, but it is not the same type of product.
Infura, QuickNode and Alchemy operate blockchain infrastructure and sell access to it. Depending on the service, that infrastructure may be shared or dedicated.
Novacula manages nodes running on infrastructure supplied by the customer.
Your application still uses standard RPC methods in both cases. What changes is where the nodes run, who controls the servers and who handles the daily operations.
For some teams, Novacula may replace part of a managed RPC workload. For others, it may work beside an existing provider.
A managed endpoint can remain available for failover, temporary capacity or chains that are not part of the current Novacula matrix.
Ownership and redundancy are not opposites.
When does each model make sense?
Use managed RPC when:
You need blockchain access immediately, traffic is small or difficult to forecast, and the provider’s chains, methods and limits fit your application.
It is also useful when occasional access across many chains matters more than controlling the underlying infrastructure.
Use traditional self-hosting when:
You need a custom node setup for a specific use case, such as an unsupported chain, client, version, or configuration. If Novacula supports the setup you need, it provides a standardized way to deploy and operate the node.
Use Novacula when:
Your nodes must run on infrastructure you control, but you do not want to build a separate operating system for every blockchain client.
It fits teams using Linux servers, virtual machines, Kubernetes or a mixed fleet, provided the current support matrix covers their requirements.
How should you compare cost?
There is no universal point where self-hosting becomes cheaper than managed RPC.
The result depends on the workload and what you include in the comparison.
For managed RPC, count the subscription, usage, throughput, regions, archive access, support and dedicated capacity.
For traditional self-hosting, count servers, storage, bandwidth, monitoring, redundancy, engineering time, upgrades and incident response.
For Novacula, count your infrastructure, the internal work that remains and Novacula’s commercial price after beta.
Novacula Core is free during beta. Infrastructure costs remain between you and your hosting provider. General availability pricing will be announced ahead of general availability.
A claim such as “80% cheaper” has no meaning without a defined chain, traffic level, redundancy plan, provider package and engineering baseline.
Frequently asked questions
What does RPC mean?
Remote procedure call is the interface an application uses to communicate with a blockchain node.
It can read blockchain data, query a balance, retrieve a transaction or submit a signed transaction.
Is Novacula a managed RPC provider?
No. Managed RPC providers operate the underlying nodes. Novacula manages supported nodes running on customer-controlled infrastructure.
Does Novacula remove all DevOps work?
No. Your team still manages infrastructure, network policy, security, capacity and application integration.
Novacula reduces blockchain-specific deployment and operational work within its supported matrix.
Do I need Kubernetes?
No. The Agent runs nodes on Linux servers and virtual machines. The Operator is available for Kubernetes environments.
Can I keep my current RPC provider?
Yes. A managed provider can remain part of a hybrid setup for failover, temporary capacity or additional chain coverage.
What happens if Novacula becomes unreachable?
Existing nodes continue running and serving RPC. New deployments and management changes wait until the executor reconnects.