Can I Use an External CDN with NTCloud Hosting?

Can I Use an External CDN with NTCloud Hosting?

Can I Use an External CDN with NTCloud Hosting?

Yes — you can absolutely use an external CDN with your NTCloud hosting, and this guide walks you through exactly how to do it (in plain English, for normal humans). Whether you want to use Cloudflare, BunnyCDN, KeyCDN, Fastly or any other provider, the process is roughly the same: get your domain working on NTCloud first, then point your nameservers to the external CDN. We’ll cover every step, every gotcha, and every “but what about…?” question you might have.

💡 Heads-up — this is all done in your registrar and CDN dashboard. Setting up an external CDN is a web-based job: you’ll be logging into your domain registrar (where you bought the domain) to update nameservers, and into the external CDN’s dashboard to import your DNS records and configure caching/SSL. You won’t be editing any files on your NTCloud server for any of this — it all happens at the DNS layer.

🚨 Important — what changes when you use an external CDN:

  • SSL becomes your CDN’s responsibility, not ours. The moment your nameservers point to an external CDN, that CDN issues and manages the SSL certificate for your domain. NTCloud no longer issues, renews or manages SSL on a domain that’s sitting behind an external CDN.
  • We don’t diagnose CDN-side issues. If something goes wrong inside Cloudflare/BunnyCDN/KeyCDN/Fastly (cache misconfiguration, page-rule conflicts, SSL mode problems, CDN error pages, WAF blocks, etc.), we can’t see inside those accounts and can’t fix them. Those are between you and the CDN’s support team.
  • NTCloud handles the origin only. The actual hosting (your site files, WordPress install, mailboxes, server-side errors, backups) stays our responsibility — but everything from the DNS layer outwards is the external CDN’s domain.

⚠️ NTCloud does not include DDoS protection. Unlike our PBN LTD hosting, NTCloud is standard money-site hosting and does not include built-in DDoS mitigation. If your site is hit by a serious DDoS attack and there’s nothing in front of it to absorb the traffic, the site can be removed from the hosting to protect the wider infrastructure. If you think your site is likely to attract attacks, putting an external CDN like Cloudflare in front isn’t optional — it’s strongly recommended. Cloudflare’s free plan includes solid DDoS mitigation and is more than enough for most use cases.

📁 Quick vocab so nothing is confusing:

  • CDN (Content Delivery Network) — a global network of servers that caches your website and serves it from a location physically close to each visitor. Speeds things up massively.
  • External CDN — a CDN you sign up to yourself (e.g. Cloudflare, BunnyCDN, KeyCDN, Fastly), separate from the CDN we use behind the scenes on our hosting.
  • Nameservers — the DNS servers that “own” your domain and decide where its traffic goes. Whoever runs your nameservers controls your DNS.
  • DNS records — the bits of data inside your nameservers that map your domain to an IP address (A records), email service (MX records), verification strings (TXT records) and so on.
  • Registrar — the company you bought your domain from (Namecheap, GoDaddy, Cloudflare Registrar, etc.). This is where you change nameservers.
  • Propagation — the time it takes for a DNS change to spread across the internet. Usually minutes; can take up to 24 hours in worst cases.
  • A record — the DNS record that points your domain to a specific IP address (where your hosting lives).
  • Origin server — the actual server your site is hosted on. With an external CDN in front, the CDN talks to the origin (us) and serves cached copies to visitors.

✅ Short Answer — Can I Use an External CDN?

Yes. Your hosting with us is fully compatible with any external CDN you’d like to use. We don’t lock you in. You can:

  • Use the CDN we already provide on your hosting (zero setup needed — it’s automatic), or
  • Point your domain’s nameservers to a third-party CDN like Cloudflare, BunnyCDN, KeyCDN or Fastly, and route all traffic through them instead.

Once your domain is set up correctly on our platform, you’re free to do either. Your hosting stays with us — only the DNS layer and edge caching moves to the external CDN.

The short version: Set your domain up with us first using our nameservers → then move the nameservers to your chosen external CDN once everything’s resolving cleanly. That’s it.


