> ## 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. # Deploy a node > Walk through the Deploy node wizard — Target, Resources, Custom config, and Review. The Deploy node wizard provisions a new blockchain full node onto one of your connected executors. It has four steps — **Target**, **Resources**, **Custom config**, and **Review** — and each step constrains the next, so your options narrow as you go. The wizard only ever offers what the chosen executor declares: its chains, networks, clients, and versions. If a combination you want is missing, [upgrade the executor](/docs/executors/upgrade-executor) first. ## Before you start * A connected, online executor. See [Connect an executor](/docs/executors/connect-an-executor). * A role that can deploy: **owner** or **admin**. See [Roles and permissions](/docs/platform/roles-and-permissions). To open the wizard, go to **Nodes** and select **Deploy node**. ## Steps Choose where the node runs and which network it joins. * **Executor** — pick the executor to host the node. Offline executors are disabled. (Hidden when you start the wizard from a specific executor — it's already chosen.) * **Chain** — only the chains this executor supports appear. See [Supported chains](/docs/chains/overview). * **Network** — for example `mainnet`, `signet`, `sepolia`, `nile`. The list depends on the chain. * **Node type** — usually `Full`; **Bitcoin** and **BSC** also offer `Pruned` (less disk, no full history). When a chain has only one type, this is fixed for you. Then, under **Client** (or **Clients** for multi-role chains like Ethereum), pick the client and **Version** for each required role. Ethereum, for example, has separate execution-layer and consensus-layer roles, each with its own client and version. When a role offers a single client or version, it's filled in and locked. The **Storage** and **Resources** sections come pre-filled with recommended values for your chain, network, node type, and client — recommended is selected automatically, and `mainnet` is consistently heavier than testnets. * **Storage** — on a Kubernetes executor, choose a **Storage class** for the disk. Each declared volume has a size; keep the recommended value or switch on **customize** to set your own. * **Resources** — per role, set the **CPU request** and **Memory request**. Switch on **customize** to also set separate CPU and memory **limits** (otherwise limits match requests). These map to Kubernetes resource requests/limits on the Operator and to process limits on the Agent. On a bare-metal Agent the wizard checks the host's live capacity. If your requests exceed what's available, it shows a capacity warning naming the resource, what's needed, and what's free. You can still deploy, but the node may not start cleanly. Optional. Overrides are validated against the selected chain; Novacula-managed settings (data directory, RPC bindings, ports) can't be overridden. Chains that expose no override surface show a short notice and you can skip ahead. * **Config files** — set keys in a chain-specific file (for example `bitcoin.conf`). Use **Browse known keys** for documented keys with guided values, or **Custom key** for anything else. Some formats accept only known keys — those panels are tagged **allowlist**. Toggle a panel between **Guided** and **Raw** to paste raw file text instead. * **CLI arguments** — append extra process arguments with **Browse known flags** or **Argument**. They're added after Novacula's managed flags; allowlist-only processes accept known flags only. For the exact keys and flags each chain accepts, see its page — for example [Bitcoin](/docs/chains/bitcoin) or [Ethereum](/docs/chains/ethereum). A summary panel shows the node you're about to create. An **Advanced** section holds optional settings for exposure, recovery, and naming — all pre-filled with safe defaults: * **Network exposure** — choose how the node's **RPC** is published: **Local** (internal only), **Direct** (publish the port, optionally restricted to an IP allowlist), or **Public domain** (serve it through a managed gateway with a domain, TLS, rate limit, and optional RPC-key auth). P2P and metrics aren't proxied. You can set this here and change it any time afterward. See [RPC exposure](/docs/nodes/rpc-exposure) for the full model, the Agent-vs-Operator differences, and how to read the resulting endpoint. * **Restart policy** *(Agent only)* — restart behaviour for the underlying processes: `On failure` (default), `Always`, or `Never`. * **Node ID** — leave empty to generate one from chain and network (plus a short random suffix), or type your own. On a bare-metal Agent, the Review step warns if the **same chain already runs on the same physical host** — including via a different Agent executor sharing that host — because two same-chain nodes on one host tend to collide on ports, resources, or data directories. **Deploy** stays blocked until the host's node inventory has loaded and you acknowledge the warning. Operator (Kubernetes) deployments aren't affected, since each node runs in its own pod. Select **Deploy**. The target executor picks up the new node on its next sync — typically within seconds — and starts running it. ## After you deploy The node detail page is where you watch and manage the node: * **Status** — reported by the executor and refreshed each sync. * **Logs** — streamed live from each process. See [Node logs](/docs/nodes/logs). * **Monitoring** — sync progress, peers, and per-process metrics. See [Node monitoring](/docs/nodes/monitoring). To change anything later — resources, config, or version — see [Edit node configuration](/docs/nodes/edit-configuration) and [Upgrade a node](/docs/nodes/upgrade-node).