Go · protocol dh/v1|not yet production-validated

Host anywhere. Run everywhere.
Own the infrastructure.

Self-hosted infrastructure where hosts stay sovereign. A replicated control plane proposes work as signed intent; each host checks it against its own policy before anything runs, keeps its own hash-chained ledger, and reports what it actually observed.

Source
What is Decentralized.Host?

Decentralized.Host is self-hosted infrastructure software, written in Go, in which a replicated control plane proposes work as signed intent and each host decides under its own local policy whether to run it. Hosts keep hash-chained ledgers and report signed observations, and desired, admitted and observed state stay separate. M1–M8 are implemented and verified on a single machine; multi-machine Linux validation is in progress.

Source: README.md, docs/BLUEPRINT.md
Implemented
M1–M8

Sovereign runtime, storage, trust and mesh, edge and TLS, HA control plane, chaos, federation and protocol conformance. 15 capabilities verified, 6 limited, 4 missing or not run.

Latest record
REF-MAC-A03 · PASS

13/13 gate steps on the macOS reference machine, signed and re-verifiable: 10/10 integration, 17/17 chaos, conformance including an independent Python implementation. Source b3:2a23e1da….

Not yet shown
Linux · multi-machine

Every automated run so far is multi-process on one macOS machine over loopback. No test has crossed physical machines, a real WAN or NAT, or run on a Linux host. Linux validation (PV1-S1-A03) is pending.

> Real output

A real cluster, started on one machine

This replaces the old deployment simulator. It is a recording of the Go build: every line below was printed by the real binaries while 7 processes formed a cluster, admitted a 3-replica app and served it through the edge. You get the same by running the commands on .

Recorded sessionreal output · not a simulation
2026-09-25 09:35:00 UTC · Darwin 24.6.0 x86_64 · commit ef849e2
$ dh dev up --dir ./devcluster

Starts 3 control-plane members, 4 hosts (one of them the edge) as separate local processes, pushes the dh-beacon sample artifact and applies a 3-replica app.

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
exit 06.776s wall clockredacted: session token, scratch path, hostname
> The idea

The control plane proposes. The host decides.

Desired ≠ admitted ≠ observed

What you asked for, what hosts accepted under their own policy, and what they measured and signed are separate everywhere: API, CLI and console. Drift is derived, never hidden in one health score.

Hosts can say no

Each host pins the cluster root and runs 18 ordered checks before starting anything. A control plane holding a genuine member key still cannot make a host run work its policy refuses.

Unknown stays unknown

Values carry a truth basis: OBSERVED, DERIVED, CONFIGURED, PLANNED or UNKNOWN. Latency appears only where it was measured. A stalled view says LAST KNOWN STATE — NOT CURRENT.

> Operator console

Served by the cluster itself

Screenshots of the same recorded cluster, taken through a read-only session. The console is served by every control-plane member and loads nothing from third parties.

Console overview: desired 3, admitted 3, observed 3, refused 0, drift 0; 4 of 4 hosts with fresh evidence; Raft leader with 3 voters; audit head verified; milestone cards derived from live evidence.
Overview — separate counts, never one health score. Recorded 2026-09-25 on a local dev cluster.
Console hosts screen: four hosts, each ACTIVE, READY, new admission ALLOWED, with fresh signed observations; three control-plane members, one leader.
Hosts — identity, admission and runtime are separate columns.
Console audit screen: chain head verified, 3 signed checkpoints verified, ledger entries for snapshot commits, health passes and workload starts.
Audit — hash chain and signed checkpoints, re-verifiable with dh audit verify.
> Architecture

Three binaries, one protocol

attenuated capability · TLS
signed bundles · stateIndex
signed observations back to the control plane

Select a block for what it holds and does.

Control plane

dh-control · runs on 1, 3 or 5 machines
Holds
  • Raft log and snapshots (bbolt)
  • member identity and root-issued certificate
  • artifact CAS
  • optional Postgres mirror (never the source of truth)
Does
  • ›Replicates desired state through Raft over mutual TLS; the state machine is deterministic and holds the audit ledger.
  • ›Only the verified leader issues bundles, signs assignments and reconciles; every bundle carries a state index so hosts refuse rollback.
  • ›Scheduler plans placements deterministically; the reconciler turns plans into signed assignments with per-assignment capabilities and rolling updates.
  • ›Verifies host observations (host key, monotonic seq) and projects views where every value carries a truth basis.
  • ›Serves the operator console (no build step, CSP default-src 'self').
