Skip to main content
Most of a node is decided when you deploy it. Three things can change afterwards, each from its own place on the node’s detail page: Everything else — chain, network, node type, which client runs each role, and the client’s config overrides — is fixed at deploy. To change any of it, delete the node and deploy a new one.

​
Edit resources

Open the node from Nodes, stay on the Overview tab, and use Edit resources on the Resources panel. The dialog lists one block per role, each labelled with its role, client, and version, so on a multi-process node (Ethereum’s execution + consensus pair, Monad’s three roles) you size each process separately. Per role you can set: Requests and limits are entered with a unit selector (cores or millicores, Gi or Mi), and each limit field shows the matching request underneath so you can see what you’re capping. Save resources stays disabled until something actually differs from the current spec. Saving updates the node’s desired spec, and the executor applies the change on its next reconcile.

​
Storage is Operator-only, and grows only

The Storage field appears only when the node runs on a Kubernetes Operator executor. On a bare-metal Agent there is no storage field — the node’s data lives in a directory on the host, not in a sized volume, so there is nothing to resize from here. On an Operator the dialog is explicit about the constraint: storage can be increased after launch, but Kubernetes PVCs cannot be shrunk. Plan an increase as a one-way move; to reduce a volume you have to redeploy the node.

​
What saving does not do

  • It does not move the node to a different executor — that needs a redeploy.
  • It does not change the node’s name or identity.
  • It does not keep a versioned history to roll back to. Edit again to change a value back.
Edit resources is offered only while the node is Running — a stopped, syncing, upgrading, errored, or deleting node doesn’t show it. Start the node to resize it.

​
Client config overrides

A node’s client config — config-file keys and extra CLI arguments — is set when you deploy, in the wizard’s Custom config step. It is not editable from the node afterwards: to change an override on a running node, redeploy it. The rest of this section describes what that step accepts, so you can plan a deploy (or a redeploy) with the right values. For the walkthrough, see Deploy a node.

​
Two kinds of override

A node accepts overrides in whatever form its client reads configuration, and the step shows only the surfaces that apply to your chain:
  • Config files — keys written into the client’s config file. Bitcoin (bitcoin.conf), Tron (config.conf), and Monad use this. Each file panel shows its format (for example ini-sectioned, yaml, or hocon-append).
  • CLI arguments — extra flags appended to the client’s command line. Ethereum and Monad use this.
Some chains expose no override surface at all; for those, the step says the chain has no custom config and you can skip ahead.

​
Config-file keys

In a Config files panel, each row is a Key and a Value.
  • Browse known keys lists the keys the chain commonly tunes, each with a type and a short description — pick one to add a pre-filled row. On Bitcoin, for example, dbcache (database cache in MiB), txindex, prune, or maxconnections.
  • Custom key adds a blank row so you can set any other key the client accepts.
  • Raw switches the panel to a free-text editor where you paste the file fragment in its native format. Toggle back to Guided for per-key rows.
Typed keys get the right input: a true/false selector for booleans, a numeric field for numbers. Panels that accept only documented keys are tagged allowlist.

​
CLI arguments

In a CLI arguments panel, each row is one argument, written as --flag=value or --flag value. Browse known flags lists the documented flags for that client — an Ethereum consensus client, for instance, accepts --checkpoint-sync-url to start from a trusted checkpoint state. Use Argument to add any other flag the client supports. Your flags are appended after the ones Novacula manages.

​
Protected keys

Some settings are owned by the platform and cannot be overridden — the data directory, RPC and P2P bindings, ports, the chain selection, and RPC credentials. Enter a protected key or flag and the form flags the row (“Novacula manages this key” for a config-file key, “<flag> is managed by Novacula” for a CLI flag) and blocks you until you remove it. Everything else is accepted, whether or not it appears in the known list. Each chain’s page lists the keys and flags it accepts and the ones it manages — see Bitcoin, Ethereum, or Tron, for example.

​
Permissions

Owner and admin can edit resources; members don’t see the action at all. See Roles and permissions.