AeroNyx Nodeboard Operator Console Guide

Nodeboard is the operations console for AeroNyx decentralized privacy nodes. It turns registration, aggregate health, capacity, protocol evidence, maintenance, and incident closure into repeatable workflows without exposing user traffic or encrypted content. Open app.aeronyx.network. A panel proves only what its current source reports; configuration, runtime readiness, and observed evidence are separate states.

Scope and operating model

Use three levels. Dashboard answers whether the fleet needs attention. Services compares a service or capacity domain across owned nodes. Node detail explains one node and contains evidence, controls, and audit history. Healthy nodes stay quiet; raw proof history and command timelines belong in detail, not in the first-level dashboard. Nodeboard manages nodes associated with the authenticated operator; it is not a public traffic explorer.

Register a node

Create a short-lived code in Registration Codes, then use the generated command or the official installer. Follow planning, installation, registration, service start, heartbeat, and admission separately. After the node appears, confirm region, public visibility, runtime version, source commit, capacity, and health. A registration code binds one onboarding flow; it is not a reusable API key and its consumed secret must not be shown again.

Start with fleet attention

Triage in this order: offline or stale heartbeat; failed, timed-out, or stale command; maintenance with active sessions; packet drops or exhausted IP/conntrack/file-descriptor/disk resources; policy drift; discovery/relay mismatch; then aging recovery or proof evidence. Stale, not reported, and disabled are different from zero and from healthy. Open the highest-impact item, identify user impact, and retain an explicit closure condition.

Use Services and node detail

Services groups Privacy Network, Discovery & Relay, MemChain & Storage, and Runtime signals. Compare nodes there, then open node detail for source timestamps, policy sync, risks, command state, and recovery evidence. Every incident needs four facts: signal, impact, action, and closure. A successful command exit is not closure; fresh heartbeat, service health, protocol endpoint, and affected capacity must recover.

Make capacity and placement decisions

Capacity is an admission decision, not a vanity score. Review IP pool used/free, max_connections, policy max_sessions, active sessions, conntrack, file descriptors, packet drops, pps/bps, bandwidth policy, disk, memory, and CPU. Distinguish hard runtime limits from commercial policy. A policy value of zero may mean unlimited and must follow backend semantics. Use Accepting, Limited, Drain, or Maintenance with the reason; never infer per-user activity from aggregate rates.

Read discovery and encrypted relay evidence

Keep these states separate: configured capability, signed advertised capability, endpoint reachability, recent probe stability, real encrypted relay observation, terminal client receipt, and restart continuity. Synthetic probes prove a test path, not user traffic. OnionMiddle is a no-exit encrypted relay role; candidate status requires a reachable peer API, ready ChatRelay runtime, signed descriptor, routeable peers, and fresh path evidence. Nodeboard must not expose route hops, peer social graphs, payloads, or client identities.

Read MemChain and commitment evidence

MemChain panels may report whether sealed storage, commitment following, witnesses, quotas, cleanup, and recovery are configured and fresh. These features are config-gated; an empty or disabled panel does not prove a fault. Witness and checkpoint counters are rollback/fork evidence, not public-chain consensus or proof that a witness stores payload bytes. Show aggregate state only, never owner keys, record IDs, projects, vectors, edges, checkpoint material, or ciphertext.

Maintain, restart, and upgrade safely

Remote restart_service is a privileged, backend-gated command. Require permission, active-session warning, maintenance/drain guidance, explicit confirmation, immutable audit, and the lifecycle pending -> sent -> executing -> completed | failed | timeout; cancel only while allowed. After completion, verify runtime, heartbeat, healthcheck, policy sync, and affected protocol evidence before ending maintenance. Upgrade panels show version drift, staged state, blockers, and cutover safety; they do not imply a universal one-click remote upgrade. Use the approved node upgrade workflow and rollback material.

Keep access credentials separate

A registration code enrolls a node. A private access code admits approved clients to a restricted node. An anonymous voucher proves service eligibility without becoming an operator credential. They are not interchangeable. Apply least privilege, short expiry, one-time display, revocation, and audit. Never put secrets, private keys, raw bearer values, or recovery material into events, URLs, screenshots, or support tickets.

Use events, freshness, and audit

Every panel should identify provenance and freshness: signed Rust heartbeat, local health endpoint, discovery status, systemd/upgrade report, backend policy, or command audit. Events should answer when state changed, which node/service was affected, who or what initiated an allowed action, and whether closure evidence arrived. Keep timestamps and coarse reason codes; exclude packet payloads, destinations, message identifiers, client IP activity, memory contents, and social-graph data.

Permissions and privacy boundary

Use role-based authorization for registration, policy changes, maintenance, commands, codes, and audit. Nodeboard may show aggregate sessions, bytes, packets, capacity pressure, routeability, proof outcomes, recovery, and command lifecycle. It must not show DNS contents, destinations, browsing history, packet/message plaintext, MemChain plaintext, client public-IP activity, wallet-level traffic, private keys, or voucher secrets. A node operator should be able to operate infrastructure without learning user behavior.

Operator routine and references

Daily: review Attention, stale/offline nodes, placement state, packet drops, resource pressure, discovery freshness, and command SLA. Before maintenance: inspect sessions, enable drain/maintenance, confirm target version/commit and rollback material. After maintenance: verify service active/enabled, fresh heartbeat, healthcheck, policy sync, discovery/relay admission when configured, then close the incident.