id: services title: The component that can mint a hostname is not the component serving agent data status: open crates: [didbot-serve, didbot-pds, didbot-tls, didbot-dns] dependsOn: [] exitCriterion: > The process serving com.atproto.* traffic holds neither the zone credential nor the ACME account key, and losing it does not stop a certificate from renewing or a name from resolving. #

services #

docs/deployment.md states the current shape plainly: the zone credential "lives beside" the signing keys, "reachable from the process" because the server writes its own DNS records. One process holds the signing keys, the zone credential, the ACME account key and every agent's repository. Its own configuration-tiers table has one row for all of it. Compromise that process and you can serve arbitrary did.json documents, pass DNS-01 for any name in the zone, and sign as any account it holds — three different kinds of total control, from one exposure.

This is not fleet. Fleet is several whole personal data servers — separate zones, separate keys, separate operators' worth of blast radius, operated as a set from above. This is one deployment, decomposed so that the piece which can mint a hostname and answer a DNS-01 challenge is not the piece an attacker reaches by finding a bug in repository-write handling. Ten small blast radii and one smaller one are different problems, and an epic that tried to be both would serve neither well.

What is one process today, and why that is the risk worth naming first #

docs/deployment.md's posture table already grades this: moving agents off the server host is "the step that matters and the cheapest", because it moves the keys and the zone credential off the machine running agent code. That step says nothing about the server host itself, where the same three capabilities still sit together:

• DNS issuance. crates/didbot-dns's Route53Dns holds the credential that writes the zone — scoped to one hosted zone, per the IAM policy in docs/deployment.md, but reachable from whatever process imports the crate.
• TLS issuance. crates/didbot-tls holds the ACME account key and orders certificates, including the wildcard pair agent-accounts describes per zone.
• Repository serving. crates/didbot-pds and crates/didbot-serve hold every account's signing keys and answer every com.atproto.* request, including from the public internet, unauthenticated, for a good fraction of the surface.

Only the third of these needs to be reachable by an arbitrary caller. The first two need to be reachable by nothing except the provisioning and renewal paths that call them.

• Say which capability moves, and to what. Splitting a crate boundary is not splitting a process boundary; didbot-tls and didbot-dns already are separate crates and that has not reduced the blast radius, because both still link into the one binary that serves requests. What has to be decided is whether issuance becomes a separate process on the same host, a separate host, or stays in-process behind a narrower internal interface — and that decision has to be made against a concrete threat (a bug in repository-write handling, not an insider) or it is architecture for its own sake.
• A provisioning and renewal interface the serving process calls, rather than a set of crates it links. Provisioning already asks for a DNS write and a certificate; today that is a function call, and it would become a request to a component that does not also parse untrusted repository writes.
• Say what the split does not fix. Splitting issuance out does not remove the zone credential from the deployment, and does not change that whoever holds the issuance component still controls every name under the zone. It narrows which failures reach that control, not how much control exists.
• Failure mode of the split itself. An issuance component that is down cannot provision a new account or renew a certificate before expiry. e-stop says the emergency stop has to work when the network to the operator's own server is unreachable; a services split has to say what provisioning does when its own issuance component is the thing that is unreachable, rather than silently blocking forever or silently falling back to holding the credential in-process again.
• Relate to docs/deployment.md's tier table. That table names three configuration tiers reachable from the host; this epic is about process tiers, which is a different axis, and the two need to agree rather than be read as the same idea twice.

Done #

Nothing closed yet.