How to host marketing sites on Cloudflare Workers without domain transfers

Let's be honest: asking clients to transfer their domain to your Cloudflare account is like asking them to hand over the keys to their house so you can redecorate the living room. Sure, it could work, but there's anxiety, compliance headaches, and about seventeen emails from their legal team explaining why they absolutely cannot do that.

I've been there. You've probably been there too. A client wants to have your blazing-fast Astro marketing site deployed on Cloudflare Workers. Still, when you mention "domain transfer," suddenly the project timeline extends by three months while procurement reviews vendor policies.

Here's the good news: Cloudflare for SaaS and Custom Hostnames let you host client marketing sites on your Workers infrastructure while their domains stay exactly where they are. Your clients add two DNS records, and boom; their site is live on your globally-distributed edge network. No transfers, no migrations, no compliance nightmares.

In this tutorial, I'll walk you through exactly how to set this up using the Cloudflare dashboard, with a real-world example: hosting the website of "BrightStar Marketing" (www.brightstarmarketing.com) on your Cloudflare Workers while their domain stays with their existing DNS provider. By the end, you'll understand how to onboard clients in minutes instead of weeks.

The problem: Why are domain transfers a nightmare

Before we dive into the solution, let's acknowledge why this problem exists in the first place.

Scenario: You've built a gorgeous Astro marketing site for BrightStar Marketing. It's optimized, edge-rendered, and faster than anything they've ever seen. They want it deployed yesterday. But their domain? It's locked in their existing DNS provider (let's say GoDaddy), tangled up with MX records for email, SPF configurations, existing subdomains for their customer portal, and probably that one critical TXT record someone added in 2018 that nobody fully understands anymore.

The traditional approaches:

1. Full domain transfer to Cloudflare – Requires changing nameservers, migrating all DNS records, getting buy-in from multiple teams, and hoping nothing breaks.

2. Proxy through their existing setup – Loss of Cloudflare's edge features, caching benefits, and performance optimizations.

3. Subdomain compromise – "What if we just host it at new.brightstarmarketing.com?" which defeats the entire purpose.

Compliance complications get even messier. Some enterprise clients have policies preventing code execution in accounts they own. BrightStar Marketing might have regulatory requirements about where infrastructure lives. Government contractors? Forget about it, too many forms to fill.

What we need is a way for BrightStar Marketing to point their domain to your Cloudflare Workers infrastructure while keeping everything else exactly where it is.

Understanding Cloudflare for SaaS

Cloudflare for SaaS is technically designed for multi-tenant SaaS platforms; think Shopify or Webflow, where thousands of customers use custom domains. But here's the secret: it works perfectly for agencies and development shops hosting client marketing sites.

The core concept: You create "custom hostnames" in your Cloudflare zone that represent your client's domain. Cloudflare provisions SSL certificates, validates ownership, and routes traffic to your Workers, all while the domain stays in the client's DNS provider.

What makes this magical:

• Zero domain transfers – BrightStar Marketing never changes nameservers

• Automatic SSL – Cloudflare provisions and renews certificates using Let's Encrypt

• Global edge deployment – Your Astro site runs on Cloudflare's network in 300+ cities

• Client control preserved – They still manage their DNS for email, subdomains, etc.

Think of it like this: Custom Hostnames creates a secure bridge between your client's domain and your Cloudflare infrastructure, without requiring them to move into your building.

How Custom Hostnames work

When a visitor types www.brightstarmarketing.com into their browser, here's what happens:

1. DNS lookup – The browser queries DNS and finds a CNAME record pointing to cname.luckym.dev (your fallback domain)

2. Cloudflare routing – Traffic hits Cloudflare's edge network, which recognizes www.brightstarmarketing.com as a registered custom hostname

3. Certificate presentation – Cloudflare serves an SSL certificate valid for www.brightstarmarketing.com (provisioned automatically)

4. Worker execution – Your Cloudflare Worker serves the Astro marketing site

5. Response delivery – The fully rendered page returns to the visitor

Two validation steps happen before this works:

1. Certificate validation (TXT record) – Proves BrightStar Marketing owns the domain so Cloudflare can issue SSL certificates

2. Hostname validation (CNAME record) – Confirms the domain is pointing to your infrastructure

Both validations use standard DNS records, which any DNS provider supports. BrightStar Marketing doesn't need a Cloudflare account, doesn't need to understand Workers, and doesn't need to change their infrastructure.

Prerequisites

Before we dive into the setup, make sure you have:

On Cloudflare:

• A Cloudflare zone (e.g., luckym.dev) on at least a Free plan

• Cloudflare for SaaS should be enabled for your zone (you'll need to request this via the dashboard or contact Cloudflare Sales)

• A short, memorable domain for CNAME targeting (we're using cname.luckym.dev)

• Your Astro marketing site already deployed to a Cloudflare Worker

• Do not use your primary domain for this, it's safer to use another domain ( like in our example )

From your client (BrightStar Marketing):

• Access to their DNS provider dashboard

• The domain they want to use (www.brightstarmarketing.com)

That's it. Notice BrightStar Marketing doesn't need a Cloudflare account and doesn't need to understand any of the technical details. This is the beauty of the approach.

Step 1: Enabling Cloudflare for SaaS

First, you need to enable Cloudflare for SaaS on your zone. This is a free feature, but it requires manual activation.

Requesting access

Navigate to your Cloudflare dashboard:

1. Select your zone (luckym.dev)

2. Go to SSL/TLS → Custom Hostnames

3. If you haven't enabled it yet, you'll see a prompt to request access

4. Click Request Access or Enable Cloudflare for SaaS

Cloudflare typically approves this within a few minutes, though it can take up to 24 hours. You'll receive an email confirmation when it's ready. Once enabled, you'll see the Custom Hostnames interface where you can manage everything.

Why the manual approval? Cloudflare uses this to prevent abuse and ensure you understand the feature's purpose. The approval is a one-time thing; once enabled, you can create unlimited custom hostnames.

Step 2: Setting up your fallback origin

The fallback origin is your "home base", where Cloudflare routes traffic for all custom hostnames by default. This is the DNS record that everything ultimately points to.

Create the fallback DNS record

In your Cloudflare dashboard for luckym.dev:

1. Go to DNS → Records

2. Click Add record

3. Configure the record:

   • Type: A

   • Name: proxy-fallback

   • IPv4 address: 192.0.2.1 (this is a dummy IP, you can use any IP here)

   • Proxy status: Proxied (orange cloud)

   • TTL: Auto

4. Click Save

Why a dummy IP? Because your Worker becomes the actual origin. The IP address just needs to exist for the DNS record to validate, Cloudflare never actually routes to it. The traffic goes to your Worker instead.

Designate as Fallback origin

Now tell Cloudflare this is your fallback origin:

1. Still in SSL/TLS → Custom Hostnames

2. Find the Fallback Origin section (usually at the top)

3. Enter proxy-fallback.luckym.dev in the input field

4. Click Add Fallback Origin

Cloudflare will validate the record and mark it as Active. This confirms your infrastructure is ready to receive custom hostname traffic.

Step 3: Creating your CNAME target

The CNAME target is the friendly address your clients will point their domains to. Instead of giving them the technical proxy-fallback.luckym.dev, we'll create cname.luckym.dev.

Set up the CNAME record

Back in DNS → Records:

1. Click Add record

2. Configure:

   • Type: CNAME

   • Name: cname

   • Target: proxy-fallback.luckym.dev

   • Proxy status: Proxied (orange cloud)

   • TTL: Auto

3. Click Save

Now cname.luckym.dev points to your fallback origin. This is the single, clean hostname you'll give every client for their CNAME records.

Pro tip: Why separate the CNAME target from the fallback origin? Flexibility. If you later change infrastructure, add load balancing, or restructure your setup, you only update one record instead of asking every client to update theirs.

Step 4: Deploying your Astro site to Cloudflare Workers

Before we can add the custom hostname, make sure your Astro marketing site is deployed to a Cloudflare Worker. I'm assuming you've already done this, but here's a quick verification checklist:

Verify your deployment:

1. Go to Workers & Pages in your Cloudflare dashboard

2. Confirm your Astro site Worker is listed and shows as Deployed

3. Test the *.workers.dev URL to ensure the site loads correctly

4. Check that your Worker is configured to handle incoming requests properly

Your Astro site should be configured with the Cloudflare adapter and deployed using Wrangler or the dashboard deployment method. The Worker should respond to all incoming requests, it doesn't need route-specific configuration since the custom hostname will handle routing.

Step 5: Creating the Custom Hostname

Now comes the magic; registering BrightStar Marketing's domain as a custom hostname in your Cloudflare zone.

Add the Custom Hostname

Navigate to SSL/TLS → Custom Hostnames:

1. Click Add Custom Hostname

2. Enter the hostname: www.brightstarmarketing.com

3. Configure SSL settings:

   • Certificate Authority: Let's Encrypt (recommended)

   • Certificate Validation Method: TXT (recommended for pre-deployment)

   • Enable Wildcard: Optional, turn this on if you want to cover both www.brightstarmarketing.com and brightstarmarketing.com with one certificate

4. Click Add Custom Hostname

Cloudflare immediately creates the custom hostname entry with a status of Pending Validation. This is expected, we need BrightStar Marketing to add DNS records before it can activate.

Understanding the Validation Records

After creating the custom hostname, click on it to view details. You'll see two critical pieces of information:

1. TXT Validation Record (for certificate)

• Record name: Something like _acme-challenge.www.brightstarmarketing.com

• Record value: A long string like ca3-f98a7d2e8b1c4a5f6789...

2. CNAME Target

• Record name: www.brightstarmarketing.com

• Record value: cname.luckym.dev

These are what BrightStar Marketing needs to add to their DNS provider. Keep this page open, you'll send these values to your client.

Step 6: Client DNS configuration

This is where your client does their part. The good news? It's remarkably simple, just copy the two DNS records and send them over to your client.

Common DNS provider variations

Different DNS providers display fields slightly differently:

• GoDaddy: Enter _acme-challenge.www and www as the Name (they auto-append .brightstarmarketing.com)

• Cloudflare DNS (if client uses it): Enter the full hostname including domain: _acme-challenge.www.brightstarmarketing.com

• AWS Route 53: Use the full FQDN with trailing dot: _acme-challenge.www.brightstarmarketing.com.

• Namecheap: Enter the subdomain part only in the Host field: _acme-challenge.www

Providing DNS provider-specific screenshots dramatically reduces confusion and support requests.

Step 7: Monitoring validation and activation

After BrightStar Marketing adds the DNS records, you'll monitor the activation process in the Cloudflare dashboard.

Checking Validation Status

In SSL/TLS → Custom Hostnames, find www.brightstarmarketing.com and watch the status indicators:

Certificate Status will progress through:

1. Pending Validation – Waiting for TXT record detection

2. Pending Issuance – TXT record found, requesting certificate from Let's Encrypt

3. Active – Certificate issued and deployed ✓

Hostname Status will show:

1. Pending – Waiting for CNAME record

2. Active – CNAME verified and routing configured ✓

Both must reach Active before the site is live.

Typical Timeline

• TXT record propagation: 5-30 minutes

• Certificate validation: 1-5 minutes after TXT detection

• Certificate issuance: 1-10 minutes

• CNAME propagation: 5-30 minutes

• Total activation time: Typically 15-45 minutes

Pro tip: DNS propagation varies by provider. GoDaddy tends to be slower (30+ minutes), while Cloudflare DNS is near-instant (1-2 minutes). Set client expectations accordingly.

Verifying the TXT Record

If validation seems stuck, verify the TXT record is correctly configured. You can use online DNS lookup tools or ask the client to check their DNS provider's dashboard.

Look for the TXT record at _acme-challenge.www.brightstarmarketing.com it should return the validation token value you provided. If it doesn't appear after 30 minutes, the record is likely misconfigured.

Step 8: Testing the live site

Once both statuses show Active, test the site thoroughly before notifying the client.

Common post-activation issues

Mixed content warnings: Your Astro site might reference http:// resources. Update all asset references to relative URLs or https://.

Redirect loops: If BrightStar Marketing has existing redirect rules pointing www to the apex domain (or vice versa), you might need to coordinate removing them.

Cache issues: First loads might be slow while Cloudflare populates the cache. Subsequent requests should be lightning-fast.

Handling the Apex Domain (Non-WWW)

You'll notice we set up www.brightstarmarketing.com but not the apex domain (brightstarmarketing.com). Let's address both options.

Option 1: Redirect Apex to WWW (Recommended)

The cleanest approach is having BrightStar Marketing set up a redirect from apex to www:

In their DNS provider:

1. Add an A record for brightstarmarketing.com pointing to a redirect service (their DNS provider usually offers this)

2. Configure a 301 redirect from brightstarmarketing.com to https://www.brightstarmarketing.com

This keeps everything clean, one canonical URL, one custom hostname, simple maintenance.

Option 2: Custom Hostname on Apex Domain

If BrightStar Marketing insists on the apex domain being the primary URL, you can create a custom hostname for it, but there's a catch.

The DNS limitation: Traditional DNS specs don't allow CNAME records on apex domains (because CNAME can't coexist with other records like MX, TXT, etc.).

Solutions:

• CNAME Flattening: If their DNS provider supports this (Cloudflare DNS, AWS Route 53 ALIAS, Azure DNS Alias), they can add a CNAME-like record on the apex

• Switch DNS providers: If they're stuck on an older provider, migrating to Cloudflare DNS (without transferring the domain) enables CNAME flattening

Option 3: Cover both with Wildcard

When creating the custom hostname, enable the Wildcard option. This adds both www.brightstarmarketing.com and brightstarmarketing.com as Subject Alternative Names (SANs) on the certificate.

Then BrightStar Marketing adds:

• CNAME for www.brightstarmarketing.com → cname.luckym.dev

• CNAME for brightstarmarketing.com → cname.luckym.dev (requires CNAME flattening support)

Both domains point to your Worker, covered by one certificate.

Common pitfalls and how to avoid them

Let me save you some debugging time by sharing mistakes I've encountered (and how to prevent them).

Pitfall 1: Client adds A Record instead of CNAME

Problem: BrightStar Marketing thinks they need to point to an IP address and adds an A record instead of a CNAME.

Symptoms: Hostname status stays Pending, site doesn't load, DNS queries resolve to the wrong IP.

Solution: Clearly specify "CNAME record" in instructions and explain why it's different from an A record. Provide a screenshot showing the CNAME section of their DNS dashboard.

Pitfall 2: TXT Record timeout

Problem: Certificate validation sits at Pending Validation for hours.

Common causes:

• TXT record added to wrong subdomain (_acme-challenge.brightstarmarketing.com instead of _acme-challenge.www.brightstarmarketing.com)

• DNS provider hasn't published the record yet

• CAA records blocking Let's Encrypt

• DNSSEC validation issues

Solution: Use a DNS lookup tool to verify the exact TXT record name and value. If CAA records exist, ensure they include 0 issue "letsencrypt.org".

Pitfall 3: Existing CNAME conflicts

Problem: BrightStar Marketing already has a CNAME for www pointing to their old hosting provider.

Symptoms: DNS provider throws an error when trying to add your CNAME, or the site loads their old content.

Solution: They must delete or update the existing CNAME record. DNS providers don't allow multiple CNAME records for the same hostname. This is often the point where you discover they have existing infrastructure you weren't aware of.

Pitfall 4: Forgetting to deploy your Worker

Problem: Custom hostname activates successfully, but visitors get 522 errors or "Worker not found."

Symptoms: Certificate shows valid, CNAME resolves correctly, but no content loads.

Solution: Verify your Astro Worker is actually deployed and active. Check the Workers & Pages dashboard to confirm the deployment status. This seems obvious but happens more often than you'd think during busy deployments.

Pitfall 5: Hard-coded domain in Astro site

Problem: The client's site loads but all links point back to your development domain or the .workers.dev URL.

Symptoms: Clicking links navigates users away from www.brightstarmarketing.com.

Solution: Ensure your Astro site uses relative URLs or dynamically detects the hostname. Configure the site properly in astro.config.mjs to work with any domain.

Real-world applications and scaling

Once you've successfully deployed BrightStar Marketing's site, here are ways to extend this approach.

Multiple client sites

The same infrastructure scales to dozens or hundreds of clients:

1. Create a custom hostname for each client domain

2. Use Workers routing or environment variables to serve different Astro builds

3. Monitor all custom hostnames from a central dashboard

4. Automate DNS instruction generation

The foundational setup (fallback origin, CNAME target) remains identical, you just add custom hostnames as clients onboard.

Staging Environments

For client approvals before production, create custom hostnames on staging subdomains:

Example:

• Production: www.brightstarmarketing.com

• Staging: staging.brightstarmarketing.com

Deploy your staging Worker to a different Worker script, create a staging custom hostname, and BrightStar Marketing adds DNS records only for the staging subdomain. After approval, create the production custom hostname.

Geographic-specific deployments

Cloudflare's edge network is global, but you might serve region-specific content:

• Create custom hostnames for regional domains (www.brightstarmarketing.co.uk, www.brightstarmarketing.fr)

• Use Cloudflare's geolocation data in your Worker to serve localized content

• Deploy the same Astro site with different translations or regional configurations

All managed through custom hostnames without separate infrastructure per region.

White-label agency offerings

If you're an agency, this approach enables true white-label hosting:

• Clients never see your Cloudflare account or Workers infrastructure

• You control updates, deployments, and configurations

• Clients maintain full DNS control for email and other services

• Clean separation between your infrastructure and client domains

This professional setup impresses enterprise clients and simplifies compliance.

When NOT to use Custom Hostnames

While Custom Hostnames solve many problems, they're not always the right choice.

Don't use Custom Hostnames if:

1. Client has complex DNS requirements – If they need advanced DNS features (DNSSEC with specific configurations, unusual record types, etc.) that conflict with CNAME flattening, regular Cloudflare routing might be simpler.

2. Full Cloudflare feature access needed – Custom Hostnames don't expose all Cloudflare features to the client. If they need direct access to WAF rules, Page Rules, or analytics dashboards for their domain, transferring to Cloudflare might be necessary.

3. Very high traffic volume – While Cloudflare handles traffic brilliantly, if BrightStar Marketing expects millions of daily requests, review Cloudflare's pricing for SaaS to ensure cost efficiency.

4. Client wants full infrastructure control – Some technical clients prefer owning the entire stack. In these cases, guide them through setting up their own Cloudflare account and Workers deployment.

5. Temporary projects – For proof-of-concept or short-term deployments, a simple .workers.dev subdomain or temporary custom domain might be more pragmatic.

Know your use case and recommend the right solution, even if that means not using Custom Hostnames.

Conclusion

Hosting an Astro marketing site on your Cloudflare Workers using Custom Hostnames gives you the best of all worlds: they keep full control of their domain and DNS, you deliver cutting-edge performance and global edge deployment, and the onboarding process takes minutes instead of months.

This approach scales beautifully. The infrastructure we set up for BrightStar Marketing today works identically for client number fifty tomorrow. You're just adding custom hostnames and sending DNS instructions.

The compliance questions disappear, the legal reviews speed up, and clients feel confident because they maintain control of their primary asset; their domain. Meanwhile, you deliver a fast, globally-distributed marketing site that makes them look incredible.

Start with one client, get comfortable with the validation flow and DNS coordination, then systematize the onboarding process. Before long, you'll wonder why you ever considered asking clients to transfer domains in the first place.

Ready to build your site?

Get in touch and we can walk through the decision together. See our Astro development service or our Next.js development service.

Lucky Media is proud to be recognized as a leading software development agency for both Astro and Next.js.

FAQs