Running a Nostream relay still requires too much terminal, SQL, log, and configuration-file knowledge, Operators need to monitor relay health, tune settings.yaml, inspect traffic, moderate abusive clients, review admission payments, without SSHing into a server or writing database queries.
This is really important for hosted deployments. A user should be able to deploy the latest Nostream image on a provider, open a secure web admin console, configure the relay, monitor it, and operate it day to day with minimal terminal usage.
I propose to Add an admin console for Nostream. This should be treated as an operator platform, not only a metrics dashboard.
The console should provide:
- Secure admin login, eventually using NIP-98 once merged from SoB !
- Live dashboard for relay health, EPS, active connections, subscriptions, and system resources.
- Visual
settings.yaml editor that validates changes and applies them through the existing hot-reload path without requiring relay restarts.
- Quick moderation actions for pubkeys, IP addresses, event kinds, rate-limit bypass lists, and admission-fee whitelists.
- Event search and inspection without SQL knowledge, starting with structured relay filters and later using NIP-50 when implemented.
- Admission/payment operations views for sats earned, pending invoices, failed callbacks, paid admissions, and payment processor health.
- Webhook management for admission and payment notifications to generic HTTP, Discord, Slack, and Telegram targets.
- Groundwork for relay operations NIP-89 to manage start/stop/restart any stats/logs for deployed services.
This will be shipped over 8 PRs by me + combining Sob NIP-50/98/89 PRs, Dashboard PRs, Metrics PR by other contributors
CC: Cameri approved this final desgin:

Phase 1: Admin backend foundation
Authenticate the relay operator before any admin data is exposed.
- Temporary admin password login until NIP-98 Sob lands :)
- Add admin config settings
- Add protected admin router mounted only when enabled.
- Add admin auth middleware with a replaceable auth interface.
- Add
GET /admin/health.
- Add
GET /admin/session or equivalent.
- Add unit tests for disabled-by-default behavior and auth.
Phase 2: Live metrics
Give operators a fast read on whether the relay is healthy
related work: #439 #464 #468
related issues: #144
- Add cluster-aware runtime counters where possible.
- Add lightweight health checks for DB and Redis.
- Add live updates through WebSocket or server-sent events.
- Avoid heavy DB polling for metrics that can be tracked in memory.
- EPS, Accepted/rejected events, Active WS, CPU/RAM load, Worker Count/Health
for reference:

Phase 3: Settings editor
Safely edit relay configuration from the browser
related issues: #229 #197 #199 #344
- Read and validate current settings.
- Schema-aware editing for common settings.
- Preview diffs.
- Atomic write to
.nostr/settings.yaml.
- Timestamped backup before each write.
- Audit log entry for every applied change.
- Use the existing hot-reload behavior where possible.
Phase 4: Moderation
Review abusive activity, Whitelist/Blacklist
related issues: #226 #124
- Add admin endpoints for existing whitelist/blacklist capabilities.
- Add views for rejected events, top pubkeys, top IPs, and rate-limit hits.
- Top publishing pubkeys.
- Top client IPs.
- Rate-limit hits.
- Duplicate/spam-like activity indicators.
- Ban/unban pubkey.
- Whitelist/unwhitelist pubkey.
- Whitelist/unwhitelist IP for rate-limit bypass.
- Edit event kind whitelist/blacklist values.
for reference:

Phase 5: Event Search and Inspection
Inspect stored relay events without SQL.
related work: #262
- Integrate NIP-50 once SoB lands :)
- Search by event id.
- Search by author pubkey.
- Search by kind.
- Search by tag filters.
- Search by created-at range.
- Search with a result limit.
Phase 6: Payments and admissions
Operators can view revenue and admissions status.
related issues: #342
- Total admission fees recorded.
- Pending, paid, expired, and failed invoices.
- Recent admissions by pubkey.
- Payment processor health.
- Callback failure history.
- Manual invoice lookup.
- Admission whitelist management.
for reference:

Phase 7: Webhooks and Notifications
Notify operators when important relay events happen
- Discord/Telegram/Slack/Generic HTTP target.
- Per-event enable/disable controls.
- Test delivery button.
- Retry policy.
- Delivery history.
- Admission invoice created/paid/failed.
- Settings changed / relay restart
Phase 8: System, Logs, and Operations
Operators can view relay logs
- NIP-89 once merged from SoB :)
- Read-only recent logs or log tail.
- Worker health.
- Relay uptime.
Security requirements
- Admin console must be disabled by default untill NIP-98.
- Never expose secrets from
.env, payment processor credentials, NWC URLs, or private keys.
- Validate every settings change before writing.
- Require audit records for all mutating admin actions.
- Use timing-safe comparisons for token or webhook secret checks.
- Require HTTPS or trusted reverse proxy guidance for remote admin access.
Running a Nostream relay still requires too much terminal, SQL, log, and configuration-file knowledge, Operators need to monitor relay health, tune
settings.yaml, inspect traffic, moderate abusive clients, review admission payments, without SSHing into a server or writing database queries.This is really important for hosted deployments. A user should be able to deploy the latest Nostream image on a provider, open a secure web admin console, configure the relay, monitor it, and operate it day to day with minimal terminal usage.
I propose to Add an admin console for Nostream. This should be treated as an operator platform, not only a metrics dashboard.
The console should provide:
settings.yamleditor that validates changes and applies them through the existing hot-reload path without requiring relay restarts.This will be shipped over 8 PRs by me + combining Sob NIP-50/98/89 PRs, Dashboard PRs, Metrics PR by other contributors
CC: Cameri approved this final desgin:

Phase 1: Admin backend foundation
Authenticate the relay operator before any admin data is exposed.
GET /admin/health.GET /admin/sessionor equivalent.Phase 2: Live metrics
Give operators a fast read on whether the relay is healthy
related work: #439 #464 #468
related issues: #144
for reference:

Phase 3: Settings editor
Safely edit relay configuration from the browser
related issues: #229 #197 #199 #344
.nostr/settings.yaml.Phase 4: Moderation
Review abusive activity, Whitelist/Blacklist
related issues: #226 #124
for reference:

Phase 5: Event Search and Inspection
Inspect stored relay events without SQL.
related work: #262
Phase 6: Payments and admissions
Operators can view revenue and admissions status.
related issues: #342
for reference:

Phase 7: Webhooks and Notifications
Notify operators when important relay events happen
Phase 8: System, Logs, and Operations
Operators can view relay logs
Security requirements
.env, payment processor credentials, NWC URLs, or private keys.