Skip to main content
Every node serves RPC, but you decide how reachable that endpoint is. RPC exposure is a per-node setting with three modes — Local, Direct, and Public domain — and it applies the same way you describe it on both backends, with each backend using its native mechanism underneath. This page is about the RPC endpoint, which has all three modes. The node’s other ports are simpler: P2P is published directly by default so the node can peer (you can close it, but it can’t be proxied), and metrics always stay internal to the host or cluster.

​
Where to set it

  • At deploy — the Network step of the Deploy node wizard, under Network & Access.
  • Any time after — open the node, go to the RPC tab, and use its Edit action (dialog: Edit RPC exposure).
Exposure is desired state like everything else: change it and the executor reconciles to match on its next check-in. You don’t need to redeploy.

​
Modes

Pick the lightest mode that fits: Local for a node only other in-network workloads consume, Direct for a port you restrict yourself at the network edge, Public domain to publish a hardened public endpoint with a hostname and TLS. A node that serves a pool belongs in Local as well: the pool’s gateway reaches it from inside the host or cluster, so nothing is lost by closing the port, and the pool domain stays the only way in.

​
Direct

Direct publishes the RPC port so clients reach it on the executor’s network. How that happens differs by backend:
  • Agent (bare-metal) — binds RPC to 0.0.0.0 on the host, so any caller who can route to that host reaches the port.
  • Operator (Kubernetes) — publishes a Service whose type you choose:
    • NodePort (default) — opens a port on every cluster node. Reaching it from outside still depends on the node having a routable IP and the firewall allowing the node-port range.
    • LoadBalancer — provisions a cloud load balancer.
Direct does not restrict callers. Novacula publishes the port and nothing more, on either backend — so who may reach it is entirely yours to decide, at your host firewall, security group, cloud load balancer, or NetworkPolicy. Confirm the restriction holds from an outside host before pointing anything at a Direct endpoint, and prefer Public domain where you want authentication and a rate limit you don’t have to build.

​
Public domain

Public domain serves the node’s RPC through a managed gateway, so clients connect to a clean https://<domain> instead of a raw host:port. You provide:
  • RPC domain (required) — the hostname clients will use, e.g. rpc.example.com. Point its DNS at the executor’s public address — the Agent host’s public IP, or the cluster’s ingress external IP on Operator. The dialog shows the exact record to create once the executor reports its address. Novacula does not manage DNS zones.
  • TLS — Auto (a certificate is issued and renewed for you via cert-manager; your cluster needs a configured issuer), Manual (you supply a TLS Secret), or Off (HTTP only, for private networks).
  • Rate limit (required) — requests per second the gateway allows.
  • Auth — RPC key (the gateway requires a valid RPC key) or None (the domain is open).
On the Operator backend this materializes as an Ingress (plus cert-manager wiring for Auto TLS); the operator chart must grant the ingress and cert-manager RBAC (shipped in the current chart — see Provision on Kubernetes). On Agent, the gateway runs as a managed service on the host. The node’s RPC tab reports DNS and certificate status so you can see when the public endpoint is actually live.

​
RPC keys

When a proxy endpoint uses RPC-key auth, access is gated by a per-node RPC key — the bearer credential your clients present to the proxied endpoint. There is one active key per node. You can issue it at deploy time (Issue RPC key after deploy) or from the node’s RPC tab later (Issue RPC key after save). The key’s secret is shown once, at the moment the executor mints it — copy it then, because Novacula stores only a hash and can’t show it again. The key itself is reusable for as many requests as you like; issuing a new key rotates the old one out (it’s revoked on the next sync). Present the key as a bearer token in the Authorization header of each request to the proxied endpoint:

​
Reading the endpoint

The node’s RPC tab shows the endpoint clients should actually use, resolved to a reachable address rather than an internal hostname:
  • Direct — protocol://host:port, where host is the node’s verified public IP. The tab marks whether the endpoint is externally reachable and offers copy / open actions. Novacula detects and verifies the address for you; where it can’t, set one from the exposure dialog — enter a public IPv4 literal and Check it, and the Hub verifies the address reaches this node before it’s saved. See Public IP verification.
  • Public domain — https://<domain>, always external, with certificate status (pending, ok, or failed) and a DNS-record hint.
If a direct endpoint can’t be resolved to an external address yet, the tab says so (for example a LoadBalancer still showing <pending>); give the executor a cycle to report, and check your cloud/firewall if it persists.

​
Permissions

Changing a node’s exposure is a configuration change, so it requires the Owner or Admin role — same as editing a running node. Members have read-only access. See Roles and permissions.