AeroNyx

Install and Register an AeroNyx Decentralized Privacy Node

AeroNyxJune 18, 20264 min read294 views

The supported production workflow for installing, registering, verifying, upgrading, and optionally enabling blind relay on an AeroNyx decentralized privacy node.

This guide is the supported production path for a new AeroNyx node. It uses the repository-local operator entrypoint, registers the node with a one-time code from Nodeboard, starts the hardened systemd service, and verifies network admission.

Operator console: app.aeronyx.network

Source repository: github.com/AeroNyxNetwork/AeroNyx

Before you begin

Use a dedicated Linux server with a stable public address.

ResourceProduction guidance
Operating systemCurrent Ubuntu or Debian release
CPU2 cores minimum; more for source builds or high packet rates
Memory4 GB recommended; hosts below 2 GB fail or warn preflight
Disk20 GB free minimum; allow more for build cache and retained releases
NetworkPublic 51820/UDP for privacy-network traffic and 8422/TCP for signed discovery/peer APIs
SSHRestrict administrative access to trusted addresses or an access proxy

The local management API on 8421/TCP should not be exposed to the public internet.

1. Create a one-time registration code

  1. Sign in to Nodeboard.
  2. Open Registration Codes.
  3. Create a short-lived code for the intended operator account.
  4. Keep the code private. It binds the new node identity to that account and can be used only once.

Nodeboard may generate the final command for you. Prefer its generated command when available.

2. Obtain the official operator script

aeronyx-node.sh is not a global Linux command. It comes from the AeroNyx repository:

bash
sudo install -d -m 0755 /opt/aeronyx
sudo git clone --branch main --single-branch \
  https://github.com/AeroNyxNetwork/AeroNyx.git \
  /opt/aeronyx/AeroNyx

cd /opt/aeronyx/AeroNyx
git rev-parse HEAD

If the repository already exists, do not clone over it. Use the built-in upgrade workflow described below.

3. Run the interactive quickstart

bash
cd /opt/aeronyx/AeroNyx
sudo ./deploy/node/aeronyx-node.sh quickstart \
  --node-name "Berlin1" \
  --region "DE" \
  --public-vpn

Replace the example name and ISO country code. Quickstart previews the plan, requests the registration code through a hidden prompt, asks for explicit confirmation, installs dependencies, builds or selects the node binary, writes configuration, applies forwarding/NAT rules, registers the generated node identity, starts systemd, and waits for admission.

For automation, pass the registration secret through stdin rather than the process list:

bash
printf '%s\n' "$AERONYX_REGISTRATION_CODE" | \
  sudo ./deploy/node/aeronyx-node.sh install \
    --quick \
    --registration-code-stdin \
    --node-name "Berlin1" \
    --region "DE" \
    --public-vpn \
    --start

Do not paste a live code into tickets, screenshots, shell history, or public AI conversations.

4. Verify the node

bash
cd /opt/aeronyx/AeroNyx
./deploy/node/aeronyx-node.sh status
./deploy/node/aeronyx-node.sh health --json
systemctl is-active aeronyx-server

A production-ready result should show:

  • systemd active and enabled
  • local VPN health ok
  • fresh management heartbeat
  • public pool state matching the intended visibility
  • 51820/UDP listening
  • signed discovery ready with fresh peers
  • no critical capacity or packet-drop risk

Nodeboard should show the same node name, region, visibility, heartbeat, capacity, and current operator action.

5. Optional blind relay participation

Public VPN participation and encrypted ChatRelay/OnionMiddle participation are separate operator choices. Do not advertise relay capability until the public peer endpoint is reachable.

bash
cd /opt/aeronyx/AeroNyx
sudo ./deploy/node/aeronyx-node.sh chat-relay \
  --enable-chat-relay --yes
sudo ./deploy/node/aeronyx-node.sh onion-middle \
  --enable-onion-middle --restart --yes

For relay participation, [discovery] must also contain the externally reachable public_endpoint, public_discovery = true, and the correct region. Validate before restart:

bash
./target/release/aeronyx-server validate -c /etc/aeronyx/server.toml
sudo systemctl restart aeronyx-server
./deploy/node/aeronyx-node.sh relay-probe --two-hop --json

New nodes enter a warm-up period. They become route candidates only after fresh reachability and path-proof evidence is available. A configured capability is not the same thing as route eligibility.

Safe upgrades

Use the operator wrapper rather than a manual git pull followed by an unguarded restart:

bash
cd /opt/aeronyx/AeroNyx
sudo ./deploy/node/aeronyx-node.sh upgrade \
  --build-priority live \
  --build-jobs auto

The upgrade workflow checks active sessions, validates the candidate binary and configuration, records status, preserves rollback material, and verifies health after restart. Use --no-restart to stage a build for a later maintenance window.

AI-assisted installation standard

An AI terminal assistant may execute this workflow, but it must:

  1. identify the official GitHub repository and exact checkout path
  2. show the resolved plan before changing the host
  3. keep registration secrets out of command arguments and logs
  4. avoid compiling on an undersized production host when a verified staged binary is available
  5. check active sessions before restart or upgrade
  6. verify service health, backend heartbeat, public reachability, and discovery after changes
  7. report warnings honestly instead of declaring success from process state alone

Privacy boundary

Operational diagnostics may expose aggregate CPU, memory, disk, file-descriptor, conntrack, packet, capacity, heartbeat, and relay-proof status. They must not expose client public IP activity, destinations, DNS contents, packet payloads, browsing history, message plaintext, private keys, voucher secrets, MemChain plaintext, or wallet-level traffic.

Related references