Nodeboard operator console guide
How AeroNyx node operators use Nodeboard to register nodes, read health and capacity, set policy, run commands and manage VPN sessions, including exactly which per-session and per-client-key data operators can see and their responsibilities for it.
Nodeboard (app.aeronyx.network) is the web console where AeroNyx node operators register nodes, watch health and capacity, set per-node policy and manage VPN sessions on the nodes they own. For those nodes it shows per-session and per-client-key traffic records (bytes, times, tier and tunnel address) and lets operators disconnect sessions and ban client keys. It does not show destinations, DNS queries or packet contents.
All production nodes are operated by AeroNyx today. Anyone who operates a node must follow the Node Operator Policy.
Sign in
Nodeboard has two sign-in methods:
- Wallet. Connect Phantom (Solana), MetaMask (Ethereum) or OKX (Ethereum or Solana). Nodeboard requests a one-time nonce from the backend and asks your wallet to sign it. The signed nonce proves you control the wallet; no password is involved.
- Phone. Log in with your phone shows a QR code to scan with the AeroNyx app and a short code to compare on both screens.
Your account sees only the nodes registered to it. Every node list, session list, billing view and command is limited to nodes you own.
Navigation
| Page | What it is for |
|---|---|
| Overview | Fleet summary: total and online nodes, active sessions, traffic, uptime, an operations summary, client placement capacity, a 24-hour traffic and billing card, Needs Attention and recent events |
| Nodes | Your nodes with health, sessions, placement and current action; each opens the node detail page |
| Services | Fleet-wide views by service: operator signal, protocol foundation, onion relay pool admission, capacity, transport, gateway DNS, client placement, service risks, node readiness, and restart readiness, queue and outcome audit |
| Sessions | Node health and active VPN tunnels, session quality, and actions to disconnect a session or ban a client key |
| Registration Codes | Generate one-time codes, copy install commands, follow install progress |
| Alerts / Events | The event stream and Incident Closure |
| Traffic & Billing | Traffic and time per node, per client key, per session and per day, with search and CSV export |
| Settings | Per-node placement and policy, fleet presets, policy sync and audit, language |
| Chat | Opens AeroNyx web chat, which pairs with the app by QR code. It is separate from node operations. |
What Nodeboard shows about users
Each registered VPN node reports every VPN session to the AeroNyx backend while the session runs and when it ends. Nodeboard shows these records to the owner of the node.
| Data | Where it appears |
|---|---|
| Session ID | Sessions, Traffic & Billing → Sessions, node detail → Recent Sessions |
Client key (client_wallet): the public key the app uses in the VPN handshake. It stays the same across sessions, so it links one user's sessions over time. Shortened in tables, searchable and exported in full. | Sessions (Client column), Traffic & Billing → Identities and Sessions |
Membership tier that the backend finds for the client key (unknown if none) | Traffic & Billing → Identities and the tier breakdown |
Tunnel virtual IP (the address inside the VPN, for example in 100.64.0.0/22) | Sessions, Traffic & Billing → Sessions |
| Bytes in and out, session count, duration | Per node, per client key, per session and per day |
| First seen and last seen per client key; start, end and last activity per session | Traffic & Billing, Sessions |
| Link quality: round-trip time, packet loss, keepalive results, last error | Sessions, Traffic & Billing → Sessions |
Traffic & Billing covers the last 7, 14, 30, 60 or 90 days. Export CSV downloads the rows of the current tab, including full client keys and virtual IPs where the tab has them.
What nodes do not report and Nodeboard does not show: client public IP addresses, destination addresses or domains, DNS queries, URLs, packet or message contents, and private keys. Chat relay, discovery and protocol panels show aggregate counters only.
The node host is a different matter. A VPN node is the exit for its users' traffic, so someone with root access to the server can observe that traffic in the same way as on any VPN server, whatever Nodeboard shows. The Node Operator Policy governs what operators may do. For how AeroNyx itself handles this data, see the Trust Center.
Operator responsibilities
- Use session and client-key data only to run, secure and bill the service, as the Node Operator Policy allows.
- Treat CSV exports as personal data: keep them only as long as you need them, store them securely, and do not share them.
- Do not try to link client keys or virtual IPs to people, and do not inspect, log or retain user traffic on the host.
- Disconnect sessions and ban client keys only for operational or abuse reasons, and record why.
- Keep sign-in wallets, phones and server credentials secure.
Register a node
- Open Registration Codes and select Generate Code. A code is valid for 15 minutes and works once.
- Copy the Quickstart command (or the step-by-step preview and install commands) and run it on the server as root. The full procedure, including how to keep the code out of shell history, is in Install and register an AeroNyx node.
- Follow Install Progress:
not_started → planning → running → completed | failed. The stage shows where the installer is (plan, preflight, dependencies, repository, config, network, build, systemd, register, start, done). On failure it shows the failed phase and exit code.
Code states are Available, Used, Expired and Revoked. When a code has expired, Nodeboard hides its install commands. The AI assistant prompt includes the code itself; sharing that prompt shares the code.
Overview and triage
Start on Overview. Fleet statistics, operations, placement and billing cards each say when they were last updated. If a refresh fails, they keep the previous data and say so. "No events" and "events could not be loaded" are shown differently, and missing data is not shown as zero.
A reasonable order of attention:
- Offline nodes or stale heartbeats.
- Failed, timed-out or stale commands.
- Nodes in maintenance that still have active sessions.
- Capacity pressure: IP pool, file descriptors, connection tracking, packet drops, bandwidth, disk, memory, CPU.
- Policy not yet synced.
- Discovery or relay readiness problems.
Nodes and node detail
The node detail page groups evidence into sections, including Node Details, Hardware Info, AeroNyx Health, Rust Runtime (version, commit, uptime), Node Capacity, AeroNyx Privacy Protocol, Node Discovery, Encrypted Chat Relay, Service Configuration, Install Workflow, Rust Upgrade Workflow, Maintenance Drain, Bandwidth Limit, Policy Enforcement, Recent Sessions, Wallet Ban Policies, Recent AeroNyx Commands, Recent AeroNyx Events, Recent Operational Events (sanitised service warnings from the last 24 hours) and an Operator Runbook with copyable commands.
Capacity Decision
Capacity Decision answers whether the node should accept new users. It combines the IP pool, the policy's maximum sessions and the node's own admission state into a conservative count of remaining user slots, and names the main bottleneck.
| State | Meaning |
|---|---|
ready | The node can accept new sessions based on current telemetry |
watch | The node can accept sessions, but a resource needs attention |
blocked | The node should not accept new sessions, for example because the service is inactive or the node's own admission check is blocked |
waiting | Capacity telemetry is missing or not fresh enough to decide |
Sessions: disconnect and ban
Sessions lists active and recent VPN tunnels with node, client key, status, duration, traffic, quality and last activity. Search by session ID, client key or virtual IP. Quality is healthy, degraded, stale, error, pending or completed.
- Kick queues a
kick_sessioncommand that disconnects one session. - Ban Wallet queues a
ban_walletcommand that blocks a client key on that node and disconnects its matching tunnels. - Unban is on the node detail page under Wallet Ban Policies (
unban_wallet).
Each action asks for confirmation and first checks that a fresh session snapshot still matches. Nothing changes until the node runs the command on a later heartbeat, so the tunnel stays up until then.
Traffic & Billing
Tabs: Nodes, Identities (per client key), Sessions and Daily. Filters: days, session status, node, and a search over client key or session ID. Summary cards show traffic, active sessions, your account's monthly quota and voucher time, and voucher issuance. The fields are listed under "What Nodeboard shows about users" above.
Settings and policy
For each node: region code, whether it is offered in the AeroNyx exit pool, node tier (public or premium), heartbeat interval, maximum sessions, bandwidth limit in Mbps and Maintenance Mode. Maintenance Mode stops new sessions while existing ones drain.
Policy reaches the node in its heartbeat. After you save, an apply_policy command appears in the node's command history, and Policy Sync moves from pending or unknown to synced once the node confirms it. Fleet Presets apply one policy to several nodes and report which ones need attention. Recent Settings Audit shows policy changes for the last 30 days.
Commands
Commands are how Nodeboard asks a node to act. They are owner-scoped, recorded, and delivered in the node's next heartbeat response.
| Action | Effect |
|---|---|
system_info, collect_logs | Collect host information or logs |
refresh_config, apply_policy | Refresh configuration or confirm the current policy |
two_hop_smoke | Run the node's local two-hop relay check and return aggregate counters |
kick_session, ban_wallet, unban_wallet | Session and client-key actions |
restart_service | Restart the aeronyx-server service |
Lifecycle: pending → sent → executing → completed | failed | timeout. A command that is still pending or sent can be cancelled. A command that stays sent or executing past the backend timeout (300 seconds by default) is marked timeout. A node cannot have two active commands of the same kind.
Restarting a node from Nodeboard
restart_service disconnects every user on the node. Services → Fleet Restart Readiness treats a node as ready to restart only when it needs a rollout restart, Maintenance Mode is on, and active sessions have drained to zero. The Restart Action Queue offers Enable maintenance, Queue restart and Cancel command. The command API requires an explicit restart confirmation, but it does not itself check sessions, so drain first. After the restart, confirm a fresh heartbeat, the new runtime version, health and policy sync before you turn Maintenance Mode off. Upgrades are run on the server with the upgrade workflow; see Run and check an AeroNyx node.
Alerts / Events and Incident Closure
The Event Stream lists node health, session errors, operator commands and policy changes, filtered by days, severity, type and node.
Incident Closure groups related events for the selected window and gives each group an impact statement, a recommended action and a recovery state:
| State | Meaning |
|---|---|
open | Actionable events still need review |
watch | No current blocker, but the issue repeated |
recovered | The latest event shows recovery, or the event is informational |
A command that completed is not closure on its own. Close an incident when the heartbeat is fresh, health and policy sync have recovered, and the affected capacity or relay signal is back.
Codes and credentials are not interchangeable
| Credential | Purpose |
|---|---|
| Registration code | Enrolls one node to your account. One use, 15 minutes. |
| Wallet signature or phone login | Signs you in to Nodeboard |
| Anonymous VPN voucher | Lets an app user prove they may use the service; it is not an operator credential |
Never put codes, private keys or recovery material into events, URLs, screenshots or support tickets.
Related pages
- Install and register an AeroNyx node
- Run and check an AeroNyx node
- Network stats and privacy boundary
- Node Operator Policy
- Trust Center
Frequently asked questions
Can node operators see which users are on their node?
Operators see each session's client key (client_wallet), tunnel virtual IP, byte counts, times and tier for nodes they own. They do not see client public IP addresses, destinations, DNS queries or traffic contents in Nodeboard.
How do I sign in to Nodeboard?
Sign in by signing a one-time nonce with Phantom, MetaMask or OKX, or by scanning a QR code with the AeroNyx app. There is no password.
Why is my kick or ban not applied yet?
Nodeboard queues the command and the node runs it on a later heartbeat. Check the command's state under the node's Recent AeroNyx Commands; it moves from pending to sent, executing and then completed, failed or timeout.
What does Capacity Decision waiting mean?
The node has not sent fresh enough capacity telemetry to decide. Run status or the health check on the node and confirm the heartbeat is fresh; upgrade or restart the node if the telemetry stays missing.
Can I restart a node from Nodeboard without disconnecting users?
No, a restart disconnects every session on the node. Turn on Maintenance Mode, wait until active sessions reach zero, then queue the restart.
Is the CSV export personal data?
Yes, it contains full client keys, virtual IPs and usage times. Handle it under the Node Operator Policy and keep it only as long as you need it.
<!-- faq:end -->