Custom Domains

---

Serve your project from a domain you own, with HTTPS provisioned for you.

Two Ways to Add a Domain

Both live in the same list under your organization’s Settings → Custom domains, and both end with a hostname serving your project over HTTPS. You add either one through the same box: pick CNAME records or Nameservers next to the hostname, and a Cloud alongside it if you choose nameservers. They differ in how much of the domain you hand over.

Pointing one hostname is the usual choice. You add two records once, neither value ever changes, and the rest of your DNS is left alone, so email and any other site on the domain keep working. It is also the only route available on the shared cloud, where there is no account to hold a zone.

Delegating is the heavier option, and some things only work that way: wildcard certificates, new hostnames going live without another trip to your DNS provider, and root domains on a provider that cannot flatten a CNAME at the zone root. Reach for it when you need one of those, or when you expect enough hostnames on the domain that having Spawned manage every record is less work than adding records yourself.

Sections 1 to 4 below cover pointing one hostname. Delegate a Whole Domain covers the other route.

---

Before You Begin

Custom domains are added at the organization level. You will need:

• A domain you control, or a subdomain of one, where you can edit records at your registrar.
• A connected Cloud, for delegation only. A delegated domain is provisioned inside one Cloud, and only projects in that Cloud can use it. Pointing a single hostname needs no Cloud.

---

1. Add the Hostname

Open your organization’s Settings → Custom domains, enter the hostname you want to serve under Domain, for example app.example.com, leave Type on CNAME records, and press Add domain. Spawned immediately shows you both records to create.

The Cloud picker stays greyed out on this route. The hostname is owned by the organization, and whichever project ends up serving it gets a certificate in its own Cloud.

Root domains such as example.com work here too, on providers that support a CNAME at the root. See Root Domains for which do.

---

2. Add Both Records

Click the row, or View DNS configuration on it, to expand the two records, then create both at your DNS provider. The first serves visitors. The second hands certificate validation to Spawned, so the HTTPS certificate is issued now and renewed on its own for as long as the record stays in place.

Verification waits for both, so add them in one go. Turn off any proxy option your provider offers, so the names resolve directly. Neither value ever changes afterwards, so once both are in place you can leave them alone for good.

---

3. Wait for Verification

The row starts at Waiting for DNS records and moves to Verified once both records resolve. Each record carries its own status dot in the expanded DNS configuration: amber while Spawned still cannot see it, green once it resolves. That tells you which of the two is holding things up.

Spawned rechecks every 20 seconds while the page is open, and Check runs one immediately. DNS changes usually take a minute or two to become visible, and occasionally longer depending on your provider.

A record that stays amber for more than a few minutes usually has one of these causes:

• Your provider appended your own domain to the value. Enter the value with a trailing dot, or as the full name.
• Your provider refuses records starting with an underscore, which blocks _acme-challenge.
• Another service already owns _acme-challenge for this hostname. Only one can.

Once the domain reads Verified, a padlock line appears under it reading Issuing certificate…, and turns into HTTPS ready on its own once the certificate lands.

---

4. Serve It From a Project

The hostname has to reach Verified before this step. A project can only serve a hostname the organization has proved it owns, so applying a project that names an unverified one fails with a message saying so, rather than deploying something that cannot answer. Once verified, the hostname is available to every project in the organization, including projects on the shared cloud.

1. Open the project and select the connection between its domain and whatever answers requests, a load balancer or a function.
2. Add the hostname to aliases. Type it, or open the picker on the row to choose from the hostnames already verified for the organization.
3. Apply. The hostname starts serving alongside the project’s existing address rather than replacing it.

This is the whole flow: verify once in organization settings, then name the hostname on a connection in any project that should answer for it. Nothing about the DNS records changes when you move it between projects.

A CDN connection cannot take extra hostnames. A distribution serves one certificate that has to cover every name on it, so route extra hostnames through a load balancer or a function instead.

---

Delegate a Whole Domain

This route hands Spawned the entire zone. Spawned answers DNS for every name under the delegated one, so later hostnames need no further DNS work, root domains are supported, and the certificate issued is a wildcard covering the whole zone. In exchange, the domain lives inside one connected Cloud and only projects in that Cloud can use it.

1. Add the Domain

Open Settings → Custom domains, enter the domain under Domain, and switch Type to Nameservers. The Cloud picker next to it becomes selectable, because a delegated zone is provisioned inside one Cloud. Choose which Cloud it should live in and press Add domain.

