TLS certificates

TLS is automatic. Every hostname managed.dev serves — your custom domains, your preview URLs, and every branch environment — gets a certificate that’s issued and renewed for you. There’s no certificate to upload, no cron job to renew it, and no window where the site falls back to plain HTTP. The first request after a domain is verified is already HTTPS.

How issuance works

When you attach and verify a custom domain, managed.dev requests a certificate for that hostname from a public ACME certificate authority, installs it on the runtime, and serves HTTPS. Renewal happens automatically well before expiry, so certificates never lapse. HTTP is redirected to HTTPS for you — see redirects — so visitors who type http:// land on the secure site.

This applies uniformly:

• Production custom domains — example.com, www.example.com, and any other hostnames you attach.
• Preview URLs — the *.preview.managed.dev address every site gets.
• Branch environments — the per-node hostnames under <env>.<node-label>.<zone>.

Wildcard certificates for environments

Branch environments are ephemeral and plentiful. If every preview environment requested its own certificate from the ACME CA, a busy team pushing dozens of branches would burn through issuance quota and rate limits fast — and pay it in slow first requests while each cert was minted.

Instead, managed.dev issues a per-node wildcard certificate that covers all environment hostnames on that node, using the DNS-01 ACME challenge. DNS-01 proves control of the domain by writing a temporary TXT record into the zone rather than serving a file over HTTP, which is the only challenge type that can validate a wildcard. One wildcard per node covers every ephemeral environment that lands there, so spinning up a new preview environment is instant — the certificate already exists.

Note

Because DNS-01 writes into the zone, wildcard certs for environments require managed.dev to control your DNS. See when to use managed.dev DNS. Production and explicitly-attached custom hostnames get certificates regardless of where your DNS lives.

What you never have to do

You don’t:

• generate a CSR or private key,
• buy, upload, or install a certificate,
• track expiry dates or run a renewal job,
• configure cipher suites, protocol versions, or OCSP stapling,
• redirect HTTP to HTTPS by hand — it’s on by default.

The runtime (FrankenPHP / Caddy) terminates TLS with sane, modern defaults, and managed.dev keeps the certificates fresh underneath it.

Tip

You can subscribe to the cert.renewed webhook event if you want a record of renewals in your own systems — see event types. It’s informational; renewal happens whether or not you’re listening.

Custom and imported certificates

Roadmap

Bringing your own certificate — uploading an externally-issued cert and key, or pinning a specific CA — is on the roadmap, not yet available. Today every certificate is issued and managed by managed.dev. If you have a compliance requirement that needs a specific issuer, get in touch and we’ll track it against your account.

For almost every site the automatic path is what you want: it’s one less secret to rotate and one less thing that can expire silently at 2am.

Next steps

Custom domainsAttach a hostname, verify ownership, and point DNS for cutover.

DNS recordsDelegate your zone so environment wildcard certs can use DNS-01.

RedirectsForward apex to www and rely on automatic HTTP to HTTPS.