AeroNyx Nodeboard Operator Console Guide

Nodeboard is the AeroNyx operator console for managing decentralized privacy nodes. The production URL is https://app.aeronyx.network.

Nodeboard is the operational control surface for AeroNyx Protocol products: decentralized privacy node onboarding, service health, capacity, encrypted packet counters, access policy, events, billing, MemChain readiness, encrypted storage capability, and commercial operation.

What Nodeboard is

Nodeboard helps node owners and infrastructure teams operate AeroNyx services safely. It connects wallet-based operator identity, node registration, node health, service visibility, aggregate sessions, events, access codes, billing views, and policy controls into one dashboard.

The decentralized privacy node still runs on the operator server. Nodeboard is the control and observability surface that helps operators understand whether that node is ready for real users and future agent workloads.

Core workflows

Services Operations Workbench

Capacity and resource load

Node detail Capacity now combines node capacity telemetry with host resource load:

• virtual IP pool capacity, used IPs, and remaining IPs
• max_connections and Nodeboard policy max_sessions
• conntrack and file descriptor pressure
• packet drops, pps, and bps
• disk capacity for root and AeroNyx state paths
• CPU load, logical CPU count, memory usage, total memory, and memory pressure

High CPU or memory pressure is treated as a commercial capacity risk because it can degrade privacy protocol quality even when the node is online and still has free virtual IPs. The thresholds match backend fleet health: CPU at 85%, memory at 90%, or 14 GB used when total memory is not reported.

Privacy boundary: these are aggregate host and protocol counters only. They do not include client public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, voucher secrets, chat plaintext, or wallet-level traffic.

The Services page is intentionally not a wall of modules. It is designed as an operations workbench for commercial AeroNyx privacy protocol operators.

First-level Services should answer three questions:

• Can the fleet accept real privacy protocol traffic now?
• Which risk blocks user placement or node capacity first?
• What is the next operator task?

The page now uses a task-based layout:

Detailed reports still exist, but they open only when selected. This keeps the first screen calm while preserving capacity, DNS, transport, restart, rollout, service-layer, risk, and per-node diagnostics.

Privacy boundary: Nodeboard displays aggregate operational state only. It must not expose client public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, voucher secrets, or wallet-level traffic.

| MemChain readiness | Display encrypted record capability, sync state, and module health when enabled. | | Encrypted storage readiness | Display encrypted object capability and storage pressure without exposing plaintext. | | Sessions | Review aggregate privacy network sessions without exposing private browsing or chat data. | | Events | Track operational events and control-plane activity. | | Codes | Manage private access codes and registration-related operator flows. | | Billing | Review commercial service accounting and billing state. | | Settings | Manage operator-facing preferences and account settings. |

Packet runtime in the Capacity panel

Nodeboard now includes a node-scoped Stale Session Packets card inside the Capacity panel. This card consumes:

data.nodes[].system.packet_runtime

It is shown beside throughput, packet rate, packet drops, and storage because it is a data-plane stability signal, not a generic event log.

The card displays:

• stale-session packet count
• packet runtime status
• aggregate encrypted packet count
• Rust packet handler active-session count

Operators should use this card after restarts, upgrades, and maintenance exits. A non-zero stale-session count is not automatically a fault. It becomes important when it continues increasing after the node is back online and clients should have reconnected.

The card is available in English, Simplified Chinese, Traditional Chinese, Japanese, Korean, and Russian. The translation keys live in:

/root/open/nodeboard/lib/i18n/index.ts

Type contract:

/root/open/nodeboard/types/index.ts
VpnPacketRuntimeSnapshot

Privacy boundary: the card only shows aggregate counters and coarse status. It does not show session IDs, client IPs, destinations, DNS contents, packet payloads, chat content, storage plaintext, keys, or wallet-level traffic.

Adding a decentralized privacy node

1. Open https://app.aeronyx.network.
2. Sign in with the supported wallet flow.
3. Open Add Node.
4. Generate a registration code.
5. Copy and run the Preview command on the Linux server. The command refreshes or clones the AeroNyx repository and runs the unified node operator entrypoint in read-only plan mode:

if [ -d AeroNyx/.git ]; then cd AeroNyx && git fetch origin main && git checkout main && git pull --ff-only origin main; else git clone https://github.com/AeroNyxNetwork/AeroNyx.git AeroNyx && cd AeroNyx; fi && AERONYX_REGISTRATION_CODE='<NODEBOARD_CODE>' ./deploy/node/aeronyx-node.sh plan --repo-dir "$PWD" --branch main

6. If the plan looks correct, copy and run the Install command:

if [ -d AeroNyx/.git ]; then cd AeroNyx && git fetch origin main && git checkout main && git pull --ff-only origin main; else git clone https://github.com/AeroNyxNetwork/AeroNyx.git AeroNyx && cd AeroNyx; fi && sudo env AERONYX_REGISTRATION_CODE='<NODEBOARD_CODE>' ./deploy/node/aeronyx-node.sh install --repo-dir "$PWD" --branch main --quick

7. After installation, copy and run the Healthcheck command:

if [ -d AeroNyx/.git ]; then cd AeroNyx && git fetch origin main && git checkout main && git pull --ff-only origin main; else git clone https://github.com/AeroNyxNetwork/AeroNyx.git AeroNyx && cd AeroNyx; fi && ./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json

