Custom domains

Every web service and static site gets a free muerte.app URL, but production traffic usually lives on your own domain. This page covers adding a domain, the DNS records to publish, how TLS certificates are issued, and what to do about apex, subdomain, wildcard and proxied setups.

A custom domain is attached at the service level. Muerte Cloud verifies ownership by DNS, provisions a certificate from Let's Encrypt, and swings traffic over once both are in place. There is no charge for adding domains or certificates.

Default URL keeps working

Adding a custom domain doesn't retire the built-in <name>.muerte.app URL. Both resolve to the same service and share the same TLS pipeline — handy for health checks, webhooks and internal tooling.

Adding a domain#

1
Open the service's Settings tab
Scroll to Custom domains and click Add domain.
2
Enter the hostname
Type the exact hostname you want to serve — example.com, www.example.com or api.example.com. Add subdomains one by one; wildcards are configured separately (see below).
3
Publish the DNS records shown
Muerte Cloud shows the exact record(s) to add at your registrar. Publishing an ALIAS/ ANAME or CNAME is enough — no A records to maintain.
4
Wait for verification
Verification usually completes in under a minute once DNS propagates. The status pill on the domain moves from Pending to Verifying to Live.

DNS records#

Which record you publish depends on whether the hostname is an apex domain (example.com) or a subdomain (www.example.com, api.example.com).

Field	Description
Subdomain	Publish a CNAME pointing at the service's default hostname, e.g. www CNAME my-service.muerte.app. TTL 300 is a good default.
Apex / root	Most registrars don't allow CNAME at the apex. Use ALIAS or ANAME to point example.com at my-service.muerte.app. Route 53 calls this an Alias record.
Fallback A record	If your registrar supports neither ALIAS nor ANAME, publish A records pointing at the anycast IPs shown in the dashboard. Note: these are managed by us and may change; ALIAS/ANAME is preferred.

No AAAA required

Muerte Cloud handles IPv6 at the edge automatically. Don't publish your own AAAA records — a stale AAAA can bypass the edge and break TLS.

Example zone

text

; apex + www for example.com pointing at my-service.muerte.app
example.com.        300  IN  ALIAS  my-service.muerte.app.
www.example.com.    300  IN  CNAME  my-service.muerte.app.

; separate hostname for the API on the same or another service
api.example.com.    300  IN  CNAME  api-service.muerte.app.

TLS certificates#

Certificates are issued automatically by Let's Encrypt once ownership is verified, and rotated well before expiry. There is no certificate to upload and no key to rotate.

Managed rotation

Certificates renew ~30 days before expiry with a hitless swap at the edge. No downtime, no manual step.

HTTP → HTTPS

Plain HTTP requests are permanently redirected to HTTPS. HSTS is opt-in per service.

TLS 1.2 and 1.3

Modern cipher suites only. Older TLS versions and weak ciphers are rejected at the edge.

SNI-only

Every request must present Server Name Indication. Clients from 2016 and later already do.

CAA records

If your zone has CAA records, they must allow letsencrypt.org. Missing this line is the single most common cause of a stuck Verifying state:
example.com. IN CAA 0 issue "letsencrypt.org"

Wildcards#

A single service can serve every subdomain of a zone — *.example.com — with a wildcard domain entry. Wildcards require a DNS-01 challenge, so Muerte Cloud will ask you to publish a temporary TXT record under _acme-challenge.example.com during issuance and renewal.

Wildcards cover one level of subdomain. A wildcard for *.example.com matches foo.example.com but not foo.bar.example.com — add a second wildcard for deeper nesting.

Proxied setups (Cloudflare and similar)#

Sitting Cloudflare, Fastly or another proxy in front of Muerte Cloud is supported, but it changes the TLS challenge and the client IPs your app sees.

Field	Description
TLS challenge	The proxy terminates TLS, so HTTP-01 challenges won't reach Muerte Cloud. Enable DNS-01 in the domain settings and publish the TXT record the dashboard shows.
Origin certificate	Use Full (strict) or equivalent on the proxy. Muerte Cloud always presents a valid publicly-trusted certificate on the origin.
Real client IP	Your app receives the proxy IP by default. Configure the proxy to add X-Forwarded-For and read that header at the runtime.
Caching	Static Sites can safely be cached at the proxy. For Web Services, cache HTML only when your app sets explicit Cache-Control headers.

Apex vs www redirects#

Most sites want one canonical hostname. Add both example.com and www.example.com, mark one as the primary, and Muerte Cloud will 301-redirect the other. The redirect happens at the edge before the request reaches your app, so there's no runtime cost.

Troubleshooting#

Stuck on Verifying

DNS hasn't propagated yet, or a CAA record is blocking Let's Encrypt. Check with dig +short example.com and dig CAA example.com.

Certificate reissue failed

The most common cause is a DNS change between issuance and renewal. Confirm the ALIAS/CNAME still points at the muerte.app hostname.

SSL error in browser

The client isn't sending SNI, or an intermediate proxy is terminating TLS with its own certificate. Test with curl -v https://example.com.

Wrong service serving the domain

Two services can't share the same hostname. Remove the domain from the old service, wait for the change to propagate, then add it to the new one.

Learn more about the deploy pipeline in How deploys work or configure environment variables in Environment variables.