Rust Privacy Node Operations and Health Checks
Day-two operations guide for AeroNyx Rust privacy nodes, including healthcheck, capacity, upgrades, Memory Chain readiness, and network maintenance.
Rust Privacy Node Operations and Health Checks
This guide covers day-two operation for AeroNyx Rust privacy nodes.
Operators should treat a node as production infrastructure. It participates in the AeroNyx privacy network, sends aggregate service metrics, and may later advertise encrypted storage or Memory Chain capability when those modules are enabled.
Daily checks
systemctl is-active aeronyx-server
journalctl -u aeronyx-server -n 100 --no-pager
In nodeboard, confirm:
- node online status
- heartbeat freshness
- service availability
- IP pool capacity
- active and historical aggregate sessions
- packet drops
- pps and bps
- conntrack and file descriptor pressure
- encrypted traffic counters
- encrypted packet forwarding counters
Capacity signals
Commercial operation needs capacity visibility. A node should expose:
| Metric | Why it matters |
|---|---|
| IP pool capacity | Shows how many client-facing network identities can be assigned. |
| Used IPs | Shows current resource pressure. |
| Remaining IPs | Helps placement and admission control. |
max_connections | Hard node-side connection limit. |
policy max_sessions | Business or safety cap from operator policy. |
| conntrack usage | Detects kernel connection tracking risk. |
| file descriptor usage | Detects process-level socket/file pressure. |
| packet drops | Indicates network or kernel pressure. |
| pps / bps | Shows packet and bandwidth intensity. |
Memory Chain and encrypted storage readiness
When encrypted storage or Memory Chain modules are enabled, nodeboard should show capability and health without exposing plaintext. Useful operator-level fields include:
- module enabled/disabled state
- encrypted object count
- storage pressure
- last sync height or last checkpoint
- proof or record verification status
- replication/sync health
The dashboard should never expose user plaintext, raw chat history, private memory contents, or decryption keys.
Maintenance routine
Before maintenance:
- check active aggregate sessions
- avoid forced restarts during high usage
- confirm nodeboard has recent heartbeat
- snapshot configuration if changing system settings
After maintenance:
- confirm
aeronyx-serveris active - confirm fresh heartbeat in nodeboard
- confirm packet drops are stable
- confirm encrypted counters resume when sessions are active
- confirm any Memory Chain or encrypted storage module reports healthy status