Security

A key carries an explicit list of what it may do: hostnames:read, hostnames:write, and dns01:write. A key that only publishes certificate challenges cannot repoint or release a hostname, so the credential on your web server is not the credential that can move your fleet.

Each of those reaches exactly what you say: the whole team, one domain and everything minted under it, or a single hostname. Give a machine a key that reaches only its own name, and a compromise of that machine reaches only that name.

There is no state where an absent field means everything. A key that may act on the whole team says so explicitly, so a key can never come to hold more than it was given by omission.

It is displayed at creation and never again, and it is not recoverable afterwards. If it is lost, the key is revoked and replaced rather than retrieved.

A revoked key stops authenticating on its next request. There is no propagation delay and no cached window to wait out.

Set an expiry when you create a key and it stops working on its own, which is what you want for anything minted for a machine that will not outlive it. An expired key says so and names the date, so it is never mistaken for a broken one. Keys created without a lifetime do not expire, because a credential on something long-running should not have an outage scheduled into it. If a key that is actually in use is approaching its expiry, we email you before it lapses rather than letting you find out from a failure.

A key can be given the ability to create and revoke keys, so a fleet rotates its own credentials on a schedule you set rather than when someone remembers. It is asked for explicitly, never handed out by default, and a key can only grant within its own reach - a key narrowed to one domain cannot mint itself a team-wide successor. It also cannot sit on the same key as DNS-01, because that is the credential that lives on exposed machines. A key that can repoint a hostname can hand out DNS-01 for that one hostname without holding it, which is how a machine gets its own renewal credential; the grant has to name a hostname, so no broad DNS-01 key can be minted through the API.

Every key shows what it is scoped to and when it was last used, so a key nothing has touched in months is visible as such. Creating and revoking a key are recorded in your account activity, with the scopes that were granted.

Minting a hostname, repointing it, releasing it - your activity log names the key that did it, not just the account. That is what makes a leaked key containable: you can see its blast radius rather than having to assume the worst and revoke everything. Actions taken by a person in the dashboard are marked as such.

You generate the key, run the ACME client, and talk to the certificate authority. We never see key material at all. This is the default.

You generate the key and send us a certificate signing request. We run the ACME client and hand back the certificate. The private key never leaves you.

We generate the key, obtain the certificate, and renew it automatically, keeping a copy for you to fetch. Stored encrypted with AES-256-GCM under a data key that exists for your account alone, itself wrapped by a key used for nothing but certificates.

Connections run directly from your users to your server, on your bandwidth. Nothing is proxied, terminated, or inspected, so there is no traffic here to read, log, or hand over.

Holding a certificate for you does not put us in the path. We keep a copy so you can fetch it; the bytes still never come near us.

A minted hostname carries no meaning and does not encode the address behind it, so it reveals nothing to a passive observer or a certificate transparency scraper. Anyone who resolves it, of course, learns the address - that is what resolution is. See the questions page.

Your hostnames sit on a domain assigned to your team alone, on every plan, so the certificate limit, cookie scope and reputation are not shared with another customer.

We register, renew, delegate and defend it. There is no registrar account for you to hold and no renewal for you to miss.

Every domain is DNSSEC-signed and its DS record published at the registry before a hostname on it goes live. Both are admission gates rather than a later step: a domain whose zone is unsigned, or whose DS is not yet live at the registry, does not enter service. The second half is the one usually skipped - a signed zone nobody can find the DS for is not protected, and a resolver has no way to tell it was meant to be.

Because signing is only automatic if we are the ones answering. Hosted DNS will sign a zone for you, but turning it on is a per-domain action, and a domain per customer makes that a step someone has to remember. Being authoritative is what lets it be a gate instead. It is also what lets us refuse a TLSA record on an unsigned zone - that record tells a client which certificate to trust, and unsigned it is a binding nobody can verify, which reads as protection and is not.

The other side of that: a dedicated domain is exclusively yours to use rather than an asset you can move to your own registrar account. When a subscription ends we release the hostnames on it and revoke their certificates, so they stop resolving then, and the domain is not renewed. Run names that must outlive the account on a domain you own. Full terms are in the terms.

Public stays public and private stays private: repointing across the boundary is refused. A name that starts on a public address and later answers with a private one lets an attacker's page speak with the authority of the visitor's own network, so that transition is not representable.

A hostname can follow a platform endpoint rather than an address you set. It does that as an ALIAS - we resolve the target and publish ordinary A and AAAA records - never a CNAME, and the difference is the whole point: a CNAME hands the address behind your name to whoever runs the target, to move across the public and private boundary whenever they like, in a zone we do not hold. We resolve the target ourselves and publish ordinary records, so the class check above runs on every refresh and a target that starts answering privately is refused with the hostname left on its last public address. That check runs against whatever the target answered, so it holds for any endpoint rather than a list of vetted ones, and it catches a target that behaves for a month and then does not.

We do not offer them, and would not recommend them here. The machines this product exists for are the ones whose addresses churn - agents on ephemeral sandboxes, devices behind NAT, workloads on private ranges. Pinning a credential to an address is precisely what breaks for them, and it is the reason DNS-01 matters in the first place. Scope the key to what it may reach instead; that constraint holds wherever the machine happens to be.

We serve no NS records pointing away from us and do not take on domains someone else is the registrant of. Being the registrant is what removes the registrar account, the renewals, and the verification step from the path between a call and a working hostname. If you need to be the accountable registrant, you need a registrar rather than us.

Our domains publish a CAA record naming the CAs we use. Publish one on your own hostname and it replaces ours for that name rather than adding to it - a CA reads the closest record set and ignores everything above, and we serve exactly what you wrote. So a record naming only your CA excludes ours there. We could quietly merge the two and spare you that, and deliberately do not: it would mean widening your policy the next time we widened ours, and an API that does not behave like DNS for the one audience that would notice. Deleting your record restores the domain policy. Details on the certificate authorities page.