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 exampleini-sectioned,yaml, orhocon-append). - CLI arguments — extra flags appended to the client’s command line. Ethereum and Monad use this.
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, ormaxconnections. - 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.
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.