Skip to main content

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.

Use the Deploy node wizard to provision a new blockchain full node onto one of your connected executors. The wizard has four steps; each step constrains the next, so options narrow as you progress.

​
Prerequisites

​
Steps

1

Target

Open Nodes → Deploy node and pick, in order:
  • Executor — only executors with capabilities matching the next fields appear.
  • Chain — Bitcoin, BSC, Ethereum, Sui, Tron. See Supported chains.
  • Network — for example mainnet, testnet, sepolia, signet. Available networks depend on the chain.
  • Node type — Full everywhere; Archive on Ethereum and BSC only.
  • Client + version — for two-role chains (Ethereum), pick an EL client and a CL client independently.
2

Resources

The wizard pre-fills CPU, RAM, and disk with the per-network defaults from the chain adapter — mainnet is consistently the heaviest, testnets are much lighter.You can raise or lower any field:
  • Storage size and storage class (Operator only) determine the persistent volume the node will use.
  • CPU request / limit and memory request / limit are honored as resource requests on Kubernetes and as cgroup-style limits on the Agent (best-effort).
Lowering defaults below the recommended minimum surfaces a non-blocking capacity warning. The node will still start, but you may see reconciliation churn or stalled sync.
3

Custom config

Optional. Two override surfaces, depending on the chain:
  • Config-file overrides — written into a chain-specific file (bitcoin.conf, fullnode.yaml, config.conf). Only keys on the per-adapter whitelist are accepted; managed keys (data-dir, RPC bindings, ports) are rejected at validate time.
  • CLI argument overrides — merged with the adapter’s managed --flag list. Forbidden flags are rejected.
Ethereum CL clients also accept a checkpoint-sync-url as a first-class field, letting the CL fast-sync from a trusted checkpoint provider instead of from genesis.See the per-chain page for the override matrix — for example Bitcoin or Ethereum.
4

Review and confirm

The review screen shows the final spec — every field you filled, plus all platform-managed values (ports, data-dir, init steps).An Advanced section exposes a few last-mile knobs the wizard pre-fills with safe defaults:
  • Service type (Operator only) — how the node’s RPC ports are published on the cluster:
    • ClusterIP (internal only) (default) — port reachable only from inside the cluster; expose externally through your own Ingress / gateway.
    • NodePort — Kubernetes opens a port on every node IP that forwards to the pod. Simple for self-hosted clusters.
    • LoadBalancer — Kubernetes provisions a cloud load balancer with a public IP. Costs money on managed clouds; only use when you actually want a public endpoint.
  • Restart policy (Agent only) — systemd restart behaviour for the underlying processes (e.g. always, on-failure).
  • Node ID — leave blank to auto-generate from chain + network + executor; supply a value if you want a specific id.
Confirm. The wizard creates the node at revision 1; the target executor picks it up on its next poll (typically within seconds) and starts reconciling.

​
What happens next

The node detail page becomes the source of truth:
  • Status — populated from the executor’s reporter loop, refreshed on each poll.
  • Logs — streamed live from each underlying process. See Node logs.
  • Monitoring — sync progress, peers, and per-process metrics. See Node monitoring.
To change anything after deploy — resources, config, or version — see Edit node configuration and Upgrade a node.