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

# Executors overview

> What an executor is, how it connects to Novacula, and how to manage one

An **executor** is Novacula software you install on your own infrastructure. It runs your blockchain nodes and reports their status back to Novacula. Everything that happens to a node — start, config edit, version upgrade, stop, delete — is carried out by an executor.

You install **one executor per host or cluster**, and it shows up in the UI under **Executors**, where you connect, monitor, upgrade, and take it out of service.

## Two backends

Pick the backend that matches where you want to run nodes:

| Backend                                          | Runs on                                                           | Materializes a node as      |
| ------------------------------------------------ | ----------------------------------------------------------------- | --------------------------- |
| **[Agent](/recipes/provision-on-bare-metal)**    | A Linux host or VM (x86\_64; tested on Ubuntu 22.04+, Debian 12+) | A set of `systemd` services |
| **[Operator](/recipes/provision-on-kubernetes)** | A Kubernetes cluster (tested on 1.27+)                            | Pods managed in the cluster |

Both run the same node specs, so a node you define behaves the same way under either backend.

## Outbound-only

The executor is the only side that opens connections: it reaches out to Novacula over HTTPS to fetch its work and report status. Novacula never reaches into your network, and the executor needs **no inbound ports**. You can run it behind a firewall or NAT with only outbound internet access.

## Online and offline

The executor checks in with Novacula on a short interval. When it stops checking in, the UI marks it **offline** after about 30 seconds; once it resumes, it flips back to **online**. Its detail page shows the status alongside **last sync** (the time of its last check-in), **uptime** (how long the executor process has been running), and how long it has been **managed** — a freshly connected executor may show no uptime until it first reports.

## How an executor appears

Each executor shows as a row in **Executors** with its status, version, last seen, and the chains it can run. When you deploy a node, the wizard offers exactly the chains, networks, clients, and versions that executor declares — so you never see combinations it can't run. To unlock newer support, [upgrade the executor](/docs/executors/upgrade-executor).

## The executor detail page

Open an executor's row to see its detail page, organized into tabs:

* **Overview** — headline telemetry (managed-node count, how many are running, items needing attention, supported chains, and last sync with uptime), a **Version & Updates** panel with **Upgrade** and **Downgrade** actions, **Network Access** (reachability, firewall state, public IP), a **Resource Pressure** summary (CPU, memory, disk), and a **Managed Nodes** list.
* **Monitoring** — the host's resource usage (CPU, memory, disk) as charts over a time window.
* **Logs** — the executor's own operational logs, searchable in the UI, so you can diagnose a misbehaving executor without opening a shell on the host or reading pod logs.
* **Access** — the API key this executor is currently bound to, and its key usage; from here you can issue a new key for it.
* **Nodes** — the nodes this executor manages.
* **Capabilities** — the chains and clients (node components) the executor declares it can run; this is what the deploy wizard offers for it.

## What you can do

* **[Connect an executor](/docs/executors/connect-an-executor)** — bring one up from zero, from the **Connect Executor** flow.
* **[Upgrade an executor](/docs/executors/upgrade-executor)** — move it to a newer release from its row in **Executors**.
* **[Deactivate an executor](/docs/executors/deactivate-executor)** — revoke its API key or delete it.

## Where to start

* [Provision on bare-metal](/recipes/provision-on-bare-metal) or [Provision on Kubernetes](/recipes/provision-on-kubernetes) — backend-specific install detail.