Either a root domain or a subdomain can be delegated. Delegating a subdomain such as app.example.com hands Spawned only that part and leaves the rest of your DNS untouched.

Spawned will then set everything up for you on your selected Cloud, and present you with 4 nameservers.

2. Delegate with Nameservers

Prove you own the domain by pointing it at Spawned’s nameservers at your registrar. This is the only DNS change you need to make. Once delegation is live, Spawned manages the records inside the zone for you.

• Root domain: replace your domain’s nameservers with the four shown in Settings.
• Subdomain: add four NS records for the subdomain (for example app), one for each nameserver.

If your registrar offers a proxy option, turn it off so the records resolve directly. Nameserver changes usually propagate within 5-30 minutes, but can take up to 24 hours.

3. Verification and Certificates

Spawned checks the delegation and issues TLS certificates on its own. The status advances through these states:

4. Attach the Domain to a Project

A verified domain is added to the project from the project itself, either through the infrastructure canvas or your favorite agent.

1. Open the project and add an External/Imported Domain to the canvas.
2. Select your verified domain. Only domains verified on the same Cloud as the project are available.
3. Set the hostname you want to serve, for example app.example.com or www.example.com.
4. Connect the Imported Domain to the component that should receive traffic: a load balancer in front of your containers, a CDN, or a function.
5. Apply the change. Spawned adds the records for that hostname inside your zone and attaches the certificate. The domain goes live once the deployment finishes.

---

Root Domains

A root domain, example.com rather than app.example.com, cannot hold a CNAME. Every zone root already carries the records that define the zone, and DNS does not allow a CNAME to sit alongside anything else. This is a rule of the protocol, not a limit of any provider.

Providers work around it with a record that behaves like a CNAME but publishes addresses: CNAME flattening at Cloudflare, or ALIAS / ANAME elsewhere. Point it at the same traffic target shown in Settings and everything else works the same. The certificate is unaffected: _acme-challenge.example.com sits below the root, so it takes an ordinary CNAME.

Root domains work at Cloudflare, Namecheap, Porkbun, DNSimple, Gandi, Dynadot, Squarespace, ClouDNS, Constellix, DNS Made Easy, NS1 and Google Cloud DNS.

Two providers look like they should and do not. AWS Route 53 and Azure DNS both have ALIAS records, but only for their own resources, so neither can point one at an outside name. Use Delegate a Whole Domain instead, which gives you root domains and wildcards.

Providers with no such record at all include GoDaddy, IONOS, OVH, Hover, Network Solutions, Hetzner, DigitalOcean and Linode. Two options there: delegate the domain, or use a subdomain such as www.example.com and turn on your provider’s URL forwarding at the root so visitors are redirected to it.

Two things to know if you use one:

• Turn any proxy off. A proxied root record resolves to your provider rather than to your app, and verification will say so.
• Some providers disable DNSSEC on a zone using ALIAS. Check before turning it on if you rely on it.

---

Configure DNS at Your Registrar

The record and nameserver changes above are made wherever your domain’s DNS is managed. Find your provider for step-by-step instructions.

• Cloudflare • GoDaddy • Namecheap • AWS Route53 • Squarespace • Porkbun • Hover

---

Troubleshooting

• Stuck on “Waiting for DNS records”: expand the row with View DNS configuration and look at the status dots. The amber one is the record Spawned still cannot resolve. Check its value against what your provider saved, confirm any proxy is turned off, and verify propagation with a tool like dnschecker.org.
• Value has your domain appended: your provider treats the value as relative. Enter it with a trailing dot, or as the full name.
• _acme-challenge already taken: another service that issues certificates for the same hostname may already own that record. Only one can, so remove the old one or use a different hostname.
• Stuck on “Waiting for nameservers”: the delegation has not propagated or points to the wrong values. Recheck your records against Settings, confirm any proxy is turned off, and verify propagation with a tool like dnschecker.org.
• Certificate not issuing: if your domain has a CAA record, make sure it allows Amazon to issue certificates.
• Changing a domain: editing a connected domain takes a few minutes to take effect. The previous address keeps working until the change completes.
• Removing a hostname: deleting it in Settings takes effect straight away, and a project still serving it stops answering on that name. Remove it from the project’s connection first, then delete both records at your DNS provider.