Run It Yourself

00Requirements

• › Go 1.26 or newer, git and make. Nothing else is needed for the local cluster.
• › Optional: Docker (container runtime and the oom chaos scenario), Python 3 (independent conformance implementation), Postgres (evidence mirror).
• › Every run so far used macOS. Linux should work, but it has not been validated yet (PV1-S1 is pending).

01Build and start a local cluster

$ git clone https://github.com/CodesbyFebin/Decentralized-.git decentralized.host
$ cd decentralized.host
# optional: check out the exact revision that passed the reference run
$ git checkout ref-mac-a03
$ make build
$ ./bin/dh dev up --dir ./devcluster

dev up starts 3 control-plane members and 4 hosts (one of them an edge) as separate processes bound to loopback, pushes the dh-beacon sample artifact, deploys a 3-replica app and prints a console URL. Dev clusters serve the API without TLS unless you pass --tls; a real installation uses TLS by default.

02Look around

$ export DH_HOME=./devcluster/operator
$ ./bin/dh get apps
$ ./bin/dh describe app web      # desired / admitted / observed, and every admission check
$ ./bin/dh mesh peers            # WireGuard handshakes and measured RTT
$ ./bin/dh audit verify          # fetch the ledger, verify chain and checkpoints locally
$ ./bin/dh chaos run --scenario leader-crash

This is what those commands printed on the reference machine. Your identifiers, timings and ports will differ; the shape should not.

cluster dev: root key EYpyLqc4JrBBnN9oKo9uR2PzyItlmh0W_thMZdRAI24 (dh1moxcikagjbglhwfnm3yhzxyi2i)
root CA ./devcluster/operator/dev/root-ca.pem
Keep ./devcluster/operator/dev/root/identity.key private: it is the trust anchor every host pins.
• starting 3 control-plane member(s)
bootstrapped dh1cqtai3x2ugv27ajz6x6xvg43ob: cluster dev initialized
member dh1wy2x6dkhlmcdzay46pdsiu3rc4 added (roster v2, 2 members)
member dh1qn4s24gwcmp7ugv4c6ietg2u53 added (roster v3, 3 members)
• starting 4 host(s) (1 edge)
• pushing the dh-beacon artifact and applying the sample app
attestation stored for b3:87f2505fb60558d69744209dc3540a9ac54c53d87a6e68c2966ebd01981ae34f
  web: created (generation 1)

Cluster "dev" is running: 3 control-plane member(s), 4 host(s), 1 edge.
  console:   http://127.0.0.1:17701/#token=<session capability — redacted>
  operator:  export DH_HOME=./devcluster/operator
  edge:      curl -H 'Host: web.dev.test' -H 'X-DH-No-Redirect: 1' http://127.0.0.1:18103/
  logs:      ./devcluster/logs
  stop:      dh dev down --dir ./devcluster

03Deploy your own executable

The process runtime runs an executable from the cluster's content-addressed store. It receives its port in $PORT and should answer the health path. Build it for the hosts' OS and architecture.

$ ./bin/dh artifact push ./myservice --name myservice --sign     # prints myservice@b3:<digest>

$ apiVersion: dh/v1
$ kind: Application
$ metadata: {name: web}
$ spec:
$   replicas: 2
$   image: myservice@b3:<digest>
$   resources: {cpu: 100m, mem: 32Mi}
$   placement: {tiers: [trusted], spread: failure-domain, antiAffinity: hard}
$   ports: [{name: http}]
$   health: {http: /healthz, interval: 1s}

$ ./bin/dh apply -f web.yaml
$ ./bin/dh rollout status app web
$ ./bin/dh describe app web

For a container, set image to a digest-pinned reference such as busybox@sha256:<64 hex>; the manifest then selects the docker runtime, which enforces memory and CPU limits. Unpinned images are refused. Manifests are strict: unknown fields are rejected.

04Open the console, then stop

$ ./bin/dh console --read-only   # prints a URL; the session token is in the #fragment
$ ./bin/dh dev down --dir ./devcluster

05Across real machines

The install runbook covers a TLS cluster with three control-plane members and hosts that join with single-use tokens. It is scripted and passed on the reference machine, but it has not yet been run across separate machines — that is exactly what PV-1 stage 2 will test. Follow docs/runbooks/install.md or the TLS install guide.