Skip to main content
Igra is an EVM-compatible L2 anchored on the Kaspa DAG. Every Igra node runs two processes: a kaspad node that follows the underlying Kaspa network, and an igra-reth execution layer (a reth fork tailored to the Igra L2) that serves the standard Ethereum JSON-RPC. The two share a JWT secret over the internal Engine API, just like an Ethereum execution-layer / consensus-layer pair; that link is internal to the node and you don’t configure it. Igra is a container-only chain — both of its clients ship as images rather than binaries, so both processes always run as containers:
  • On a Kubernetes Operator executor, as pods in the cluster, like every other chain.
  • On a bare-metal Agent executor, as Docker containers on the host rather than as systemd services.
Either way you deploy it the same way, from the Deploy Node wizard against an executor that supports Igra.
Deploying onto an Agent, the wizard’s Runtime field locks itself to Docker — Igra’s only valid runtime — so there’s nothing to choose. See Runtime.
On an Agent, Novacula installs the Docker engine for you — it’s a prerequisite of the container runtime, not something you prepare in advance. Before an Igra node’s first launch the agent checks whether it can reach the Docker daemon; if it can’t, it adds Docker’s official package repository (pinned, with a checksum-verified signing key), installs docker-ce, enables the daemon, and joins itself to the docker group. The agent then restarts once so that group membership takes effect. The step is idempotent — a no-op on a host that already has a working Docker — and Docker is left in place when you delete the node.Auto-install covers Ubuntu hosts. On another distribution the step fails with an explicit message instead of guessing at your package manager: install the Docker engine yourself and make sure the agent’s user can reach the daemon socket, then redeploy.

​
Quick start on k3s

No full cluster? A lightweight distribution works too. k3s is a CNCF-certified, single-binary Kubernetes that stands up a working cluster in one command — enough to host the Novacula Operator and an Igra node.
1

Install a single-node k3s cluster

k3s ships a default local-path storage class, which the Operator’s PVCs can use. It stores data on the node’s own disk, so size that disk for Igra’s volumes (see Resource defaults below). This is fine for a test or galleon-testnet node; for a production mainnet node use a real CSI storage class instead.
2

Install Helm

The Operator ships as a Helm chart, so you need Helm:
3

Point your shell at the cluster

k3s writes this kubeconfig as root with 600 permissions. If you aren’t running as root, either use sudo, or install k3s with --write-kubeconfig-mode 644 (append it to the install command above) so kubectl and helm can read the file.
4

Install the Operator

Copy the Helm command from the Connect Executor screen in the UI — it comes pre-filled with your Hub URL, executor key, and the current version, so you don’t fill those in by hand. It looks like this:
Then confirm the Operator rolled out:
The executor row in the UI flips to online within seconds. See Connect an executor and the full Provision on Kubernetes walkthrough.
5

Deploy Igra

Open the Deploy Node wizard, pick Igra and a network, and deploy. See Deploy a node.

​
Networks

The wizard offers exactly the networks, clients, and versions the executor declares. Pick a network and the wizard pre-fills the resource and storage defaults for it. Igra has a single node type, full.

​
Clients

The two roles move in lock-step at the same version. kaspad runs with a co-located kaspa-rest-proxy helper that gives the HTTP-less node a readable REST surface for health probing; it’s part of the node and not something you configure.

​
Resource defaults

The wizard pre-fills these per network; you can raise them before deploying. kaspad is the heavier process — plan for a node well above 32Gi total RAM once both processes and the OS are accounted for.

​
Ports

The Ethereum JSON-RPC is served on :8545 (HTTP) and :8546 (WebSocket). Point your apps at these.

​
Configuration

Igra runs with a fixed, upstream-pinned configuration per network — there are no client config overrides to set when you deploy. The product picks the correct ports, chain identity, and bootstrap for the network you chose.

​
Sync

  • The execution layer receives blocks from kaspad over the internal Engine API; the L2 itself has no peer-to-peer chain-tip discovery.
  • Block Height and Sync Progress are derived by comparing the node’s local height against the public Igra explorer’s tip on each reporting cycle. This requires outbound HTTPS from the executor to the public explorer (explorer.igralabs.com). If your network blocks that egress, Sync Progress will report stale.

​
Monitoring

Open a node and select the Monitoring tab to read the common per-node metrics — Block Height, Peers, Sync Progress, plus EL Finalized Block and EL Safe Block extras — as charts. Kaspad-side health is surfaced too: Kaspad DAA Score (the kaspad chain height) and Kaspad Sync progress. See Node monitoring.

​
Common patterns

  • RPC endpoint — accept the defaults and expose :8545 (HTTP) and :8546 (WebSocket) to your apps. Check egress to the public Igra explorer is open, or Sync Progress won’t track.