Skip to main content
Open the node’s detail page and go to the Configuration tab. Scroll to the Config section: the Config overrides panel shows the keys and arguments currently applied on top of the defaults. Click Edit to change them (or Add overrides if there are none yet) to open the Edit configuration dialog. Overrides let you tune how the node’s client runs — cache sizes, indexes, peer limits, sync flags — without redeploying. Everything else about the node (chain, network, node type, client, and version) is fixed at deploy. To change those, see Upgrade a node or redeploy.

Two kinds of override

A node accepts overrides in whatever form its client reads configuration. The dialog 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; for those, the dialog says the chain has no custom config to edit.

Edit 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. For example, on Bitcoin you can set 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 directly in its native format. Toggle back to Guided to return to per-key rows.
Typed keys get the right input: a true/false selector for booleans, a numeric field for numbers.

Add 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. For example, an Ethereum consensus client accepts --checkpoint-sync-url to start syncing from a trusted checkpoint state instead of from genesis. Use Argument to add any other flag the client supports.

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 the RPC credentials. If you type a protected key or flag, the dialog flags the row — “Novacula manages this key” for a config-file key, “<flag> is managed by Novacula” for a CLI flag — and blocks Save changes until you remove it. Everything else is accepted, whether or not it appears in the known-keys list.

Save and roll out

The dialog footer shows an overrides count and a Δ changes badge so you can see the size of the edit at a glance. Save changes stays disabled until something actually differs from the current config. When you save, the node restarts with the new configuration. The restart is in place: the data directory is preserved, so the node does not re-sync from genesis. Watch the node return to running on the detail page. A few things 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 you can roll back to. Edit again to revert a key, or clear it.
Resource requests and limits (CPU, memory, disk) and storage class are set at deploy and can’t be changed here — redeploy if they need to change.

Permissions

Owner and admin can save configuration changes. Members can open the dialog but can’t submit. See Roles and permissions.