8. Wait for the decentralized node to register and send heartbeats.
9. Confirm the node appears online in Nodeboard.
10. Open the node detail page and review Install Workflow. This node-scoped panel shows the consumed registration-code install status, last reported stage, next action, and any failure recommendation without exposing the registration code value or user traffic data.

Node list first-level signals

The node list and dashboard cards should stay compact. They are for daily scanning, not deep debugging.

Each node card should answer these operator questions immediately:

• Is the node online and recently reporting?
• Can it serve the AeroNyx privacy protocol, or is it control-plane only?
• Is it public, private, or protected by an access code?
• Is maintenance mode preventing new placement?
• How many active sessions are using the node versus policy capacity?
• Is there a bandwidth cap that affects commercial placement?

Node cards intentionally do not show conntrack, file descriptor pressure, packet drops, pps, bps, DNS diagnostics, or full transport metadata. Those belong in node detail and the Services workflow modules where operators have enough space and context to act safely.

Node detail pages use section navigation for commercial operations. The top of the detail view links operators to:

• Overview: health score, availability, CPU, memory, service manager, and heartbeat freshness.
• Capacity: IP pool, sessions, conntrack, file descriptors, throughput, packet rate, packet drops, and storage.
• Runtime: Rust version, Git commit, rollout status, and restart-required state.
• Install & Upgrade: registration-code install progress and Rust upgrade workflow status.
• Events: sanitized recent operational errors from Rust heartbeat.
• Commands: node-scoped command queue and command history.

This keeps the detail page complete while avoiding a long unstructured operations wall.

Private access codes

Node operators can restrict a node to private access from the node detail Settings & Access panel.

Recommended workflow:

1. Open the node detail page in https://app.aeronyx.network.
2. Open Settings & Access.
3. Choose Password Protected or click Generate private access code.
4. Copy the generated code and share it only with the intended private users or internal operations team.
5. Click Save Changes. Generated codes are not sent to the backend until the operator saves.
6. To rotate access, generate a new code and save again.
7. To remove private access, use Remove password protection.

Privacy boundary:

• Nodeboard stores only the hashed access password on the backend
• Nodeboard does not expose the stored password back to the UI
• private access code management must not include client public IPs, destinations, DNS contents, packet payloads, chat plaintext, voucher secrets, private keys, or wallet-level traffic

Services page

The Services page is designed as a mature operator console, not a wall of modules. The first screen should answer three questions quickly:

1. Can the fleet serve AeroNyx Privacy Protocol traffic now?
2. What is the highest-priority operational risk?
3. Which workflow should the operator open next?

The page now keeps deep reports behind a workflow selector:

First-level summary cards should focus on:

• node online and heartbeat state
• capacity summary
• aggregate active sessions
• encrypted traffic
• encrypted packet forwarding
• packet drops and health warnings
• commercial placement readiness

Detail panels can hold:

• IP pool capacity, used IPs, and remaining IPs
• max_connections
• policy max_sessions
• conntrack and file descriptor pressure
• pps and bps
• throughput caps: Rust reports bandwidth_limit_bytes_per_second; Nodeboard converts it to bits/sec for operator-facing bps/Mbps/Gbps display
• DNS resolver ownership and status
• transport capability metadata
• MemChain capability and sync state
• encrypted storage capability and storage pressure

This split keeps the page usable for daily operations while preserving the full diagnostic surface for senior operators. The first screen should feel like an international-grade operations product: clear status, one next action, and no module overload.

MemChain and encrypted storage

MemChain is the encrypted record layer direction for AeroNyx. It gives the protocol a way to preserve versioned private state, such as conversation memory, node service records, encrypted storage checkpoints, and future agent workflow state.

Nodeboard should present this as operational capability, not plaintext content. Operators need to know whether the module is enabled, synced, healthy, and within storage limits. They should not see user messages, decrypted memory, private keys, or raw personal data.

Agent-to-agent protocol services

AeroNyx is designed for a future where autonomous agents need private network access, encrypted communication, and verifiable state exchange. Nodeboard should eventually show whether a node can serve agent workloads, including:

• private routing capability
• encrypted protocol capability
• MemChain readiness
• encrypted storage readiness
• payment or settlement readiness
• capacity available for agent traffic

Operational safety

Nodeboard should expose aggregate service and node metadata only. It should not expose:

• packet payloads
• DNS contents
• user destinations
• domains or URLs
• browsing history
• voucher secrets
• wallet-level traffic
• raw client public IP activity
• decryptable chat history
• encrypted storage plaintext
• MemChain plaintext
• registration code history after expiration

Recommended operator routine

Daily:

• check node online status
• review Services capacity warnings
• review Events for repeated failures
• confirm latest heartbeat freshness

Before maintenance:

• check aggregate active sessions
• avoid forced restart during high usage
• run Rust healthcheck
• use staged upgrades before planned restart windows

After maintenance:

• confirm aeronyx-server is active
• confirm Nodeboard sees fresh heartbeat
• confirm transport metadata is active
• review packet drops and capacity warnings
• confirm MemChain or encrypted storage modules remain healthy when enabled

