Move, migrate, or remove a domain

Migrate a live domain to Easel

A cutover changes where public DNS sends visitors. Prepare Easel and a rollback path first, then change one record.

Before the cutover

Validate the deployment first with the cutover checklist. Then:

• Test the deployment through its deployment URL. If the app needs the real hostname, use a local hosts-file override rather than moving public DNS early.
• Add the custom domain to the project. Leave the old record in place; Easel can't verify the domain until DNS points at it.
• Record every existing DNS entry: A, AAAA, CNAME, MX, TXT, CAA, SRV, and email-authentication records such as SPF, DKIM, and DMARC.
• Lower the TTL of the record you'll change, then wait for the old TTL to expire.

Change DNS

Replace only the web-routing record with the one the dashboard shows: an A record to the edge IP for an apex, or a CNAME to cname.easelusercontent.com for a subdomain. See Configure DNS.

• Don't touch MX, SPF, DKIM, DMARC, or other services' TXT records.
• Keep any proxy, such as Cloudflare, DNS-only until the domain is Live.
• Expect HTTPS requests to fail briefly until Easel issues the certificate.

Changing nameservers moves every record at once. Prefer changing one record unless moving DNS hosting is the goal.

Verify and monitor

From more than one network, confirm DNS reaches Easel, the certificate is valid, the right project and deployment respond, canonical redirects work, and sign-in, APIs, and email still work:

dig example.com A
dig www.example.com CNAME
curl -I https://example.com

Then watch Observability for error rate, latency, and function failures. Clients keep cached DNS answers for a while, so keep the old platform and its credentials until traffic has moved. Raise the TTL once things are stable.

Roll back the cutover

1. Restore the previous routing record.
2. Keep the domain on Easel while caches expire; clients that cached the new answer keep reaching Easel until then.
3. Confirm traffic returns to the previous host.
4. Fix the issue before trying again.

To roll back to an earlier deployment on Easel instead, see Promote and roll back.

Move a domain between projects

There's no atomic transfer, including between workspaces. Remove the domain, then add it again:

1. Prepare the destination project and its Production deployment.
2. Remove the hostname from the source project.
3. Add it to the destination project. For another workspace, you need access to both.
4. Leave DNS alone if it already points at Easel; verification runs again on the destination.
5. Confirm the destination responds, then update redirects and app settings.

Between steps 2 and 3, requests that reach Easel get a not-found response, never another customer's site.

Remove a domain

Removing a domain detaches it from the project. It doesn't cancel the registration, change records at an external DNS provider, or delete deployments. With Easel DNS, Easel also removes the hostname's managed A and AAAA records.

Before you remove a domain that's in use, check whether it's used for API requests, authentication callbacks, webhooks, email links, mobile deep links, cookies, or customer integrations.

1. Open Project settings → Domains.
2. Select the remove (trash) button on the domain's row.
3. Select Remove to confirm.

The domain stops serving the project within a few seconds. Update any redirect domains that pointed at it, then remove the DNS record when you no longer need it. Until then, Easel answers requests for it with not found.

Wildcard domains

Wildcard custom domains such as *.example.com aren't supported, and neither are wildcard certificates for them. Add each hostname you need as its own domain, such as alice.example.com and store.example.com.

If your app serves many per-customer subdomains, add each one, or put your own reverse proxy in front of Easel for those hostnames. When your code reads the Host header, map it to a known customer rather than trusting any subdomain.