Skip to main content
Ink is not currently offered in the deploy wizard. This page documents how a node is built for when it returns; you can’t deploy one today.
Ink is an OP-Stack L2 anchored on Ethereum. Every Ink node runs two processes: an op-reth execution layer and an op-node rollup client. They talk to each other over a JWT-secured Engine API that the platform manages — you never set it. Sequencer URL, op-node P2P bootnodes, and the L1 endpoints op-node derives the rollup from are all baked in per network, so a node finds the chain without extra configuration (see L1 endpoints). Ink is a container-only chain — both of its clients ship as images rather than binaries, so both roles 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.
Deploying onto an Agent, set Runtime to Docker in the wizard’s Target step. The field defaults to Systemd, which cannot run Ink — there are no binaries to install — so leaving it will fail. 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 Ink 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.

​
Networks and resources

Ink offers a single node type, full. The deploy wizard pre-fills resource and disk defaults:

​
Clients

One pinned client per role today. The deploy wizard offers exactly the client and version the executor declares.

​
Ports

​
L1 endpoints

op-node derives the L2 chain from Ethereum L1 — it does not sync purely from L2 peers. Novacula supplies that connection for you: the network carries default public L1 execution and beacon endpoints (ethereum-rpc.publicnode.com and ethereum-beacon-api.publicnode.com), so a node syncs out of the box with no L1 configuration. The node’s L1 execution and beacon endpoints are fields on the node spec rather than client flags, and the deploy wizard doesn’t surface them yet — a node deployed from the UI uses the public defaults. The related op-node flags (--l1, --l1.beacon, --l1.rpckind, --l1.trustrpc) are managed by the platform; don’t set them as overrides.
The public defaults are shared endpoints and rate-limited accordingly. A production Ink node is only as reliable as the L1 behind it, so if op-node stops making progress, L1 is the first thing to suspect. Talk to us if you need a node pointed at your own L1 — including an Ethereum node you already run on Novacula, which cuts egress and avoids third-party limits.

​
Config overrides

Set per-role overrides when you deploy — see Edit a running node. Each role (el for op-reth, rollup for op-node) passes through any flag the platform doesn’t already manage. The P2P bootnodes and static peer are baked in per network and managed for you, so --p2p.bootnodes and --p2p.static are rejected if you try to set them. The L1 flags above are managed too.

​
Sync

op-node fetches batches from L1 and op-reth applies them through the Engine API. There is no checkpoint-sync URL or snapshot-restore option — initial sync is from genesis via the L1-derived chain, so a fresh node takes time and the disk default reflects full history. A healthy, reachable L1 endpoint is the gating factor for sync; if op-node can’t reach L1, it can’t make progress.

​
Monitoring

Status, height, peers, sync progress, and disk combine both processes’ readings — see Node monitoring. Both roles report per-stage detail, which is what you need when a fresh node looks stuck:
  • op-reth pipeline progress — per-stage series for headers, bodies, execution, merkle unwind, and prune, each as entities processed against the stage total. During initial sync the node works through these stages in order, so a stage sitting still tells you exactly where it is.
  • op-node reference heads — the rollup’s L1 origin for the unsafe L2 head, the L1 head it sees, and the L2 cross-unsafe head. Since op-node derives the L2 from L1, a stalled L1 head points at your L1 endpoint rather than at the node.
Sync progress reflects the execution layer’s real position, so a node whose op-reth is still behind is not reported as fully synced.

​
Common patterns

  • RPC provider for Ink mainnet — accept the defaults and serve the node’s HTTP and WebSocket RPC to your apps.