Commercial capacity and runtime telemetry

Nodeboard now treats capacity and runtime state as first-class operator data. The node detail page should answer four questions quickly:

1. Can this decentralized privacy node accept more users?
2. If not, is the bottleneck IP pool, session policy, conntrack, file descriptors, packet drops, bandwidth, or placement policy?
3. Is the node running the expected Rust version and build?
4. Has a new binary been staged on disk but not restarted yet?

The capacity panel reads aggregate telemetry from signed Rust heartbeats and the Rust /api/vpn/health contract:

The Runtime panel shows version, git commit, build profile, build target, process id, uptime, start time, and rollout status. If Linux reports that the running executable was replaced on disk, Nodeboard should warn the operator to drain active sessions, enter maintenance mode, and restart the decentralized node.

Privacy boundary: Nodeboard capacity and runtime telemetry is aggregate operations metadata only. It must not include user public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, voucher secrets, chat plaintext, MemChain plaintext, or wallet-level traffic.

Runtime provenance in node detail

Nodeboard is the operator console for running AeroNyx privacy protocol nodes. The node detail page reads backend system.runtime and compatible flat fields such as runtime_version, runtime_git_commit, and runtime_uptime_seconds.

The runtime panel should answer four operational questions:

• What exact Rust build is this node running?
• Did the binary on disk change after a GitHub main update?
• Does the node need a controlled restart to activate the new build?
• Is the node healthy enough to keep accepting privacy protocol sessions?

This runtime panel is designed to sit beside the capacity panel. Capacity explains whether the node can accept more users; runtime provenance explains whether the node is running the expected software. Together they let operators distinguish IP pool exhaustion, file-descriptor pressure, conntrack pressure, packet drops, service drift, and stale builds without exposing user traffic data.

Privacy boundary: Nodeboard displays node-operations metadata only. It must not display client public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, voucher secrets, chat plaintext, social graph contents, or wallet-level traffic.

Nodeboard-generated install and AI operator commands

Nodeboard registration codes now generate a single operator workflow built around deploy/node/aeronyx-node.sh.

When an operator generates a registration code, Nodeboard shows:

• a read-only plan command using aeronyx-node.sh plan
• an install command using aeronyx-node.sh install --quick
• a post-install verification command using aeronyx-node.sh health --json
• an AI assistant prompt for Codex, OpenClaw, Claude Code, Hermes, or similar terminal-capable agents

The intended flow is:

1. Copy the plan command and verify the resolved repository, branch, service name, and registration-code presence.
2. Run install only after the plan looks correct.
3. Run health --json after install or upgrade.
4. Check Nodeboard for heartbeat, capacity, runtime provenance, and rollout state.

The generated AI prompt instructs agents to use aeronyx-node.sh as the only operator entrypoint, avoid printing secrets, avoid --force without explicit human approval, and summarize healthcheck results after host changes.

Privacy boundary: generated commands and AI prompts are node-operations tooling only. They must not expose client public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, voucher secrets, chat plaintext, social graph contents, private keys, or wallet-level traffic.

AI-aware maintenance runbook

Nodeboard node detail includes an operator runbook for already-running AeroNyx privacy protocol nodes. The panel derives the Rust repository path from runtime rollout metadata when possible, then generates copyable commands for:

• health --json
• status
• logs --lines 200
• upgrade --no-restart
• an AI maintenance prompt for Codex, OpenClaw, Claude Code, Hermes, or similar terminal-capable agents

The generated prompt explicitly explains that aeronyx-node.sh is not a global system command. It comes from the open-source AeroNyx repository at https://github.com/AeroNyxNetwork/AeroNyx and is available after clone/update at AeroNyx/deploy/node/aeronyx-node.sh.

The runbook intentionally stages upgrades with --no-restart so active sessions are not interrupted. Forced restart remains a human-approved maintenance-window action.

Registration-code install progress

The registration codes page displays recent install progress reported by deploy/node/install.sh through the unified aeronyx-node.sh workflow.

For each registration code, Nodeboard can now show:

• install status: not_started, planning, running, completed, or failed
• current step, such as plan, build, register, or start
• a short message from the installer
• the last reported timestamp

This lets operators see whether an AI-assisted or one-command install is waiting for approval, building, registering, starting, completed, or failed without opening SSH logs first.

The progress endpoint intentionally stores only privacy-safe install metadata. It filters suspicious fields such as registration code echoes, secrets, passwords, tokens, client IPs, DNS contents, destinations, packet payloads, and chat plaintext.

Install failure phases and operator actions

decentralized node installs report progress back to Nodeboard through the registration-code install progress endpoint. If an install fails, the installer preserves the last active phase instead of reporting a generic failure. This lets Nodeboard show the exact step and a focused operator action without collecting user traffic data.

The privacy boundary remains the same for all phases: Nodeboard should receive node operations metadata only. Operators and AI assistants must not paste client public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, voucher secrets, chat plaintext, private keys, registration secrets, or wallet-level traffic into support output.

For AI-assisted operations, the safe order is:

1. Clone or update https://github.com/AeroNyxNetwork/AeroNyx.
2. Run ./deploy/node/aeronyx-node.sh plan first.
3. Wait for human approval before install, restart, or network changes.
4. If install fails, read the Nodeboard phase and run the matching health/log commands from the Nodeboard operator runbook.

