Simple for users — without weakening control.

NABD BaaS keeps the daily surface easy, while admins retain clear authority over access, sensitive actions, tokens, and audit review. The principles below hold whether the backend is local SQLite or production Postgres.

Required controls

  • Tenant-scoped users and API tokens.
  • Clear separation between viewer · operator · admin · super-admin.
  • Token hashes are stored, never the raw token.
  • Wallets, signing material, and cloud credentials live outside the web app.
  • Maintenance flows through the allowlist — no shell access from the portal.
  • Network create, token issue, maintenance request, and job result all emit audit events.

Production checklist

IdentityReplace local bootstrap tokens with tenant login and signed sessions.
RolesEnforce viewer · operator · admin permissions before every action.
SecretsUse managed secret storage (KMS/HSM) for keys and credentials.
ReleaseDeploy signed, scanned images; generated load balancers pin NGINX 1.30.2+ stable or 1.31.0+ mainline.
QueuesHarden the queue lock for concurrent workers before scaling.
AuditPipe audit_events to an external append-only store for retention.

Trust boundary

The frontend never reaches Docker, node files, wallet JSON, or shell commands. It talks to the API. The API writes a job. The worker is the only component that spawns NABD CLI subprocesses, and it only does so for actions in the shared allowlist.

If you add a new maintenance action, register it in packages/shared/src/maintenance-actions.ts AND in the worker’s command map. The API will refuse anything that is not in both.