Run your own NANDA Node
Fork the codebase, provision a handful of Cloudflare bindings, and you have a federation-capable agent registry running on your own domain — for data residency, air-gapped deployments, or as an alternative trust anchor in the NANDA network.
Prerequisites
- • Cloudflare account with Workers Paid plan (D1, R2, KV, Queues access).
- • Node.js 20+ and pnpm 10.
- • A domain you control (for your node URL and .well-known agent discovery).
- • Familiarity with Cloudflare Wrangler and SvelteKit 2.
Fork & deploy
The node itself is not yet a fully public repository, but the shape of the deploy is stable. The pattern below is what Nexartis-operated nodes use today.
Migrations are hand-written SQL in drizzle/migrations/. Never run drizzle-kit push — that will corrupt your schema journal.
Point the SDK at your node
The TypeScript SDK works against any conformant NANDA Node — just pass your own baseUrl.
Node configuration
Once deployed, visit /admin/settings as an authenticated operator to set your node's
public metadata, moderation policies, federation peers, and invitation flow. Per-node branding lives
under Pegasus-managed public pages; infrastructure services are frozen and should not be forked-and-modified
lightly.
Security considerations
- • Store Ed25519 signing keys in Cloudflare Secrets Store — never in
wrangler.jsoncor environment variables. - • Rotate
CRON_AUTH_TOKENand HMAC secrets on a documented schedule. - • Federation gossip is signed but not encrypted — treat peer lists as semi-public.
- • Enable ZTAA middleware and rate limits before accepting public API traffic.
Self-hosted nodes are responsible for their own uptime, backups, and incident response. Nexartis does not provide SLA coverage for third-party deployments during the beta.