You have a running EmDash instance on Cloudflare Workers. Now you need your own domain on it, with SSL. The official docs cover the happy path. This guide covers the three places where most setups break silently.<\/p>\n
DNS is the first. You point your domain’s CNAME to the Workers subdomain. That part is standard. The non-obvious<\/a> part is that EmDash’s asset pipeline (R2, images, CSS bundles) generates URLs that may or may not respect your custom domain, depending on how you configure the Set Cloudflare provides automatic SSL certificates for custom domains on the Free plan. That works fine for the front end. But EmDash’s backend (the admin panel at The trap: if you enable Full (strict)<\/strong> SSL mode in Cloudflare’s SSL\/TLS settings, and your origin server (the EmDash worker) is not configured to serve a valid certificate for your custom domain, Cloudflare will reject the connection. Workers do not serve origin certificates by default. You must set SSL\/TLS to Full<\/strong> (not strict) or Flexible<\/strong> when using Cloudflare’s edge certificates. The strict mode expects a certificate on the origin, and Workers is not an origin server in the traditional sense.<\/p>\n Set SSL\/TLS encryption mode to Full<\/strong> (not strict). This encrypts traffic between Cloudflare and the Worker using Cloudflare’s internal certificates. Your visitors still get a valid edge certificate for your domain.<\/p>\n Adding a custom domain to your EmDash worker is not a simple CNAME record. You must add the domain as a Route<\/strong> in the Cloudflare dashboard under Workers & Pages > your worker > Triggers > Custom Domains. This creates the necessary DNS record and SSL certificate automatically. Do not manually create a CNAME record for the worker subdomain \u2014 Cloudflare’s route system handles that. A manual CNAME can conflict and cause intermittent 522 errors.<\/p>\n After adding the custom domain, wait for the certificate to provision. This usually takes 30 seconds to 2 minutes. During that window, the domain returns a 525 SSL handshake failure. Most people panic and start changing DNS TTLs, which only delays the provisioning.<\/p>\n One more detail: EmDash’s playground instances (temporary demo sites) do not support custom domains at all. They are locked to the Based on reports from the Cloudflare community forum, a basic DDoS attack against a Workers-based site can generate 10,000 API calls per second<\/a>. At standard Workers billing rates (30 cents per million requests after the first 10 million), that racks up over $13,000 in a month. EmDash multiplies this because every page view hits Workers (compute), D1 (database reads), R2 (storage operations), and potentially KV (session lookups). Each of these has its own billing meter.<\/p>\n Two mitigations exist, and neither is obvious:<\/p>\n The only real protection is a usage notification<\/strong> in Cloudflare’s billing settings \u2014 there is no hard spend cap. Set a notification at 80% of your budget. You will get an email, but the charges keep accruing until you manually disable the worker.<\/p>\n After the domain resolves and the SSL certificate appears valid, test three things that are not part of the standard checklist:<\/p>\n EmDash’s architecture is designed to run at the edge, but the edge comes with edge cases. The three traps \u2014 environment variable, SSL mode, and route binding \u2014 account for roughly 80% of failed custom domain setups in the first 24 hours, based on reported issues in the EmDash GitHub repository<\/a>. Fix those, and your instance will survive production traffic.<\/p>\nPUBLIC_SITE_URL<\/code>codecodecodecode environment variable. If you forget to set it, the site loads over your domain but all internal links (media, fonts, SEO canonical tags) point back to the default Workers.dev URL. That kills your SEO from day one.<\/p>\nPUBLIC_SITE_URL<\/code>codecodecodecode to https:\/\/yourdomain.com<\/code>codecodecodecode in the Cloudflare dashboard under Workers & Pages > your EmDash worker > Environment Variables. Then redeploy. The build process reads this variable at runtime for all absolute URL generation.<\/p>\nSSL\/TLS: The Edge Certificates Trap<\/h2>\n
\/admin<\/code>codecodecodecode) runs on the same worker. The admin panel communicates with the database (D1) and storage (R2) through Cloudflare’s internal network. The SSL for that internal traffic is handled by Cloudflare’s infrastructure, not by your domain certificate.<\/p>\nCustom Domain on Workers: The Route Binding Nuance<\/h2>\n
emdashcms.com<\/code>codecodecodecode subdomain. If you deployed via the playground, you must redeploy from a real Cloudflare account using the npm create emdash-latest<\/code>codecodecodecode command with the Cloudflare Workers deploy option. The playground is for evaluation, not production.<\/p>\nAvoiding the $13,000 Billing Surprise<\/h2>\n
\n
wrangler.toml<\/code>codecodecodecode under [limits]<\/code>codecodecodecode. This prevents runaway plugins from burning compute, but does not cap total requests.<\/li>\nVerifying the Setup: What Most People Miss<\/h2>\n
\n
https:\/\/yourdomain.com\/admin<\/code>codecodecodecode. If the passkey authentication fails with a “domain mismatch” error, your PUBLIC_SITE_URL<\/code>codecodecodecode is wrong or missing. The WebAuthn passkey is bound to the origin URL. Changing the domain after initial setup requires re-registering all passkeys.<\/li>\n<\/ol>\n\n
<\/code>codecodecodecode. If it points to the Workers.dev URL, the environment variable is not being read at build time. Delete the worker’s build cache and redeploy.<\/li>\n<\/ol>\n\n
https:\/\/yourdomain.com\/assets\/...<\/code>codecodecodecode. If it starts with https:\/\/pub-.r2.dev<\/code>codecodecodecode, the R2 bucket is not configured with a custom domain. Set a custom domain on the R2 bucket in Cloudflare dashboard (R2 > your bucket > Settings > Public URL). This does not require SSL configuration separately \u2014 Cloudflare serves R2 over HTTPS automatically.<\/li>\n<\/ol>\n