Bootstrap relay lists for Peerbit applications.
Use the list matching the Peerbit client/network version:
The source files on GitHub are an independent emergency fallback:
- v4: https://raw.githubusercontent.com/dao-xyz/peerbit-bootstrap/master/bootstrap-4.env
- v5: https://raw.githubusercontent.com/dao-xyz/peerbit-bootstrap/master/bootstrap-5.env
The two files are deployed atomically as static assets on an asset-only Cloudflare
Worker. wrangler.jsonc owns the bootstrap.peerbit.org custom domain, including
DNS and TLS. There is no Worker application code and no AWS dependency.
Every deployment validates the source format, builds dist/ from scratch, runs a
Wrangler dry run, and verifies production after deployment. Production verification
requires exact bytes and SHA-256, strict HTTPS, CORS, cache and security headers,
ETag revalidation, and a 404 for unknown paths.
Wrangler and all of its transitive dependencies are installed from the committed lockfile without lifecycle scripts before deployment credentials enter the process.
The stable filenames intentionally use:
Cache-Control: public, max-age=0, must-revalidate
This allows ETag revalidation without leaving clients on a stale relay list.
The deploy job requires these environment-scoped values:
- Secret
CLOUDFLARE_API_TOKEN - Variable
CLOUDFLARE_ACCOUNT_ID
The token is scoped to this Cloudflare account and only:
- Account → Workers Scripts → Write
peerbit.orgzone → Workers Routes → Write
It does not need DNS, Pages, R2, KV, billing, or token-management access.
Rollback is a revert on master, which redeploys the prior atomic asset version.
Cloudflare deployment rollback remains available for an emergency platform-side
rollback.
Monitor bootstrap production runs every 15 minutes and can also be dispatched manually. It
does not receive deployment credentials. It compares the public files with the
repository and probes every advertised relay for:
- matching public IPv4 answers from Google and Cloudflare DNS;
- strict TLS on the peer API and at least 14 days of certificate validity;
- the exact advertised peer ID; and
- a valid WebSocket upgrade and accept hash on port 4003.
Automated relay provisioning is temporarily disabled. The previous workflow depended on the retired AWS-backed test-domain service, exported the administration API port instead of the relay multiaddr, and launched Peerbit outside a service manager.
Existing nodes must be recovered in place without deleting or resetting
/root/.peerbit. Re-enable provisioning only after the Cloudflare DNS and
systemd-supervised implementation has been released and validated. A node must not
be added to a bootstrap file until DNS, strict TLS, exact peer identity, public WSS,
a real libp2p dial/reservation, service enablement, and restart recovery all pass.
Rolling Bootstrap Self-Update performs rolling updates of the advertised fleet
through each node's remote self-update API, with preflight health checks and
batch-by-batch rollout. If a batch fails, it can roll updated nodes back to their
per-node previous @peerbit/server version.
Changing rollouts/bootstrap-5.json on master triggers Deploy Bootstrap Rollout.
Its secret-free validation job must pass before the direct production-environment
job can access the administration key. Nodes already on the requested version are
skipped.
The signed-request v1 to v2 migration used exact, lockfile-pinned v6 and v8 admin clients. After the verified fleet-wide v8 rollout, the temporary v1 client was retired. Current tooling uses only signed-request v2: it pins the peer ID from the bootstrap multiaddr, verifies the signed authentication descriptor, and checks the complete target dependency fingerprint. The completed v6-to-v8 configuration is kept as an inert audit record and cannot initiate another legacy transition.
For active v8-to-v8 rollouts, the local package and lockfile pin the target admin
client and its npm SHA-512 integrity. rollbackIntegrity is reviewed audit metadata
for the remote package selected by selfUpdate; it is not installed as a local
alias. Exact authenticated dependency fingerprints enforce both the source
preflight and rollback result. CI validates the config, lockfile, package metadata,
state-machine tests, and high/critical dependency audit before the production job
can access its secret.
The npm graph installs without the React Native peer subtree. The Node
implementation of the Peerbit WebRTC transport uses node-datachannel;
react-native-webrtc is loaded only under React Native, and its
react-native >= 0.60.0 peer requirement was the sole path that pulled the
vulnerable react-native -> metro -> image-size subtree (CVE-2025-71330 and
CVE-2025-71329) into these Node-only relays. The committed lockfile contains no
peer-only nodes, .npmrc sets legacy-peer-deps=true so npm does not
reintroduce them, and every workflow that installs dependencies fails if
react-native, metro, metro-config, metro-transform-worker, or
image-size appears in the lockfile or resolves from the installed tree. Those
workflows then run npm audit --omit=dev --omit=peer --audit-level=high
directly, with no exception machinery, and smoke-test the @peerbit/server,
@peerbit/crypto, and @dao-xyz/borsh import surface that the rollout tooling
uses at runtime.
Rollouts run only from a reviewed master push; direct arbitrary-version dispatch
and broad secret inheritance are disabled. The production environment provides
PEERBIT_ADMIN_KEY_B64, containing the base64-encoded serialized Peerbit admin
keypair trusted by the bootstrap nodes.