🤔 Why Use an External CDN at All?

Good question — NTCloud already includes its own built-in CDN (the Edge Caching section in your NTCloud control panel) so most sites don’t strictly need a second CDN in front. But there are some genuinely strong reasons to add one — and in one specific case (DDoS protection) using an external CDN is strongly recommended rather than optional. Here’s why people do it:

  • Existing CDN account — you already use Cloudflare or BunnyCDN for other projects and want consistency across your portfolio.
  • Advanced firewall / WAF rules — external CDNs let you write your own page rules, IP block lists, country blocking, rate limits, custom WAF policies, etc.
  • Analytics — granular per-request analytics, threat data and bandwidth reporting from the CDN dashboard.
  • DDoS mitigation (especially important on NTCloud) — NTCloud does not include DDoS protection at the hosting layer. If your site gets hit by a serious DDoS attack, it can be removed from the hosting to protect infrastructure for other customers. Putting a CDN like Cloudflare in front absorbs the attack at the network edge before it ever reaches your origin. If your site is likely to attract attacks, an external CDN is effectively a requirement.
  • Custom edge logic — workers, edge functions, A/B testing, redirects, header manipulation, image resizing at the edge.
  • Specific geographic performance — some external CDNs have more PoPs (points of presence) in regions that matter to your audience.
  • Bandwidth savings — caching aggressively at the edge can reduce origin bandwidth usage significantly.

If none of those sound relevant and your site isn’t likely to face DDoS attacks, NTCloud’s built-in Edge Caching is more than enough and you don’t need to bother with an external CDN. But if DDoS attacks are even a possibility, or any of the other reasons above apply, an external CDN in front of NTCloud is well worth setting up.


Here’s a quick comparison of the most-used external CDNs. All of them work fine with our hosting — pick whichever fits your needs and budget.

CDNFree tier?Best forSetup difficultyNotes
CloudflareYes (generous)General-purpose, beginners, free SSL & DDoS protectionEasyImports DNS automatically. Best starting point.
BunnyCDNNo (cheap PAYG)Cost-conscious sites, video, large file deliveryMediumPay-as-you-go pricing, excellent value. Good for high-traffic.
KeyCDNNo (cheap PAYG)Simple asset CDN for WordPress / static sitesMediumNo-frills, fast, popular with WordPress users.
FastlyFree trial onlyEnterprise sites needing custom edge logicHardVery powerful, very complex. Overkill for most.
AWS CloudFrontFree tier (limited)Sites already on AWS, integration with S3HardBest if you already live inside the AWS ecosystem.

For most users we’d suggest starting with Cloudflare — the free tier is genuinely good, setup is the simplest, and there’s tons of community documentation if you get stuck. If you’ve outgrown Cloudflare’s free plan or want pay-as-you-go pricing, BunnyCDN is excellent value.


📋 Before You Start — Your Pre-Flight Checklist

Don’t skip this section. Doing these checks first will save you hours of “why isn’t it working?” later.

  1. Your domain is resolving correctly on NTCloud. Make sure your nameservers have already been pointed to NTCloud, propagation has completed, and your site loads when you visit it. If your site isn’t yet resolving on NTCloud, sort that first before moving to an external CDN.
  2. Your site loads correctly on our nameservers — open your domain in a fresh browser/incognito window and confirm it loads as expected. Don’t move to an external CDN if the site is broken on our side; you’ll just inherit the same problem on top of new CDN-shaped problems.
  3. You know what email service you use. If you use email on your domain (e.g. NTCloud mailboxes or Google Workspace), note down the MX records before changing anything. Migrating nameservers without copying MX records is the #1 way people accidentally kill their email.
  4. You have access to your registrar account. That’s the place you bought your domain — Namecheap, GoDaddy, Porkbun, NameSilo, etc. You’ll need to log in to change nameservers there.
  5. You have access (or are about to create an account) on your chosen external CDN.

