Question 1

Is Decentralized.Host production-ready?

Accepted Answer

No. M1–M8 are implemented and pass a signed reference run, but 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. Public ACME, a 24-hour soak, upgrades, fuzzing and an external security review are also outstanding. The roadmap page lists exactly what must pass before a release candidate.

Question 2

What does "decentralized" mean here?

Accepted Answer

Authority is split. A replicated control plane can only propose work as signed intent; each host decides under its own policy whether to run it, keeps its own ledger, and reports signed observations. Independent clusters can cooperate through root-signed federation agreements. It does not mean a blockchain, a token or a public marketplace.

Question 3

Is there a token, credits or rewards for running a host?

Accepted Answer

No. There is no token, payment, staking or reward mechanism, and none is planned. (The earlier Python prototype that used this domain had Solana devnet credits; the Go implementation does not.)

Question 4

What happens if the control plane goes down?

Accepted Answer

Hosts enter offline-hold: work they already admitted keeps running, new work is refused, and observations queue in a local outbox that is flushed when the control plane returns. The cp-total-outage chaos scenario kills every member for 15 seconds under traffic and checks that no request fails.

Question 5

Can a compromised control plane make my host run anything?

Accepted Answer

Not anything. A member key can only sign within its root delegation, and every host checks each assignment against its pinned root, the capability chain and its own policy.yaml (tiers, runtimes, digest pinning, attestation, caps) before running it. A member can still sign harmful-but-permitted work, such as scaling an app to zero; use `dh freeze` if you suspect compromise.

Question 6

Do I need Docker?

Accepted Answer

No. The process runtime runs signed executables from the cluster's own content-addressed store. Docker is the second runtime, for digest-pinned container images, and the only one that enforces CPU and memory limits today.

Question 7

Can I git push to deploy, or does it build my code?

Accepted Answer

No. There is no git-push deployment, build service or framework detection. You build an executable or image with your own tools, push it with `dh artifact push` (or reference an image by sha256 digest), and apply a dh/v1 manifest.

Question 8

Does it run on Linux?

Accepted Answer

It is meant to, and an offline Linux amd64 kit exists to prove it, but the first authoritative Linux run (PV1-S1-A03) has not happened yet. Every verified result so far is from macOS. An earlier diagnostic run in a starved Linux container found two real defects, which were fixed with regression tests.

Question 9

Is it open source?

Accepted Answer

The Go repository is public, but it has no LICENSE file yet. Until one is added, the default is all rights reserved: you can read the code and run it to evaluate it, but it is not licensed for redistribution or reuse. The earlier Python prototype is MIT-licensed; that license does not cover the Go implementation.

Question 10

How is this different from Kubernetes, Nomad or Coolify?

Accepted Answer

Those tools assume the control plane is trusted to command nodes. Here the host is the final authority over its own machine, every state transition is signed and journaled, and desired, admitted and observed state stay separate. In exchange it is far smaller and younger: fewer runtimes, no build pipeline, no ecosystem, and no production validation yet.

Question 11

Where does the data on this site come from?

Accepted Answer

From the Go repository: docs/BLUEPRINT.md for capability status, evidence/INDEX.md and the signed validation records for results, and a recorded session of the real binaries for the terminal output. Nothing on the site is generated in the browser or estimated.

Question 12

What is not implemented?

Accepted Answer

Erasure-coded volumes, HTTP/3, containerd/gVisor/Firecracker runtimes, `dh volume snapshot`/`restore`, CPU and memory enforcement for the process runtime, signed release binaries and an upgrade path, automated browser tests, and did:dh owner identities.