Entries land here when a change asks something of you. A change you inherit and never notice does not, so this is shorter than the commit log — the repository has that.

Getting updates is how you pull a release into your project.

Breaking changes

Production sends mail from app. and site.

Affects you only if your project already serves production. Every other runtime context is unchanged.

Production's sending domain follows the production hostname now instead of the resource-naming rule:

staging, development, preview, local and test keep the shape they had. Sending domains has the full table.

What breaks, and how you find out. Nothing fails at build or deploy. A sending domain resolves whether or not anyone onboarded it, so your next production deploy goes green and every message it sends is rejected at the recipient — email verification, password reset and Polar receipts with it.

The fix, before you deploy production again. Onboard the two new hostnames, then read them back rather than assembling them:

cd apps/web && APP_RUNTIME_CONTEXT=production pnpm exec varlock load --filter NUXT_EMAIL_SENDER_DOMAIN

pnpm exec wrangler email sending enable app.<your domain>
pnpm exec wrangler email sending dns get app.<your domain>

Repeat for apps/site and site.<your domain>. Confirm with wrangler email sending list. Leave the old two onboarded until the new deploy is live and sending, then remove them.

app.<domain> is also apps/web's Worker route, and that is not a collision: a Custom Domain is a proxied address record, and the SPF and DKIM records sit at the same name beside it.

To keep the old hostnames instead, replace the production arm of NUXT_EMAIL_SENDER_DOMAIN in each application's .env.schema with the expression its other arm uses.