Recent operational events

Nodeboard node detail includes a Recent Operational Events panel for AeroNyx privacy protocol nodes. It is designed for commercial operations triage, not user traffic inspection.

The data path is:

1. decentralized node reads local aeronyx-server systemd journal warnings from the last 24 hours.
2. Rust sanitizes each event before heartbeat reporting.
3. The backend exposes the sanitized snapshot as data.nodes[].system.recent_errors.
4. Nodeboard shows the panel on node detail, below capacity diagnostics and before runtime/runbook actions.

The panel intentionally stays out of the Services first screen. Services should remain a fleet-level overview: health, capacity, traffic, and error counts. Operators click into node detail only when they need the exact event summary and runbook commands.

Privacy boundary:

• Allowed: timestamp, severity, sanitized operational message, source label.
• Redacted or excluded: client public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, voucher secrets, chat plaintext, private keys, registration secrets, and wallet-level traffic.

If no recent events are reported, Nodeboard displays a clear/empty state. If a node has not upgraded to a Rust build that reports this field yet, Nodeboard displays a waiting state instead of treating the node as broken.

Services workflow for commercial operators

The Services page is organized as a commercial operations workflow, not as a wall of raw telemetry. A first-level operator page should answer the next decision quickly: can the AeroNyx privacy protocol receive client placement, what is blocking capacity, and where should the operator drill down next.

The current workflow is:

1. Daily Operations - open these first during normal operation. This group contains Client Placement, Node Capacity, and Transport so operators can see commercial readiness, remaining capacity, and carrier availability without reading every node-level report.
2. Triage & Recovery - open these when users cannot connect, policy blocks traffic, DNS readiness fails, or a rollout needs action. This group contains Gateway DNS, Restart & Rollout, and Service Risks.
3. Advanced Diagnostics - use these for engineering review. This group contains Service Layers and Node Readiness so deeper MemChain, ChatRelay, sovereign data RPC, heartbeat, and per-node tables remain available without crowding the first screen.

The Services first screen should stay focused on fleet-level health, capacity, traffic, and error counts. Per-node capacity details, recent operational events, runtime version, runbook checks, and restart safety belong on the node detail page.

The Gateway DNS module reports resolver ownership and readiness only. It must not include DNS contents, domains, client public IPs, destinations, packet payloads, voucher secrets, browsing history, chat plaintext, private keys, or wallet-level traffic.

Node detail Operator Actions

Node detail includes an Operator Actions hub directly after commercial readiness. It is a decision layer, not another raw telemetry table. The purpose is to tell an operator what to inspect or change next without forcing them to scan every panel on the page.

The hub links to existing detailed sections:

1. Settings & Access - visibility, private access code, region, maximum sessions, and bandwidth policy.
2. Capacity Bottlenecks - IP pool, max connections, policy max sessions, conntrack, file descriptors, packet drops, pps, and bps.
3. Health Checks - tunnel device, MTU, forwarding, NAT, DNS readiness, and egress checks.
4. Recent Events - sanitized Rust operational events from the last 24 hours.
5. Rust Runtime - version, git commit, process uptime, rollout state, and restart-required metadata.
6. Command Queue - active, failed, timed out, or completed backend-to-Rust commands.
7. Maintenance & Restart - drain state, restart blockers, maintenance mode, and controlled restart readiness.
8. Install / Upgrade Runbook - one-command health, status, logs, staged upgrade, and AI maintenance prompt.

This layout keeps Nodeboard commercial-friendly:

• Operators see the next action before they read low-level counters.
• Detailed data stays in the existing panels, so the page does not duplicate logic.
• Remote restart and upgrade remain behind explicit maintenance/readiness gates.
• Access passwords are configured through Node Settings; Nodeboard never displays stored password hashes.

Privacy boundary:

Operator Actions uses aggregate node operations only. It must not expose client public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, chat plaintext, voucher secrets, private keys, registration secrets, or wallet-level traffic.

Registration code install timeline

The Registration Codes page shows a stage timeline for each generated node registration code. This timeline turns Rust installer reports into an operator-readable workflow so a node operator can see where an install is waiting, running, completed, or failed.

The timeline stages are:

1. plan - preview-only install plan generated by aeronyx-node.sh plan.
2. preflight - Linux, systemd, root, TUN, route, memory, disk, and port checks.
3. dependencies - package manager, git, curl, build tools, Rust toolchain, OpenSSL, and outbound network setup.
4. repository - GitHub access, branch checkout, repository path, and tracked local change checks.
5. config - /etc/aeronyx/server.toml generation or validation.
6. network - forwarding, NAT, TUN interface, egress interface, and privacy protocol CIDR rules.
7. build - Rust release binary build.
8. systemd - service unit installation and verification.
9. register - node registration through Nodeboard/backend using the registration code.
10. start - service start and post-start health verification.
11. completed - install workflow completed; the operator should open node detail and verify capacity, runtime, recent events, and health checks.

The Rust installer reports these fields through the backend:

• install_status: not_started, planning, running, completed, or failed.
• install_step: the current stage, such as preflight, network, build, register, or start.
• install_message: a short operator-facing status message.
• install_last_reported_at: last installer report timestamp.

