Operators Overview

This section is for people who run NOOSChain nodes and environments. Operators own the live system: node processes, configuration, admin access, consensus, storage, recovery, monitoring, state-root sidecars, smart-contract runtime sidecars, and incident response.

If you are writing contracts, start with Smart Contract Developers. If you are changing protocol internals, start with Nooschain Developers. If you need the high-level architecture first, start with General Overview.

Operator Mental Model

A running NOOSChain environment has consensus state and local node state. Operators need to watch both.

Layer	Operator responsibility
Node process	Start, stop, upgrade, configure, and verify the node.
Admin access	Protect operator tokens, admin keys, CLI access, and GUI access.
Consensus	Configure validators, peers, Raft adapters, and conflict response paths.
Storage	Protect database files, snapshots, backups, and restore procedures.
Sync and verification	Check block height, replay, gossip, state roots, and local health.
State-root sidecars	Activate, monitor, and recover SMT sidecars when a state-root engine requires them.
Smart-contract runtime	Activate Wasmtime sidecars, preflight runtime readiness, and watch execution failures.
Observability	Collect logs, metrics, health reports, alerts, and incident evidence.

Consensus state is what the chain agrees on. Local node health is whether this node can serve, validate, execute, sync, and recover. A node can have the same chain head as its peers while still having a local runtime, sidecar, storage, or permission problem that operators must fix.

Start Here

Use the path that matches what you are doing now.

Goal	Start with
Run local commands and inspect the node	Operator CLI
Build or deploy containers	Docker Deployment
Build a new three-VM production cluster	Three-Validator Production Tutorial
Use a browser admin surface	Admin GUI
Understand admin identities and access	Authentication And Identities
Try common operator workflows	Recipes
Prepare a production environment	Production Readiness
Gate a production release	Production Release Readiness
Build monitoring and alerts	Monitoring And Alerting
Recover from data loss or corruption	Backup, Restore, And Recovery
Respond to an active incident	Incident Response
Handle fork or conflict conditions	Conflict Handling
Operate smart-contract execution	Smart Contract Runtime Operations
Activate state-root verification	State-Root Activation

Daily Operations

Day-to-day operation is mostly about keeping the node observable and boring:

• confirm the node process is running and reachable;
• check logs for repeated warnings, runtime errors, consensus churn, and sidecar failures;
• inspect chain head, block height, sync status, consensus status, and state root verification;
• verify admin access paths still work and operator tokens are not exposed;
• check mempool, transaction failures, and smart-contract execution failures;
• confirm backups and snapshots are being created on schedule;
• periodically restore from backup in a non-production environment;
• keep CLI, Admin GUI, Swagger/OpenAPI, and observability access documented.

Useful pages:

• Operator CLI
• Admin GUI
• Logging
• Swagger / OpenAPI
• Observability API
• Health Repair

Production Responsibilities

Production operators should be able to answer these questions before a node serves real traffic:

Question	Where to document or verify it
Which configuration is active?	Production Readiness
Who can administer the node or chain?	Authentication And Identities
Where are operator tokens and signing keys stored?	Production Readiness
What alerts page the operator team?	Monitoring And Alerting
How are backups made and restored?	Backup, Restore, And Recovery
What is the release gate?	Production Release Readiness
What is the incident path?	Incident Response
How are consensus conflicts handled?	Conflict Handling
Which sidecars are required?	State-Root Activation, Smart Contract Runtime Operations

Do not treat a successful node start as production readiness. Production readiness includes secrets, backup restore proof, monitoring, consensus configuration, sidecar preflight, upgrade procedure, and incident ownership.

Consensus And State

Consensus and state-root operations are where local configuration and consensus rules meet. Operators need to know which adapter is active, how validators are configured, what sidecars are required, and how to respond when a node disagrees with its peers.

Use:

• Three-Validator Production Tutorial
• HashiCorp Raft Deployment
• Raft Consensus Configuration
• Raft Sidecar Operations
• State-Root Activation
• Nervos Activation Runbook
• Nervos Sidecar Recovery
• Snapshots
• Conflict Handling

For the general explanation of consensus modes, see Consensus. For protocol internals, see the Nooschain Developers consensus pages.

Backup, Restore, And Snapshots

Backups and snapshots are operational controls, not paperwork. A backup plan is only credible when restore has been tested.

Operators should maintain:

• backup schedule and retention policy;
• snapshot creation and restore procedure;
• off-node copy location;
• restore drill record;
• recovery time and recovery point expectations;
• evidence needed for incident review.

Use:

• Backup, Restore, And Recovery
• Snapshots
• Incident Response
• Health Repair

For the general snapshot concept and recipes, see General Snapshots.

Smart-Contract Runtime Operations

Operators do not usually author smart contracts, but they do operate the runtime that executes them. That includes enabling contract execution, checking runtime preflight, managing the Wasmtime sidecar, watching contract metrics, and responding to failed calls or runtime incidents.

Use:

• Smart Contract Runtime Operations
• Smart Contract Operations Runbooks
• Smart Contract Layer Readiness
• Smart Contract Release Candidate Gate
• Smart Contract Incident Drills
• Smart Contract Package Signing Policy
• Smart Contract Web Console

For authoring, manifests, authorization, packages, provenance, registry, and SDK usage, use Smart Contract Developers.

Page Map

Area	Pages
Setup and access	Operator CLI, Admin GUI, Authentication And Identities, Swagger / OpenAPI
Day-to-day operations	Recipes, Logging, Observability API, Health Repair
Production and recovery	Production Readiness, Production Release Readiness, Backup, Restore, And Recovery, Incident Response, Conflict Handling
Consensus and state	HashiCorp Raft Deployment, Raft Consensus Configuration, Raft Sidecar Operations, State-Root Activation, Nervos Activation Runbook, Nervos Sidecar Recovery, Snapshots
Smart contracts	Smart Contract Runtime Operations, Smart Contract Operations Runbooks, Smart Contract Layer Readiness, Smart Contract Release Candidate Gate, Smart Contract Incident Drills, Smart Contract Package Signing Policy, Smart Contract Web Console

What This Section Does Not Cover

• Smart contract authoring, manifest design, package provenance, registry use, and SDK usage belong in Smart Contract Developers.
• Protocol design, replay internals, state-root engine changes, and adapter internals belong in Nooschain Developers.
• Architecture, buckets, permissions, consensus concepts, state roots, sync, and snapshots at a conceptual level belong in General.