| Control plane architecture | Novacula operates the Hub as a cloud service. Customer-side Agents and Operators run the nodes on Linux hosts, virtual machines or Kubernetes. | The customer installs and runs the Control Panel, Keycloak, PostgreSQL, Temporal and the blockchain workloads inside their own Kubernetes cluster. | Novacula operates the management service for you. Chainstack makes the customer responsible for hosting the complete management layer. |
| Deployment environments | Agent on x86_64 Linux hosts and virtual machines, running nodes as systemd units or Docker containers. Operator in Kubernetes. | Kubernetes only: k3s, upstream Kubernetes, EKS, GKE or AKS, with a storage class that supports dynamic provisioning. k3s on Ubuntu 22.04 or 24.04 is the tested configuration. | Novacula manages standalone hosts without Kubernetes. Chainstack requires a Kubernetes cluster before the first node. |
| Node types | Full, archive, pruned, lite and blob-serving node types, chosen per node where the chain supports them. | Presets fix the client and the sync mode per network; CPU, RAM, storage and client settings can be adjusted before deploy. There is no user-selectable archive or pruned option. | With Novacula you decide what kind of node you run. With Chainstack the preset decides the client and the mode; you size it. |
| Serving several nodes behind one endpoint | A pool puts several nodes behind one domain and one TLS certificate. Requests go only to members the executor sees running, healthy and synced. A member that stops meeting that bar leaves rotation while the address stays the same. A request that never reached a member is retried on the next one. The pool endpoint serves HTTP JSON-RPC only. | Load balancing across self-hosted nodes is planned, not shipped. Endpoints are internal Kubernetes service addresses; putting several nodes behind one address is left to a LoadBalancer, NodePort or Ingress the customer configures. | Novacula ships the single-endpoint, health-aware failover layer. With Chainstack Self-Hosted it is the customer’s to build in Kubernetes. |
| 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, and TLS with automatic ACME certificate issuance for the pool domain. | Node endpoints are plain in-cluster HTTP and WebSocket with no keys, rate limits or TLS. Exposing them safely is the customer’s job. | Novacula gives you a customer-facing RPC endpoint out of the box. Chainstack gives you an internal Kubernetes service address that you expose yourself. |
| Client upgrades | Every version change is a checked transition: the Hub says whether it is in place, needs a resync or is blocked, and whether it is security-urgent, recommended or optional. An automatic upgrade policy applies a chosen channel inside a daily window. A failed in-place upgrade rolls back on its own. | The console notifies when a newer client version exists, and client image updates ship with Control Panel releases. Configuration changes are applied as tracked revisions. No rollback of a node client upgrade is documented; rollback exists for the Control Panel upgrade only. | Novacula lets you automate client upgrades with a safety net: a checked transition, a chosen channel and window, and automatic rollback. Chainstack notifies you of new versions and delivers client updates with its Control Panel releases. |
| Monitoring and alerting | Node health, sync, peers, RPC activity, resource usage, metrics and process logs in the Hub, with ad-hoc PromQL per node. Preset alerts, no PromQL to write, delivered to Slack, Microsoft Teams, Telegram or a webhook, with an incident feed in the Hub. | An optional in-cluster stack: Grafana, VictoriaMetrics, VMAgent, VMAlertmanager, the VictoriaMetrics operator, a Chainstack node exporter, the Prometheus node exporter and kube-state-metrics. Alert rules and delivery channels are not shipped; the customer exposes Grafana and configures them. | Both give node-level visibility. Novacula also gives you working alerts on day one. With Chainstack you run the observability stack and write the alerting yourself. |
| Operational overhead | Novacula operates the Hub. You operate your hosts, executors, storage, networking and the nodes. The Operator is one Deployment with a namespaced Role. | You operate the Kubernetes cluster, the Control Panel with its database, orchestration and identity components, storage, the observability stack, upgrades and the nodes. The Control Panel alone needs about 5 cores, 6 GiB of memory and 15 GB of storage before the first node. | Novacula reduces the management infrastructure your team must run. Chainstack gives more direct control with more operational responsibility. |
| Control-plane availability | Executors connect outbound to the Hub and keep the last desired state. If the Hub is temporarily unavailable, nodes keep running and pool endpoints keep serving; Hub-dependent operations such as ACME issuance resume when it returns. | Management is available while the customer-operated cluster and Control Panel are healthy. | Novacula separates node runtime availability from Hub availability. |
| Running without a control plane | The Operator can run from Node custom resources alone, with no Hub connection, for GitOps-style clusters. | The Control Panel is required; there is no declarative or headless mode. | Novacula fits an existing GitOps workflow. Chainstack adds a control panel you must keep. |