Nodeboard uses this data to highlight completed, active, failed, and pending stages. If a stage fails, Nodeboard shows a stage-specific recommendation and a next action. The recommendation is operational only; support output must not include registration secrets, private keys, client public IPs, DNS contents, packet payloads, chat plaintext, or wallet-level traffic.

Registration-code structured install details

The Registration Codes page now shows privacy-safe structured installer details directly inside each install progress row. This is intentionally a compact operator view, not a new first-level Services module.

When deploy/node/install.sh reports progress through the unified deploy/node/aeronyx-node.sh workflow, Nodeboard may display short chips for allow-listed fields:

• command: install mode such as plan, quick-install, network-only, preflight-only, config-only, or install
• repo_dir
• branch
• service
• config
• dry_run
• failed_phase
• exit_code
• script_version
• host
• os
• arch

The purpose is to help a human operator or AI assistant understand the current install context without opening SSH logs first. For example, a failed row should show failed_phase and exit_code before lower-priority path fields, while normal rows remain compact and focused on command, repository, branch, service, config, and dry-run state.

Product rule: the Registration Codes page owns onboarding and install progress. Node detail owns capacity, health, runtime, events, upgrade workflow, and runbook actions. The Services page remains a fleet-level operations workbench and should not become a dump of every per-node install field.

Privacy boundary: these chips are allow-listed operations metadata only. The backend sanitizer and Nodeboard UI must not expose registration code echoes, private keys, API tokens, passwords, client public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, voucher secrets, chat plaintext, MemChain plaintext, encrypted storage plaintext, or wallet-level traffic.

Rust upgrade workflow status

The decentralized node upgrade flow is designed as an operator workflow, not as a noisy services dashboard. deploy/node/upgrade.sh now writes a local privacy-safe status snapshot to:

/var/lib/aeronyx/upgrade-status.json

The snapshot lets Nodeboard, support runbooks, and AI maintenance assistants answer the most important operator question: which upgrade stage is active, staged, completed, or failed?

The file contains only operational metadata:

• status: running, completed, or failed
• step: current stage such as preflight, dependencies, repository, build, validate, systemd, network_restore, restart, healthcheck, staged, cleanup, or completed
• message: short operator-facing progress or failure reason
• repo_dir, branch, service, and config
• no_restart and force
• updated_at

Privacy boundary: the upgrade snapshot must never contain registration codes, private keys, client public IPs, destinations, DNS contents, packet payloads, chat plaintext, voucher secrets, or wallet-level traffic.

Operators can inspect the status with:

./deploy/node/aeronyx-node.sh status

Automation can inspect it through:

./deploy/node/healthcheck.sh --json-only

The JSON response includes top-level upgrade_status. Missing status files are reported as reported: false, which is a normal state for nodes that have not run the new upgrade workflow yet.

Product rule for Nodeboard: the first-level Services page should show only whether the node needs attention. Detailed upgrade stages belong on node detail, operator actions, health checks, or runbooks. This keeps the console mature: operators see the next useful action first, then drill into evidence when they need it.

Nodeboard upgrade workflow panel

Nodeboard surfaces Rust upgrade state on the node detail page, not as another first-level Services module. The Services page should answer fleet-level readiness questions; the node detail page should answer operational questions for one node.

Current data path:

1. deploy/node/upgrade.sh writes /var/lib/aeronyx/upgrade-status.json.
2. Rust /api/vpn/health allow-lists this file into system_stats.vpn_health.upgrade_status.
3. Backend GET /api/privacy_network/vpn/overview/ exposes the sanitized value as data.nodes[].system.upgrade_status.
4. Nodeboard shows:
   • an Operator Actions shortcut named Upgrade Workflow
   • a node-detail panel named Rust Upgrade Workflow

The panel helps operators see:

• whether the last upgrade is running, completed, failed, or waiting
• the current upgrade step
• the last operator-facing message
• repo path, branch, service, config path
• whether --no-restart or --force was used
• when the status was last updated

Privacy boundary: this flow only reports install/upgrade metadata. It must not include registration codes, private keys, client public IPs, destinations, DNS contents, packet payloads, chat plaintext, voucher secrets, or wallet-level traffic.

Registration code to node detail handoff

Nodeboard connects the install timeline to the node operations workspace. When a registration code is consumed by a decentralized node, the backend returns a privacy-safe linked_node summary with the code history row.

The summary contains only:

• node id
• node name
• node status
• whether it is an AeroNyx privacy protocol node
• latest heartbeat timestamp

It does not expose node public keys, node public IPs, hardware details, binary hashes, client public IPs, destinations, DNS contents, packet payloads, chat plaintext, voucher secrets, or wallet-level traffic.

Nodeboard uses this summary to show next actions directly under the install timeline:

• Open node detail
• Capacity
• Upgrade workflow

Product rule: registration codes are the beginning of the operator journey. After install completes, the operator should move to node detail for capacity, health, runtime, events, upgrade workflow, and runbook actions. The first-level Services page remains a fleet readiness view and should not become a dump of every per-node operational detail.

Storage capacity in the capacity panel

