Production setup needs a fixed siteUrl, which then pins passkeys and sitemaps to one host

[PavloGrubyi]

We host EmDash sites on Cloudflare Workers. Each site starts on a service subdomain, and the owner can later connect their own domain.

Since the trusted-setup-origin change (1.0.x), production setup fails with SITE_URL_REQUIRED unless siteUrl or EMDASH_SITE_URL is set. We understand the reason: the first unauthenticated setup request must not choose the origin used in auth emails.

The side effect is that the same value then drives passkey rpId, sitemaps, robots.txt and canonical URLs at runtime. A site that moves to a new domain must redeploy with a new value, and until then passkey registration on the new domain fails. A site served on two hosts can hold passkeys on only one of them.

Our workaround: set EMDASH_SITE_URL only for the setup request, then remove it and redeploy. Setup has already stored emdash:site_url for emails, and every other path uses the request origin.

1. Is removing the variable after setup safe and supported?
2. Could setup take its trusted origin separately from the runtime siteUrl, for example from a setup-only variable or a setup token, so the runtime can follow the request host?

[keybits]

Does the 'Change Domain' feature introduced in 1.20 solve this for you?

[PavloGrubyi]

Thanks, @keybits. We tested EmDash 1.2.0 on our Cloudflare QA site, with no configured siteUrl or EMDASH_SITE_URL.

This does address much of the domain-move case. Using the dialog's "Use … anyway" option changed sitemap.xml and robots.txt to the new host without a redeploy. "Continue on …" carried the admin session to the new host without email. We then registered a passkey there and confirmed sign-in in a fresh browser session, using Chromium's virtual WebAuthn authenticator.

We could not confirm the checked path: "Check and switch" returned 422, "does not serve this site yet", even with a direct Worker Custom Domain serving the same EmDash admin. Our cabinet's separate custom-hostname connection also did not complete its readiness check in this run. We have no email provider on this QA site, so outbound email behavior remains untested.

The remaining setup question is whether setting EMDASH_SITE_URL for production setup and removing it afterwards is safe and supported. We still use that workaround. So I would call this a partial solution for our setup, with the domain check still to investigate.