source: pkg/control, cmd/dh-control

The path of a deployment

  1. 01 · dh → control plane
    Apply

    A dh/v1 manifest is validated strictly (unknown fields rejected), normalized, hashed and committed through Raft as desired state.

  2. 02 · control plane
    Plan

    The deterministic scheduler filters hosts by tier, resources, architecture, features, anti-affinity and failure domain. `dh explain app` shows the plan.

  3. 03 · control plane (leader)
    Sign

    The reconciler issues signed assignments, each with a capability bound to one host, generation, artifact digest and resource ceiling.

  4. 04 · host
    Admit

    The host checks the pinned root, roster, signature, audience, generation, clock, capability chain, revocation, freeze, freshness and its own policy — 18 checks, in order.

  5. 05 · host
    Run

    Artifact chunks are fetched from peers and BLAKE3-verified; the admitted generation starts under the process or docker runtime.

  6. 06 · host → control plane
    Observe

    The host signs what it measured. Nothing is shown as running until a host has observed it; desired, admitted and observed stay separate.

  7. 07 · edge
    Route

    Edge hosts probe replicas over the mesh and route only to healthy ones.

  8. 08 · anyone with the ledger
    Verify

    `dh audit verify` checks the hash chain and signed checkpoints locally; hosts keep their own ledgers too.

> Capabilities

Each claim names its evidence

M1VERIFIED

Hosts admit work under their own policy

Every assignment passes 18 ordered checks on the host before anything runs: signatures, audience, generation, clock, capability chain, revocation, freeze, freshness, tier, runtime, digest, attestation, federation and resource caps. The control plane proposes; the host decides.

evidence: pkg/node/sovereignty_test.go — a host refuses a control plane that holds a genuine member key
M1VERIFIED

Control-plane outage is not a workload outage

If the control plane is frozen, unreachable or stale, admitted work keeps running (hold, not stop), new admissions are refused, and observations queue in an outbox that flushes on recovery.

evidence: chaos cp-total-outage (854/854 requests OK); m1_test.go
M1VERIFIED

Hash-chained audit you verify yourself

The control plane keeps a hash-chained ledger with signed checkpoints, and every host keeps its own fsynced journal. `dh audit verify` fetches the ledger and verifies the chain locally; backups and exports verify offline.

evidence: pkg/audit tests; 14 conformance vectors; chaos journal-corruption
M2VERIFIED

Content-addressed volumes with committed snapshots

BLAKE3 content addressing with FastCDC chunking, verified on every read. Snapshots commit only when 2 replicas return signed evidence; an interrupted write rolls back to the last committed snapshot, and a lost host is restored from peers byte for byte.

evidence: tests/integration/m2_test.go; chaos interrupted-storage-write, storage-replica-loss, disk-full
M5VERIFIED

Replicated control plane (Raft, mutual TLS)

Three or five members, a deterministic state machine, a leader-only bundle issuer, membership changes and leadership transfer. Leader loss does not interrupt workloads.

evidence: m5_test.go; chaos leader-crash — 1.2–2.2 s to a new leader, 0 failed requests (single machine, loopback)
M6VERIFIED

17 chaos scenarios on real disposable clusters

Leader crash, total control-plane outage, host crash, agent restart, journal corruption, network partition, packet chaos, clock skew, stale generation, replay/forgery, revoked host, storage replica loss, disk full, OOM, interrupted deployment, interrupted storage write and Postgres outage — each under traffic with invariants checked and a signed report.

evidence: dh chaos run --scenario all (17/17 in REF-MAC-A03)

What it does not do yet

  • › No run has crossed physical machines, a WAN or NAT, or used Linux.
  • › ACME is tested only against Pebble, never a public CA.
  • › The process runtime does not enforce CPU or memory limits.
  • › No 24-hour soak, fuzzing or external security review yet.
  • › No git-push builds or buildpacks: you deploy executables or digest-pinned images.
  • › No signed release binaries or upgrade path yet; build from source.
  • › Erasure coding, HTTP/3, containerd, gVisor and Firecracker are not implemented.
  • › No token, credits or marketplace — and none are planned.

See it for yourself

You need Go 1.26 or newer. Every run so far has been on macOS; Linux validation is pending. Once built, the recorded cluster started in 6.8 seconds.

shell
$ git clone https://github.com/CodesbyFebin/Decentralized-.git decentralized.host
$ cd decentralized.host && make build
$ ./bin/dh dev up --dir ./devcluster