Nodeboard keeps Services as a high-level operations summary. Detailed capacity diagnostics belong on the node detail page, where an operator is already focused on one decentralized privacy node.

The node detail capacity panel now includes Storage beside throughput, packet rate, and packet drops. This card reads backend system.capacity.disk and prefers the AeroNyx state directory /var/lib/aeronyx when available, falling back to the root filesystem /.

Storage pressure matters because the same node host may need room for release builds, upgrade artifacts, systemd logs, MemChain data, encrypted storage growth, and healthcheck output. If the decentralized node reports high filesystem usage, Nodeboard should show a capacity risk before the node becomes unreliable for privacy protocol sessions or future agent workloads.

Operators should use the panel this way:

1. Check IP pool and sessions first to understand user capacity.
2. Check conntrack and file descriptors to understand kernel and process pressure.
3. Check throughput, packet rate, packet drops, and storage to understand service quality and operational headroom.
4. Open the node detail runbook only when a risk card asks for a specific operator action.

Privacy boundary: storage capacity is aggregate filesystem usage only. Nodeboard must not display file lists, MemChain records, encrypted storage contents, client public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, voucher secrets, chat plaintext, social graph contents, or wallet-level traffic.

CPU and memory pressure in node health

Nodeboard reads CPU and memory from signed Rust heartbeats through the backend VPN observability API. These values are aggregate node operations metadata only.

The backend treats CPU and memory as commercial health gates:

• CPU at or above 85% marks the node as overloaded.
• Memory uses percentage when Rust reports both memory_mb and memory_total_mb.
• Memory at or above 90% marks the node as overloaded.
• Older nodes that do not report memory_total_mb fall back to the legacy absolute 14 GB threshold.

This matters because the same absolute memory number means different things on different machines. A node using 7.6 GB on an 8 GB host is under pressure, while a node using 14 GB on a 64 GB host may still have enough headroom. Nodeboard should rely on the backend resource-load check instead of duplicating this logic in React.

Privacy boundary: resource-load health includes CPU percentage, memory MB, total memory MB, and derived percentage only. It must not include client public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, voucher secrets, chat plaintext, MemChain plaintext, social graph contents, or wallet-level traffic.

Bandwidth limit pressure in capacity risks

Nodeboard should show bandwidth pressure as part of node capacity, not only as a separate bandwidth chart. Operators need one place to answer why a node cannot accept more commercial traffic.

node capacity telemetry now includes the node-wide bandwidth limiter state:

• bandwidth_limit_mbps
• bandwidth_limit_bytes_per_second
• bandwidth_window_bytes
• bandwidth_window_used_percent
• traffic_capacity_status

When Rust reports traffic_capacity_status = near_limit or the one-second limiter window is at least 80% used, Nodeboard should show a warning capacity risk. When Rust reports traffic_capacity_status = saturated or the limiter reaches 100%, Nodeboard should show a critical capacity risk.

The capacity panel still stays compact. It keeps bandwidth cap status inside the existing Throughput card and uses Rust-authored risk cards for operator action. Detailed charts and policy sync remain in the node detail Bandwidth Limit panel.

Privacy boundary: bandwidth capacity telemetry is aggregate node operations metadata only. It must not include client public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, voucher secrets, chat plaintext, MemChain plaintext, social graph contents, or wallet-level traffic.

Healthcheck operator action summary

deploy/node/healthcheck.sh --json-only now includes a privacy-safe operator_action object for Nodeboard, support runbooks, and AI maintenance assistants.

The object is derived from existing healthcheck evidence only. It does not collect additional user traffic data. It summarizes:

• status: ok, info, warning, or critical
• priority: the recommended operator workflow, such as fix_failed_healthcheck, fix_failed_upgrade, service_not_active, privacy_protocol_degraded, review_warnings, upgrade_staged, or monitor
• title: short operator-facing headline
• detail: the first failed or warning check, upgrade message, or service state
• next_step: the safest next command or Nodeboard workflow
• source: which local diagnostic source produced the recommendation

This lets Nodeboard show a clear next action without duplicating healthcheck logic in React. It also gives terminal-capable AI assistants a stable field to summarize before proposing install, upgrade, restart, or support actions.

Privacy boundary: operator_action is derived from aggregate node operations metadata only. It must not include private keys, registration secrets, client public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, voucher secrets, chat plaintext, MemChain plaintext, encrypted storage plaintext, or wallet-level traffic.

Heartbeat operator action

Rust /api/vpn/health now reports an operator_action summary in the same privacy-safe heartbeat payload that carries capacity, runtime, upgrade status, recent events, and health checks.

This is different from the manual deploy/node/healthcheck.sh --json-only summary. The healthcheck summary is useful during SSH maintenance; the heartbeat summary is useful for Nodeboard because it is reported continuously by the decentralized node after the node has pulled, built, and restarted on a version that includes this contract.

The Rust heartbeat operator_action is derived from existing node operations data:

• failed health checks
• failed upgrade workflow state
• systemd service manager state
• capacity risks
• degraded privacy protocol status
• staged upgrade state

It uses the same fields as the CLI healthcheck summary: status, priority, title, detail, next_step, source, and privacy_boundary.