💡 Tip: Set your domain up on our hosting FIRST, fully resolve it on our nameservers, and only THEN move to an external CDN. This guarantees the external CDN can import all the right DNS records automatically.


🚀 Step-by-Step — Cloudflare as an Example

Cloudflare is the most popular external CDN, the free plan covers most use cases, and the setup is dead simple. We’ll use it as the worked example — the steps for other CDNs (BunnyCDN, KeyCDN, Fastly) are very similar and we’ll cover them after.

1️⃣ First, get your domain working on our nameservers

Before doing anything else:

  • Point your domain to NTCloud’s nameservers at your registrar. You’ll find the correct nameservers in your NTCloud control panel when you add the domain.
  • This lets our system generate every DNS record needed for your hosting — the A records pointing to the right IP, plus any TXT, MX or CNAME records relevant to your setup.
  • Wait for propagation. Usually a few minutes; sometimes longer.
  • Confirm your site loads on our hosting from a fresh browser window.

Why does this matter? Because in the next step Cloudflare will automatically scan your domain’s DNS and import every record it finds. If your records aren’t there yet, Cloudflare can’t import what doesn’t exist.

📘 Related guide: How to update your nameservers walks through doing this at the most common registrars.

2️⃣ Add your domain to Cloudflare

Once your site is happily resolving on our nameservers:

  1. Head to cloudflare.com and create a free account (or log in to an existing one).
  2. Click Add a site and type in your domain name (without the http:// or any subdomain, just yourdomain.com).
  3. Choose the Free plan unless you specifically need Pro/Business features.
  4. Cloudflare will automatically scan and import all DNS records — your A records, MX records, TXT records, CNAMEs, everything tied to your current setup with us.
  5. Carefully review the imported records. Compare them against the DNS records you can see on your NTCloud DNS panel. If anything’s missing (rare, but possible), add it manually inside Cloudflare now.
  6. Click Continue.

⚠️ Don’t skip the review step. Cloudflare’s automatic import is good but not perfect. Missing an MX record here means your email stops working the moment you change nameservers. Double-check it!

3️⃣ Change your nameservers at your registrar

After Cloudflare imports your records, it’ll give you two new nameservers that look something like ali.ns.cloudflare.com and vicente.ns.cloudflare.com (the names vary per account).

  1. Log in to your domain registrar (Namecheap, GoDaddy, Porkbun, NameSilo, etc.).
  2. Find the nameserver settings for your domain (usually called Nameservers, DNS or DNS Management).
  3. Remove our nameservers and replace them with the two Cloudflare nameservers.
  4. Save the changes.

This tells the global DNS system “Hey, Cloudflare is now in charge of this domain.” Your hosting stays with us — only the DNS layer moves.

4️⃣ Wait for propagation

Nameserver changes typically take a few minutes to a few hours, with a worst-case of around 24 hours for full global propagation. Back in Cloudflare, click Done, check nameservers and they’ll email you when they detect the change.

💡 Verify propagation: Use a tool like whatsmydns.net to check your domain’s nameservers from multiple locations worldwide. When most/all of them show the Cloudflare nameservers, you’re good.

5️⃣ Verify everything still works

Once Cloudflare confirms it’s active:

  • Open your website in a fresh browser/incognito window — it should load normally.
  • Send yourself a test email (and from a different account, send TO your domain email) — confirm mail still works.
  • Check HTTPS is working (the padlock in the browser bar).
  • If you use any third-party services that verify your domain (Google Search Console, Bing Webmaster, etc.), confirm they’re still validated.

That’s it — you’re done! Your site is now being served through Cloudflare’s edge network, with our hosting still doing the heavy lifting on the backend.


🔧 Setting Up Other CDNs (BunnyCDN, KeyCDN, Fastly)

The Cloudflare flow above is the simplest because Cloudflare wants to be your full DNS host. Other CDNs work slightly differently — they don’t necessarily take over your DNS, they just front-cache your site. Here’s how the most popular alternatives work:

🐰 BunnyCDN

  1. Sign up at bunny.net and add a Pull Zone for your domain.
  2. Set the Origin URL to your domain name on our hosting (e.g. https://yourdomain.com) — BunnyCDN will pull content from there.
  3. BunnyCDN gives you a hostname like yourzone.b-cdn.net.
  4. Two routes from here: either (a) connect a custom hostname like cdn.yourdomain.com via a CNAME so static assets load from there, or (b) put BunnyCDN fully in front of your site using their Bunny DNS service and CNAME flattening.
  5. Configure caching rules and SSL inside the BunnyCDN dashboard.

🔑 KeyCDN

  1. Sign up at keycdn.com and create a Pull Zone.
  2. Set the Origin URL to your domain on our hosting.
  3. KeyCDN issues you a zone URL like yourzone-abc.kxcdn.com.
  4. Add a Zone Alias like cdn.yourdomain.com inside KeyCDN, then create a matching CNAME record in your DNS pointing to the kxcdn.com hostname.
  5. Configure your WordPress site (or static HTML) to load assets from the new CDN hostname.

⚡ Fastly

  1. Fastly is the most powerful option but also the most complex. Sign up at fastly.com.
  2. Create a Service, set your origin to your domain on our hosting.
  3. Configure VCL (Varnish Configuration Language) rules for caching, redirects, header manipulation, etc.
  4. Point your domain (via CNAME or full DNS delegation) to your Fastly service hostname.
  5. Verify the service is healthy in the Fastly dashboard.

Fastly is genuinely fantastic but it’s an “enterprise” tool. If you’re not 100% sure why you’d pick Fastly over Cloudflare, you probably don’t need Fastly.

💡 Common pattern: Most non-Cloudflare CDNs act as a front-end for specific assets (images, JS, CSS) rather than taking over your entire DNS. You typically create a cdn.yourdomain.com subdomain that points to the CDN, then update your site to load static files from there. Cloudflare is unusual in that it wants to handle all traffic at the DNS layer.


🗂️ DNS Records — What to Leave Alone & What to Add

Once you’ve moved nameservers to an external CDN like Cloudflare, you are now managing your DNS — not us. Here’s a quick guide to what each record does, so you don’t accidentally break things:

Record typeWhat it doesSafe to edit?
A / AAAAPoints your domain to the hosting IP (origin server).Only if you know the new IP. Wrong IP = site down.
CNAMEAliases one hostname to another (e.g. www → root domain).Usually safe to add new ones. Don’t delete imported ones unless sure.
MXRoutes email for your domain. Critical for receiving mail.Only edit if you know what you’re doing.
TXTDomain verification, SPF, DKIM, DMARC and similar.Safe to add. Don’t delete imported ones unless sure.
NSNameservers for the domain itself.Leave alone — managed by the CDN you switched to.
SRVService records (e.g. for VoIP, calendaring).Edit only if you specifically use a service requiring them.

⚠️ Don’t delete records you don’t understand. If the import brought across a record you weren’t expecting (e.g. a weird-looking TXT or CNAME), it’s almost certainly there for a reason — domain verification, SPF, DKIM, etc. Leave it alone unless you know what it does.


🔒 SSL / HTTPS with an External CDN

This is one of those areas that trips people up. Here’s the deal:

  • When you put an external CDN in front of your site, there are actually two SSL connections: visitor → CDN, and CDN → our hosting (origin).
  • The CDN handles the visitor-facing certificate for you. Cloudflare gives free SSL automatically on the Free plan.
  • The CDN → origin connection should always be SSL too, otherwise you get a “mixed mode” setup that’s not actually secure.

Cloudflare SSL mode — choose carefully

Inside Cloudflare → SSL/TLS → Overview, you’ll see four modes. Pick wisely:

SSL modeWhat it doesWhen to use it
OffNo SSL. Just HTTP.Never. Don’t use this.
FlexibleSSL between visitor and Cloudflare only. Cloudflare talks to origin over HTTP.Never. Looks safe, isn’t safe, breaks WordPress redirects.
FullSSL on both legs. Origin can use a self-signed cert.✅ Default recommendation.
Full (strict)SSL on both legs, plus validates the origin’s certificate.✅ Best option

💡 Recommended: Use Full or Full (strict). Flexible looks like it works but actually breaks WordPress redirect loops and is genuinely insecure. Never use Flexible. Ever.

Always Use HTTPS

While you’re in Cloudflare’s SSL section, also enable:

  • Always Use HTTPS — auto-redirects http:// to https:// at the edge.
  • Automatic HTTPS Rewrites — fixes mixed-content warnings for resources hardcoded as http://.
  • Minimum TLS Version: 1.2 or 1.3 — modern security baseline.

📦 Caching Settings Worth Knowing

The whole point of a CDN is caching. Here’s what to do (and what NOT to do) on the most common providers:

Sensible default caching settings

  • Caching Level: Standard — caches static assets, lets dynamic content pass through.
  • Browser Cache TTL: 4 hours to 1 day for most sites. Longer for sites that rarely change.
  • Auto Minify (HTML/CSS/JS): careful with this — it can break some themes/plugins. Test thoroughly.
  • Brotli compression: turn it on. Smaller payloads, faster sites.
  • Polish (image optimisation): available on Cloudflare Pro+ plans. Worth it if you have an image-heavy site.

Bypass caching for logged-in users

If you’re running WordPress, make sure your CDN doesn’t cache pages for logged-in users — otherwise admins and members see other people’s cached versions of pages. Cloudflare handles WordPress cookies sensibly by default, but if you’ve enabled aggressive caching (“Cache Everything” page rule), you need a matching bypass rule for wp-admin and the WordPress login cookie.

Purging the cache

When you make site changes and they’re not showing up, the CDN cache is usually the culprit. Each external CDN provider has a Purge Cache button inside their dashboard — use it after big content updates.


📧 Don’t Forget About Your Email!

This deserves its own section because it’s how people most often break things. When you move nameservers from us to an external CDN, the new CDN becomes your DNS host — which means it’s also where your email-related DNS records need to live.

Before changing nameservers, write down every record relating to email:

  • MX records — tells the world where to deliver email for your domain.
  • SPF (TXT) — authorises which servers can send mail on behalf of your domain.
  • DKIM (TXT) — cryptographic signature record proving emails are legitimately from you.
  • DMARC (TXT) — tells receiving servers what to do with mail that fails SPF/DKIM.
  • Autodiscover / Autoconfig CNAMEs — used by mail clients (Outlook, Apple Mail) to auto-set up mailboxes.

Cloudflare’s automatic import usually catches these correctly, but always double-check after the import and before you change nameservers. If even ONE MX record is missing, your inbound email will silently fail — and you won’t notice until someone calls you saying their email bounced.

🚨 Test email after the switch. Send yourself a test from an external account (e.g. a Gmail you own) to your domain email. If it arrives, you’re golden. If it doesn’t, check your MX records on the new DNS host.


🛑 Important: Who Supports What

Once you’ve pointed your nameservers to an external CDN, the responsibility split shifts. NTCloud still handles your origin hosting — site files, mailboxes, server-side errors, backups — but everything from the DNS layer outwards becomes the external CDN’s domain. That includes SSL certificate issuance and renewal (it’s now done by the CDN, not us), caching, WAF and page rules, and any troubleshooting at the CDN layer. We don’t have access to your Cloudflare/BunnyCDN/KeyCDN/Fastly dashboard, so we can’t diagnose or fix issues there.

Here’s a clear breakdown:

LayerWho handles itExamples
Hosting / origin serverNTCloud (us)Site files, WordPress install, mailboxes, server-side errors (500/502/503), backups, your NTCloud control panel.
DNS / nameserver layerYour external CDNA records, MX records, TXT records, propagation, sub-domain DNS, custom record types.
Edge / CDN layerYour external CDNCaching, page rules, WAF rules, redirects, country blocking, Rocket Loader, image optimisation, etc.
SSL / HTTPS certificateYour external CDNOnce nameservers point to an external CDN, that CDN issues and manages the SSL certificate. We no longer issue or renew SSL for the domain.
CDN-side troubleshootingYou + your CDN’s supportWe don’t have access to your external CDN account, so we can’t diagnose CDN-layer issues (cache misses, page-rule conflicts, CDN error pages, SSL mode problems, etc.). That sits with the CDN’s support team.
Domain registrationYour registrarWHOIS, renewal billing, transfer locks, nameserver settings.

If you’re not sure where a problem sits, the fastest way to find out is to pause/disable the external CDN temporarily. On Cloudflare you can set DNS records to “DNS only” (grey cloud) which removes proxying — if the issue disappears, it’s a CDN setting. If it persists, it’s likely an origin issue and we can help.


🛠️ Troubleshooting Common Issues

“Too many redirects” / ERR_TOO_MANY_REDIRECTS

This is the #1 issue when setting up Cloudflare in front of a WordPress site. It’s almost always caused by Cloudflare’s Flexible SSL mode (mentioned above). Change it to Full or Full (strict) and the loop stops immediately.

Site won’t load at all after nameserver change

  • Check the nameservers actually changed at your registrar (sometimes the save doesn’t stick).
  • Use whatsmydns.net to verify propagation.
  • In Cloudflare, confirm your A record points to the correct origin IP (it should match the one shown in your NTCloud DNS panel).
  • If the A record is wrong, fix it in Cloudflare and wait 5 minutes.

Email stopped working

  • Log into your external CDN’s DNS dashboard.
  • Compare the MX records there against what we had before the switch.
  • Re-add any missing MX, SPF, DKIM or DMARC records.
  • Wait 5–10 minutes for the records to propagate.

SSL/HTTPS errors after switching

  • Cloudflare’s Universal SSL can take 15–30 minutes to activate after you change nameservers.
  • Make sure your SSL mode is Full (not Flexible, not Off).
  • Enable Always Use HTTPS in the SSL/TLS → Edge Certificates section.

Site changes aren’t showing up

  • It’s almost certainly cache. Purge the CDN cache from the external provider’s dashboard.
  • Also clear your browser cache (Ctrl+Shift+R / Cmd+Shift+R for a hard reload).
  • If you have a WordPress cache plugin too, purge that as well.

Random “522 / 524” errors on Cloudflare

These are Cloudflare-specific error pages indicating it couldn’t reach our hosting in time. They’re rare on our infrastructure but can occur during brief network blips. If you see them repeatedly, contact us — that part is on our side.

📘 Related guide: Common Cloudflare notices & what they mean covers the most common Cloudflare error pages in plain English.


↩️ Switching Back to Our Nameservers

Changed your mind? No problem — you can switch back at any time. Here’s how:

  1. Log in to your domain registrar.
  2. Find the nameserver settings.
  3. Replace the external CDN’s nameservers with NTCloud’s nameservers (you’ll find these in your NTCloud control panel).
  4. Save and wait for propagation.
  5. Once propagated, our system will pick up the domain again and your built-in CDN will kick back in automatically.

💡 Tip: Before switching back, make sure all the DNS records you’d added externally (MX, TXT, custom subdomains etc.) are also configured on our side. Otherwise you might lose email or specific subdomains during the cut-over.


❓ External CDN FAQs

Will an external CDN make my site faster than your built-in CDN?

Not necessarily. Our hosting already has caching, compression and a CDN baked in. For most sites the speed difference is negligible. External CDNs win on flexibility, features and bandwidth offload — not raw page-load times.

Does using an external CDN cost extra?

Cloudflare’s Free plan is genuinely free and covers most small/medium sites. BunnyCDN is pay-as-you-go (typically a few dollars a month for small sites). KeyCDN is similarly cheap. Fastly is enterprise-priced. Our hosting fee doesn’t change either way.

Can I still use your built-in CDN if I’m on Cloudflare too?

Once your domain’s nameservers point to Cloudflare, all visitor traffic goes through Cloudflare first. Our built-in CDN is on the origin side, so it still does its job behind the scenes, but the user-facing CDN is Cloudflare. You’re not running “two CDNs” — you’re running Cloudflare’s edge in front of our caching origin.

Do I lose any features by moving to Cloudflare?

Your NTCloud control panel keeps working as normal — file manager, FTP/SSH access, databases, mailboxes, one-click installs, web optimisation, malware scans, logs, etc. The only things that move to the external CDN are DNS hosting and edge caching/SSL. If you previously added DNS records inside NTCloud (e.g. third-party A, CNAME, MX or TXT records via the Domain Names section), you’ll now do those inside the external CDN’s DNS panel instead. NTCloud’s built-in Edge Caching becomes redundant for visitor traffic (since the external CDN is in front), but you can still use NTCloud’s Edge Caching dashboard to purge caches if needed.

Will SSL break when I switch?

How SSL works changes depending on where your nameservers point. If you stay on NTCloud nameservers, NTCloud issues your SSL via the Security → SSL/TLS tab inside your control panel (SSL can only be issued once your nameservers have resolved, and may take up to 30 minutes to take effect globally — always test on a cleared cache). The moment you point nameservers to an external CDN, that CDN takes over SSL — for example, Cloudflare issues its own Universal SSL automatically (usually within 15–30 minutes of propagation). Just make sure your CDN’s SSL mode is set to Full or Full (strict). NTCloud no longer issues or renews SSL while a domain is sitting behind an external CDN.

My CDN setup is broken — can you help?

NTCloud’s support covers the origin hosting side — things like server-side errors (500/502/503), mailbox issues, file/database problems, or anything where the underlying site itself is misbehaving. We don’t diagnose CDN-side issues (cache misses, page-rule conflicts, CDN error pages, SSL mode problems, WAF blocks, etc.) because we don’t have access to your third-party CDN account. Those need to go to Cloudflare/BunnyCDN/KeyCDN/Fastly support, or you can fix them in their dashboard yourself.

Should I use Cloudflare’s “Always Online” / “Rocket Loader”?

Always Online is great — it serves stale cached pages when the origin is unreachable. Leave it on. Rocket Loader is a JavaScript performance feature that’s been known to break some themes/plugins — turn it on, test thoroughly, and disable it if anything weird happens.

Can I use Cloudflare just for DNS, without proxying?

Yes — set each DNS record to “DNS only” (the grey cloud icon). This uses Cloudflare as your DNS host without routing traffic through their CDN. You lose the caching/security benefits but keep simpler DNS management.

What happens to my domain’s WHOIS / registration?

Nothing. Your domain registration stays with whoever you bought the domain from. Nameservers and registrar are two completely separate things — changing nameservers doesn’t affect domain ownership.

Can I use a CDN with a static HTML site (no WordPress)?

Yes — even better, in fact. Static HTML sites are perfect for aggressive CDN caching because there’s no logged-in state to worry about. Just point your nameservers to your chosen CDN and let it cache everything.

Is using a CDN GDPR-compliant?

Most CDNs (Cloudflare, BunnyCDN, KeyCDN, Fastly) offer EU-region settings and Data Processing Agreements. If you serve EU visitors, check your chosen CDN’s GDPR documentation and update your privacy policy to mention the CDN as a data processor.


✅ Quick Summary

  • You can use any external CDN with our hosting — Cloudflare, BunnyCDN, KeyCDN, Fastly or others.
  • Set the domain up on our nameservers first, confirm it’s all working, then move to the external CDN.
  • Cloudflare’s automatic DNS import is the simplest route — just review the records carefully.
  • Always use Cloudflare SSL mode Full or Full (strict) — never Flexible.
  • Double-check your email records (MX, SPF, DKIM, DMARC) before changing nameservers.
  • Once on an external CDN, that CDN’s dashboard is where you manage DNS, caching, SSL and firewall settings.
  • You can switch back to our nameservers whenever you want.

You’re now ready to set up your external CDN like a pro. Take it slow, double-check each step, and don’t skip the email-record review!

Share this article: