Deployment

Every Tenzro operator runs the same binary, tenzro-node. One node can take any set of roles under one identity and one stake: validator, RPC provider, model (AI) provider, compute, storage, TEE, edge relay. This page covers how to deploy it. For which role to pick and what each earns, see Operators and roles. Every flag and subcommand of the binary is listed in NODE.md, generated from its source.

Hardware requirements

Where the network asks for a manufacturer-certified TPM, the TPM's endorsement certificate must chain to one of the manufacturer roots that governance has recognised. A software TPM (swtpm) has no such certificate: use it only for private test networks whose own genesis lists its roots, never on Tenzro Network.

CPU and GPU builds

Each platform has a CPU build and GPU builds, and none falls back to another:

• GPU builds: CUDA for NVIDIA and Vulkan for AMD, Intel and other Vulkan GPUs on Linux and Windows, Metal on macOS. On a machine with no usable GPU or driver a GPU build refuses to start, and the message names the CPU build to use instead. The Vulkan build serves llama.cpp models on the GPU; ONNX Runtime has no Vulkan provider, so on an NVIDIA or AMD GPU it refuses ONNX models and names the build that serves them.
• CPU build. Serves the roles that need no accelerator (validator, RPC, storage, light) and CPU-tier models. It refuses a GPU-tier model with a message naming the GPU build.

Model admission is decided by the accelerators the running process can actually drive, not by the build alone.

Install

Download the archive for your platform from the downloads page. Each archive holds tenzro-node and the tenzro CLI, and every release publishes SHA-256 checksums alongside the archives.

To build from source you need the Rust toolchain pinned in rust-toolchain.toml, plus clang, cmake, protoc, pkg-config and OpenSSL:

git clone https://github.com/tenzro/tenzro-network
cd tenzro-network
cargo build --release -p tenzro-node -p tenzro-cli                       # CPU build
cargo build --release -p tenzro-node -p tenzro-cli --features tenzro-node/cuda   # CUDA build

See Hardware discovery for the other accelerator features.

Hardware-rooted identity

A node's identity lives in its hardware. Its identity, account and announcement signatures are made by a P-256 key held in the TPM or the Secure Enclave, and consensus votes are signed with a session key that the hardware certifies once per epoch. No key is ever written to disk, so there are no key files to copy, back up or leak. See Hardware-rooted keys.

• Validators need a TPM 2.0 or a Secure Enclave, like every node. Any machine with one can run a validator.
• Autonomous operation (tenzro setup --operator autonomous) lets the machine answer for itself with its own hardware key instead of a person's passkey.

Check what a machine offers before you start:

tenzro hardware
tenzro tee detect

Guided setup

tenzro setup walks through joining Tenzro Network, bootstrapping a local network or joining a private one, and writes the configuration and service unit for you:

tenzro setup --path network --mode validate --roles validator --yes
tenzro setup --path network --mode provide --roles ai,storage --access on-demand,subscription

Run the node

tenzro-node --roles validator,ai --data-dir /var/lib/tenzro

• With no --boot-nodes the node joins Tenzro Network through its genesis validators' identities. Boot nodes are machine identities (did:tenzro:machine:<id>, optionally @<relay url>), never network addresses. --boot-nodes "" keeps a node isolated.
• Run the exact binary version and genesis the network runs. State is deterministic; a different binary or an edited genesis produces a different state root, and your blocks are rejected.
• A new validator joins as a non-voting node that validates and syncs. It proposes and votes once it has bonded and has been admitted at an epoch boundary. See Validator lifecycle.
• Every listener binds to loopback by default (--rpc-addr 127.0.0.1:8545, --web-addr 127.0.0.1:8080, --mcp-addr 127.0.0.1:3001, --a2a-addr 127.0.0.1:3002). To serve RPC or MCP publicly, put your own HTTPS reverse proxy in front of the listener and announce its URL with --external-rpc-addr or --external-mcp-addr.
• TENZRO_DATA_DIR sets the data directory once for both the node and the CLI.

Ports

See Networking.

Who may use your node

The node's access policy (access.toml in the data directory) decides who may reach each surface: open, signed in, named DIDs, agents under Terms, or closed. There are no API keys or admin tokens; administrators are DIDs and sign in with their own hardware key or passkey.

tenzro-node access                       # wizard
tenzro-node access --preset signed_in --admin did:tenzro:human:<id>
tenzro access show --rpc http://127.0.0.1:8545

See RPC access.

Run as a service

Run the node under a supervisor with automatic restart, so a crash or reboot brings it back with the same identity. The keys stay in the TPM or Secure Enclave, so a restart needs no console interaction.

[Unit]
Description=Tenzro node
After=network-online.target
Wants=network-online.target

[Service]
User=tenzro
Environment=TENZRO_DATA_DIR=/var/lib/tenzro
ExecStart=/usr/local/bin/tenzro-node --roles validator
ExecStop=/usr/local/bin/tenzro-node graceful-exit
Restart=always

[Install]
WantedBy=multi-user.target

The service user needs access to the TPM device (/dev/tpmrm0, usually through the tss group). tenzro-node graceful-exit asks the running node to step down at a safe point before it stops. Never wipe the data directory to reset a node: it holds the node's chain state and configuration. tenzro-node backup and tenzro-node restore move it between machines.

Containers

Each release publishes images built from its Linux archives: tenzro-node:testnet-v1-cpu, tenzro-node:testnet-v1-cuda and tenzro-node:testnet-v1-vulkan, for linux/amd64 and linux/arm64, each also tagged with the release commit. They run as a non-root user, keep everything on the /data/tenzro volume, check themselves with the node's /health endpoint, and refuse to start without the host's TPM (--device /dev/tpmrm0). Run a node in Docker covers the TPM credential, GPU flags, ports and a systemd service.

On an orchestrator, keep one validator per machine, give each pod its node's TPM device, use tenzro-node graceful-exit as the preStop hook, and point liveness at /health and readiness at /ready.

Light nodes

Laptops, desktops and edge devices can run a light node that follows the chain, verifies finality and relays without storing the full history:

tenzro-node --roles light --data-dir ~/.tenzro

It works behind NAT. New full nodes can start from a snapshot instead of replaying the chain (--state-sync-from with a verified --checkpoint-height and --checkpoint-hash); see State and snapshots.

Monitoring

• GET /health, GET /ready and GET /status on the Web API report liveness, readiness (height, lag behind the network tip, peer count) and node state.
• GET /metrics serves Prometheus metrics.
• Logs go to stdout; --log-format json produces structured logs and --log-level sets verbosity.
• tenzro status shows live resource and traffic status from the command line.

Hardening checklist

• Keep every listener on loopback and expose only what your roles need, through your own TLS reverse proxy.
• Keep /metrics off the public internet.
• Set an access policy that matches what you serve, and keep the admin list short.
• Publish a signed operator policy that says what you serve and how; you are only slashed for provable breaches of your own policy. See Operator policies.
• Subscribe to release announcements and upgrade promptly; run the same version as the network.