Product rule: Nodeboard can use data.nodes[].system.operator_action as the first node-level recommendation, while keeping detailed evidence in the existing Capacity, Health Checks, Runtime, Recent Events, Upgrade Workflow, and Runbook panels.

Privacy boundary: heartbeat operator_action is derived from aggregate node operations metadata only. It must not include client public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, voucher secrets, chat plaintext, private keys, registration secrets, MemChain plaintext, encrypted storage plaintext, or wallet-level traffic.

Product interaction model: Services stays high-level, Node Detail owns evidence

AeroNyx Nodeboard should follow a mature operator-console hierarchy:

• Services is the fleet-level decision surface. It should answer: is the AeroNyx privacy protocol fleet healthy, blocked, at risk, or ready for more placement? It should show concise readiness groups, fleet summaries, and primary actions only.
• Node Detail is the evidence and remediation surface. Capacity, Rust runtime health, install and upgrade status, recent operational events, runbook commands, and node-specific recommendations belong here.
• Operator Actions on Node Detail now consumes data.nodes[].system.operator_action from the Rust heartbeat path. This lets the decentralized node explain the highest-priority next step using its own local health evidence while Nodeboard only renders the recommendation and links to the relevant panel.
• Services should not duplicate every Node Detail module. When a fleet card detects a problem, it should route the operator to /dashboard/nodes/{id} or a section anchor such as #capacity-panel, #runtime-panel, #upgrade-workflow, #recent-operational-events, #health-checks, or #operator-runbook.

This keeps Nodeboard closer to a commercial product experience: first-level pages stay scannable, and detailed diagnostics remain available without overwhelming operators.

Rust operator_action data contract

Rust source:

• /root/open/AeroNyx/crates/aeronyx-server/src/api/vpn_health.rs
• /root/open/AeroNyx/deploy/node/healthcheck.sh

Backend pass-through:

• /root/aeronyx/privacy_network/api/vpn_observability.py

Nodeboard consumer:

• /root/open/nodeboard/app/dashboard/nodes/[id]/page.tsx
• /root/open/nodeboard/types/index.ts
• /root/open/nodeboard/lib/i18n/index.ts

The field is privacy-safe operational metadata only. It must not include node private keys, client public IPs, destinations, DNS contents, packet payloads, browsing history, voucher secrets, chat plaintext, or wallet-level traffic.

Product language standard

Nodeboard should describe the product as the operator console for AeroNyx privacy protocol nodes, not as a generic VPN panel.

Use these terms in operator-facing UI and docs:

• AeroNyx Operations for the top-level operating view
• AeroNyx privacy protocol nodes for commercial routing nodes
• Encrypted traffic for aggregate traffic counters
• Encrypted packets / encrypted packet forwarding for packet counters
• Node Detail for deep capacity, runtime, event, install, upgrade, and runbook evidence

Avoid these terms in user-facing copy unless explaining a legacy interface or low-level compatibility detail:

• VPN panel
• VPN network
• VPN Operations
• VPN Nodes
• VPN Traffic

API paths and internal source names may still contain vpn for backward compatibility. UI copy should present the product as AeroNyx privacy infrastructure.

First-level node operations and Attention triage

Nodeboard should stay useful at a glance. The first-level Nodes page is not a raw diagnostics dump; it is the operator's scan surface for the AeroNyx privacy protocol fleet.

The AeroNyx Node Operations table shows:

The Attention column summarizes the most important privacy-safe signal in this priority order:

1. Rust operator_action from signed node telemetry.
2. Rust-authored capacity.risks[], such as IP pool, conntrack, fd, bandwidth, packet drops, CPU, memory, or disk pressure.
3. Recent sanitized operational events.
4. Failed health checks.
5. Non-healthy node health status.
6. Clear state when no current action is required.

Each Attention item links directly into node detail evidence:

• #operator-actions for Rust recommendations and runbook shortcuts
• #capacity-panel for IP pool, max sessions, conntrack, fd, drops, pps, bps, CPU, memory, disk, and recommended configuration
• #recent-operational-events for sanitized Rust operational events
• #health-checks for detailed health-check results

This keeps the first-level page compact while still answering the operator's commercial question: can this node safely carry more traffic, and if not, where should I look first?

Privacy boundary: Attention is based on aggregate node operations only. It must not expose client public IPs, destinations, DNS contents, packet payloads, domains, URLs, browsing history, voucher secrets, chat plaintext, private keys, or wallet-level traffic.

Capacity panel workflow

The node detail capacity panel is the source of truth for commercial capacity triage. Operators should use it to decide whether a node can accept more AeroNyx privacy protocol sessions and why a connection may fail.

The panel should show:

• IP pool capacity, used IPs, and remaining IPs
• max_connections from decentralized node configuration
• policy max_sessions from Nodeboard
• active sessions and remaining session capacity
• conntrack usage and kernel limit
• file descriptor usage and soft/hard limits
• packet drops
• pps and bps
• bandwidth limit and traffic capacity status
• CPU, memory, and disk pressure
• Rust-authored capacity risks and recommended configuration

When a node cannot accept more sessions, the operator should check in this order:

