[ Switch to styled version → ]


← Docs index

Self-hosting the registry

Private networks, roles, identity, policies, audit export and blueprints in the open-source registry, for anyone who runs their own.

Who can use these features. Every operation in this section needs the registry admin token (some network operations also accept that network’s own admin token or an owner/admin role). On the public backbone run by Vulture Labs only the operators hold the admin token, so you can’t create or administer networks there. To use these features, run your own rendezvous and point your daemons at it.

Overview

The rendezvous server (github.com/pilot-protocol/rendezvous, AGPL-3.0) is the registry and beacon that daemons connect to. Besides addresses and trust, it can run networks with the controls a private deployment needs: role-based access control (RBAC), identity provider integration, membership policies, structured audit logging, and declarative provisioning through blueprints.

Plain networks treat membership as a binary boundary. Networks in enterprise mode add layers for access control (RBAC), identity and directory synchronization, traffic permissions (port policies), event logging (audit), and configuration (blueprints).

Run your own registry

One rendezvous process serves the registry (TCP) and the beacon (UDP). Set an admin token when you start it; with no token, network creation is disabled.

# Build and start the registry + beacon
git clone https://github.com/pilot-protocol/rendezvous
cd rendezvous && go build ./cmd/rendezvous
./rendezvous -registry-addr :9000 -beacon-addr :9001 \
  -store ./registry.json -admin-token "$PILOT_ADMIN_TOKEN"

# Point a daemon at it
pilotctl daemon start --registry registry.example.com:9000 --beacon registry.example.com:9001

# Admin commands read the registry address and token from the environment
export PILOT_REGISTRY=registry.example.com:9000
export PILOT_ADMIN_TOKEN=your-admin-token

pilotctl also reads the token from admin_token in ~/.pilot/config.json. The registry admin commands sit under `pilotctl extras`; run it with no arguments for the list. See Self-hosting for running the registry in production.

Enable enterprise mode

Enterprise mode is set per network. Enable it at creation time:

pilotctl network create --name prod-fleet --enterprise --join-rule invite

`network create` needs the registry admin token. `--join-rule` is `open` (the default), `token` (with `--token`), or `invite`, which requires `--enterprise`. The creator node (`--node-id`) becomes the network’s owner; enterprise mode is what makes the roles enforceable.

Feature summary

Enterprise gating

Some features require enterprise mode on the network, while others are available for all networks.

Features that require enterprise mode:

Features available to all networks:

Attempting an enterprise operation on a non-enterprise network returns an error. The setting is toggled by the registry's `set_network_enterprise` RPC or the Go SDK's `client.Client.SetNetworkEnterprise`. Membership is preserved when toggling.

Network creation and deletion, per-network admin tokens and blueprint provisioning are gated by the admin token, not by enterprise mode. Blueprint provisioning only enables enterprise when the blueprint explicitly requests it.

What’s next

Related