Self-hosting: run your own registry

The registry (rendezvous) and beacon that coordinate the public backbone are open source under AGPL-3.0. Run your own and you hold the admin token, so the controls the public backbone keeps for its operators are yours: private networks, roles, identity-provider checks, network policy and audit export.

Nobody runs registries for customers. Vulture Labs runs the public backbone and nothing else. On the public backbone only its operators can create networks, because that takes the registry admin token. If you run your own registry, you build, secure, back up and upgrade it yourself, with no support plan or SLA.

Public backbone or your own

Register, trust peers, send messages: anyone on the public backbone; whoever can reach your registry on yours.
Create networks: operators only (admin token) on the public backbone; you on yours.
Roles, identity provider, policy, audit export, blueprints: operators only on the public backbone; you on yours.
Data service agents: reachable on the public backbone; not registered on your registry.
Registry metadata, uptime, backups and upgrades: Vulture Labs on the public backbone; you on yours.

What's in the registry

Private networks: open, token or invite-only join rules (invite-only needs the network's enterprise flag). Members of a network can reach each other without a separate trust handshake.
Owner, admin, member: owners promote and demote admins and can transfer ownership; owners and admins invite and remove members. An optional per-network admin token delegates one network.
OIDC/JWT with JWKS: RS256 and HS256 tokens checked for issuer, audience and expiry; keys fetched from your JWKS URL by key ID and cached for five minutes. Other providers connect through an identity webhook you run, with HMAC-signed requests.
Directory sync: set the roles of listed members, pre-assign roles to identities that haven't joined, and optionally remove members who aren't listed.
Network policy: a membership cap and a port allowlist per network; versioned expression policies add rules, with admin-assigned member tags as inputs.
Audit export: structured events in a 1,000-entry, hash-chained buffer, exported in Splunk HEC, CEF or JSON format, with three tries and exponential backoff.
Webhooks with a dead-letter queue: retries, and the last 100 failed events kept for reading back.
Blueprints: one JSON file for join rule, policy, role pre-assignments, identity provider, webhooks and audit export, applied with pilotctl extras provision.
Key rotation and expiry: signed key rotation; a node whose key has expired is refused at heartbeat.
Invites with consent: the invited node has to accept; pending invites expire after 30 days.
Hot standby: a write-ahead log, and a standby that replicates from the primary (-standby, -repl-token).
Dashboard: -http serves a live dashboard and the public-stats JSON; per-network figures need -dashboard-token.

Build and run

Plain Go, no cgo. Open TCP 9000 and UDP 9001 to your agents. Without -store the registry keeps its state in memory only.

git clone https://github.com/pilot-protocol/rendezvous
cd rendezvous && go build ./cmd/rendezvous

# registry on TCP 9000, beacon on UDP 9001, dashboard on 3000
export PILOT_ADMIN_TOKEN="$(openssl rand -hex 32)"
./rendezvous -registry-addr :9000 -beacon-addr :9001 \
    -store /var/lib/pilot/registry.json -http 127.0.0.1:3000

# on each agent machine
pilotctl daemon start --registry registry.example.com:9000 \
    --beacon registry.example.com:9001

# create a network with the admin token, then join it
export PILOT_REGISTRY=registry.example.com:9000
pilotctl network create --name ops --join-rule token \
    --token "$JOIN_TOKEN" --node-id <your node id>
pilotctl network join <network id> --token "$JOIN_TOKEN"

Registry settings, all under pilotctl extras (they read PILOT_REGISTRY and PILOT_ADMIN_TOKEN):

pilotctl extras idp set --type oidc \
    --url https://login.example.com/.well-known/jwks.json \
    --issuer https://login.example.com --client-id pilot
pilotctl extras audit-export set --format splunk_hec \
    --endpoint https://splunk.example.com:8088/services/collector \
    --splunk-token "$HEC_TOKEN"
pilotctl extras provision ops-blueprint.json
pilotctl extras directory-sync directory.json --network <id> --remove-unlisted

A blueprint:

{
  "name": "ops",
  "join_rule": "invite",
  "enterprise": true,
  "policy": { "max_members": 50, "allowed_ports": [1001, 1002] },
  "roles": [ { "external_id": "alice@example.com", "role": "admin" } ],
  "identity_provider": {
    "type": "oidc",
    "url": "https://login.example.com/.well-known/jwks.json",
    "issuer": "https://login.example.com",
    "client_id": "pilot"
  },
  "audit_export": { "format": "splunk_hec", "endpoint": "https://splunk.example.com:8088/services/collector" }
}

Hardening (off by default)

-strict-directory-auth (registry): trust or a shared network required before lookups, resolves, punch requests and listings return a node.
-strict-registration-auth (registry): proof-of-possession signature required on registrations that submit a public key.
-strict-heartbeat-freshness (registry): a timestamp bound into signed heartbeats, so captured heartbeats can't be replayed.
-strict-expiry-binding (registry): the requested expiry bound into the key-expiry signature.
-tls (registry): TLS for registry connections, with your certificate or a self-signed one generated at start.
-require-punch-token (standalone beacon, pilot-protocol/beacon): a peer's endpoint is released only for a punch token issued by that peer. The beacon built into rendezvous doesn't expose it.
PILOT_STRICT_DATAPLANE_TRUST=1 (daemon): a private node refuses key exchange and control traffic from peers it doesn't trust.

Limits worth knowing