1. IP pool remaining: if zero, expand the privacy protocol virtual IP range or drain sessions.
2. max_connections and policy max_sessions: if lower than demand, adjust configuration intentionally.
3. conntrack and fd pressure: raise host/kernel/systemd limits before scaling.
4. packet drops, pps, bps, bandwidth cap: reduce load or expand bandwidth.
5. CPU, memory, disk: move traffic or resize the host.
6. Rust runtime and recent events: confirm the node is running the expected version and has no recent sanitized operational errors.

The correct user-facing name is AeroNyx privacy protocol or AeroNyx privacy network. Do not describe Nodeboard as a VPN panel.

Capacity Decision and incident closure

Nodeboard should turn telemetry into operator decisions.

The node detail Capacity Decision panel answers four questions:

1. Can this node accept new users now?
2. How many user slots or IP slots remain?
3. What is the primary bottleneck: IP pool, file descriptors, conntrack, bandwidth, packet drops, policy max sessions, or Rust service state?
4. What should the operator do next?

The Events page Incident Closure panel answers the fault-management questions:

1. What recent error happened?
2. What is the impact scope?
3. What action is recommended?
4. Did the system recover after treatment?
5. Is the same issue repeating?

These two panels are the commercial operations layer. Raw telemetry remains available, but the first screen should show conclusions.

One-command node onboarding

Registration Codes generates a single quickstart command for ordinary operators:

git clone https://github.com/AeroNyxNetwork/AeroNyx.git /opt/aeronyx || git -C /opt/aeronyx pull --ff-only origin main
cd /opt/aeronyx
sudo ./deploy/node/aeronyx-node.sh quickstart --registration-code "<code>" --api-base "https://api.aeronyx.network/api" --repo-dir "$PWD"

The command is designed for humans and AI assistants. It previews the plan, waits for explicit INSTALL confirmation, installs/registers the node, then runs status and healthcheck.

Discovery and Relay foundation

Nodeboard now shows a Rust-authored Relay foundation status inside the node detail Discovery panel. It converts low-level PeerStore and gossip counters into an operator decision:

• whether signed peer discovery is healthy
• whether gossip freshness is acceptable
• whether seed recovery is configured
• whether restart recovery is configured through seed endpoints or peer cache
• whether the node is ready to be treated as a future relay/multihop foundation
• what Rust recommends as the next action

This keeps the first-level Services page focused while preserving deep per-node evidence for operators and AI maintenance tools. A node with healthy in-memory peers but no seed recovery or peer cache should be treated as degraded for relay foundation readiness, because it may lose discovery after restart.

The panel follows the AeroNyx blind-node invariant: aggregate peer and gossip metadata are allowed, but user content, MemChain plaintext, packet payloads, destinations, DNS contents, social graph edges, private keys, voucher secrets, and wallet-level traffic are never shown.

Related protocol note: AeroNyx Node Discovery and Relay Foundation.

Discovery Cache Evidence

Nodeboard should treat last_cache_save_status=success and restart_recovery_configured=true as evidence that the decentralized privacy node has at least one restart recovery path. The decentralized node saves the verified PeerStore cache after bootstrap and again during graceful shutdown, so upgrades should preserve recently discovered peers when the service receives a normal stop signal.

Discovery restart recovery in Nodeboard

Nodeboard reads the decentralized node's privacy-safe discovery summary from heartbeat metadata. Operators should use the Discovery panel as a readiness gate before enabling future multi-hop relay or encrypted service routing experiments.

The green path is:

• PeerStore health is healthy
• relay foundation is ready
• restart recovery is configured
• last cache save is success
• valid peers are present

The decentralized node now stores a backup of the verified PeerStore cache at the same path with .bak appended. If the primary cache is damaged or has no usable verified descriptors, startup can recover from the backup and continue discovery gossip. Nodeboard does not need to display peer URLs or raw descriptors; it only needs the aggregate status, counts, and cache source/status fields already reported by the node.

Privacy boundary: PeerStore cache and backup are discovery metadata only. They must not include message plaintext, packet payloads, DNS contents, client browsing history, wallet-level traffic, voucher secrets, or private keys.

Discovery source priority in Nodeboard

Nodeboard should read Rust discovery state as an operator decision, not as a raw counter list. Static bootstrap files and URLs are cold-start seed material. The decentralized node can load them first, then load the local verified PeerStore cache and report the cache as the effective successful source.

Expected healthy state after restart:

• Bootstrap Source: success
• Source kind: cache
• Recovery status: success
• Relay foundation: ready
• Valid peers: at least 2
• Runtime rejected: may be greater than zero if stale static seed descriptors were observed

Do not downgrade the primary Nodeboard card solely because runtime.rejected is non-zero when last_source_status=success, recovery_status=success, and relay_foundation_ready=true. Show rejected descriptors as diagnostic evidence for maintenance, not as an outage.

Discovery recovery display

Nodeboard now prefers bootstrap.recovery_status in the Discovery Bootstrap Source card when Rust reports it. This prevents an expired static bootstrap file from masking a successful live seed-gossip recovery path.

Expected healthy display:

• Bootstrap Source value: success
• Detail kind: file / recovery
• Relay foundation: ready
• Valid peers: at least 2

The underlying last_source_status remains available in heartbeat data for diagnostics. Operators should use it to clean up stale bootstrap files, while using recovery_status and the Rust stability summary for the actual readiness decision.