Use cases

Start with the certificate

A hostname alone is not reachable over HTTPS. It needs a certificate that matches it, and getting one is where most setups stall.

HTTP-01 validation requires a certificate authority to open a connection back to the machine. Anything behind NAT, on a private range, or on a host with no port 80 fails that test and cannot get a certificate at all. Wildcards cannot use it either, by design.

Every hostname can return its own DNS-01 credential, scoped to that one hostname and nothing else, in the acme-dns format certbot, Caddy, Traefik, lego, and cert-manager already speak. We publish the challenge record on our side, so the CA never has to reach your machine. Private addresses and wildcards stop being special cases and become the ordinary path. It is available on every plan.

The quickstart walks the whole thing, and the DNS-01 endpoints are documented in full.

Agent-spawned compute

The agent registers the address it was just given and gets a hostname back in the same response, already resolving. Caddy on the box picks it up and HTTPS is live about a minute later. When the machine is replaced, the next one PUTs its address onto the same hostname and everything pointing at that name keeps working - the URL the agent handed out does not change.

MCP servers

Each customer's MCP server boots, registers its IP, and comes up on its own hostname with its own certificate. Because the address is not encoded in the hostname, you can move that server between machines, regions, or providers with a single PUT and every client that already has the URL keeps working.

A2A agents

A2A discovery starts with an Agent Card served over HTTPS, at /.well-known/agent-card.json since v1.0 and at the older /.well-known/agent.json for clients that have not caught up. That is a public HTTPS endpoint on a name a calling agent already holds, which makes the hostname part of the contract rather than a deployment detail. Mint one, serve the card from it, and repoint it with a PUT when the agent moves. Callers that cached the card keep working, because the name they cached did not change.

Agent platforms

Hold as many dedicated domains as you need. You mint hostnames beneath them through the same API, and you decide which customer sits on which domain - so one customer's reputation, certificate budget, and cookie origin are not shared with the next. Same endpoints as a single developer uses, different scale.

Edge and device fleets

A fleet behind NAT or on an internal network cannot be reached by a certificate authority, which rules out HTTP-01 entirely. DNS-01 is the only self-serve path, and it is the reason a device nothing on the public internet can reach still gets a publicly trusted certificate for its own hostname.

SPIFFE and SPIRE

SPIRE can attach a DNS name to an X509-SVID, with spire-server entry create -dns, which puts the name in the certificate it issues. A workload can hold a SPIFFE ID and a minted hostname at the same time with no cooperation from us: SPIFFE says which workload it is inside your trust domain, the hostname is how anything outside that trust domain reaches it. Nothing to configure here, and no conflict between the two.

Agent Name Service

ANS is a naming and discovery layer for agents, currently an OWASP specification with a v2 draft at the IETF. It resolves an agent name to an endpoint, and a minted hostname is an endpoint it can name today. Registering with ANS is between you and the registry; we are what the registration points at.

The v2 draft moves further toward DNS, anchoring agent names to a domain and expecting records published under it - TLSA among them. Those are the record types we serve, and the records API publishes them under any hostname you hold: TXT today, TLSA once the zone is signed. We follow the draft and ship against it as it lands.