> ## 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.

# Edit node configuration

> Tune a running node's config-file keys and CLI arguments from the UI — what you can override, what's protected, and how changes roll out

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](/docs/nodes/upgrade-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.

<Note>
  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.
</Note>

## Permissions

**Owner** and **admin** can save configuration changes. Members can open the dialog but can't submit. See [Roles and permissions](/docs/platform/roles-and-permissions).