Why Drupal behind a CDN needs cache tag purging from day one
A CDN in front of Drupal serves cached copies of anonymous pages from locations close to readers, so fewer requests reach the origin web servers and database. A team needs one when anonymous traffic strains the origin, when page loads vary by region, or when traffic spikes from campaigns or news would otherwise overwhelm the hosting. The difficulty is not turning caching on. It is making sure that when an editor publishes or corrects a page, the edge stops serving the old version within a time the business accepts. Cache tag purging is what makes that possible, because Drupal attaches cache tags to every response that identifies the nodes, views, menus and blocks it contains.
Drupal sends those tags in response headers, and CDN-specific contributed modules use them to invalidate exactly the affected pages instead of the whole cache. Teams should confirm which purge module and CDN connector fit their provider, since support differs by vendor, and check the current documentation on Drupal.org before choosing. Purging by URL remains useful for simple cases, but it misses pages that list changed content, such as listings and homepages, unless the mapping is planned. The work spans three areas: Drupal configuration (purge queue, cache tag mapping, which pages are cacheable), origin headers that the CDN must respect, and editorial workflows such as scheduled publishing and bulk imports that create many invalidations at once. Each needs an owner before launch, because a missing tag shows stale content to readers and an excessive purge erodes the cache benefit.
Which CDN and purge approach fits which situation
This table compares Cloudflare, Fastly and Akamai for a team running Drupal in its own infrastructure, then sets out tag-based against URL-based purging. Read each row as a question to answer with the vendor and the module's Drupal.org page before choosing, because integration details change between releases. The main takeaway is that the purge model and the edge logic you need usually matter more than the brand.
| Decision point | Cloudflare | Fastly | Akamai |
|---|---|---|---|
| Drupal integration path | Confirm the current Cloudflare module on Drupal.org and its purge support | Confirm the current Fastly module on Drupal.org and its tag purge support | Confirm the current Akamai module on Drupal.org and its supported purge methods |
| How purging is triggered | Confirm whether purges run from Drupal cache tags, URLs or both | Confirm whether surrogate key purges run from Drupal cache tags | Confirm whether purges are queued from Drupal and how failed requests are retried |
| Tag-based purging support | Confirm with the vendor and module page before assuming tag support | Typically the strongest fit for tag purging, so confirm the module supports it | Confirm with the vendor and module page before assuming tag support |
| Edge logic options | Confirm which edge rules, workers and cache rules your plan supports | Confirm which VCL-based or edge logic options apply to your setup | Confirm which edge configuration and scripting options your contract includes |
| Authenticated traffic handling | Confirm how cookies and session variants are bypassed at the edge | Confirm how Drupal session cookies are excluded from caching | Confirm how Drupal session cookies are excluded from caching |
| Fits a team that needs | Simple anonymous page caching with URL purges and a managed edge | Fine-grained tag purging with custom edge logic and a Varnish-style model | Large enterprise estates with existing Akamai contracts and governance |
| Team skills to plan for | DNS, WAF and cache rule administration | VCL and Varnish-style configuration | Akamai configuration and property management |
| Tag purge versus URL purge | Tag purge removes every page carrying a Drupal cache tag, so content changes reach related listings | URL purge removes only named pages, which is simpler but can leave listings stale | Choose tag purging when pages aggregate many entities, and URL purging for small static sites |
Setting up a CDN in front of Drupal in order
This sequence takes a Drupal site from an uncached origin to an edge layer that serves anonymous pages, purges the right URLs when content changes, and keeps logged-in and form traffic off the cache. Each step ends with a check the team can repeat after every change.
Confirm Drupal version and hosting path
The platform team records the Drupal core version, the PHP version, the web server and the database, and confirms which hostnames will sit behind the CDN. Drupal 10 requires PHP 8.1 or later and Drupal 11 requires PHP 8.3 or later, so the CDN module chosen in a later step must match the running core. The team also documents whether the site runs as one site or several and where the origin is reachable. This step is done when the team has a written inventory that the CDN vendor, the hosting team and the Drupal developers all sign off on.
Set cache headers and lifetimes for anonymous pages
Before any edge rule is written, the Drupal developers confirm that anonymous page responses carry correct cache headers, including the cache tags and max-age values that Drupal core emits, and that the page cache and dynamic page cache are enabled. The team decides a default lifetime for anonymous pages and records which content types or views need a shorter one. A simple test is to request an anonymous page twice with curl and confirm the response includes the cache tag header and a max-age value rather than no-cache directives. The step is complete when those headers are present on the representative pages listed in the inventory.
Configure the CDN and origin allowlist
The platform or network team creates the CDN service for the chosen provider, whether Cloudflare, Fastly or Akamai, and points the hostnames at the origin. They restrict origin access so that only the CDN's published address ranges or a shared secret header can reach the web server, which keeps purge and cache traffic from bypassing the edge. Drupal's trusted host patterns must include the public hostnames. The check is a direct request to the origin IP that is refused and a request through the CDN hostname that returns the expected status and cache response header.
Install and map the purge integration to content events
The Drupal developers install the CDN or purge integration module that matches the provider and the Drupal core version, then configure the purger with the provider's API credentials stored outside the codebase. They map content events to invalidation: saving or deleting a node, changing a taxonomy term, updating a menu or a block, and changing a user's published state each invalidate the cache tags those entities emit. Teams should confirm with the module documentation how queued purges are processed, because cron or a queue worker must run for invalidations to leave Drupal. The step is done when a test save produces a purge entry in the queue and the purge log records it.
Exclude authenticated and form traffic
The team writes edge rules so that requests carrying a Drupal session cookie, requests to the user login and account paths, and POST requests to forms bypass the cache entirely. Drupal's anonymous cache contexts must be checked so that pages personalized by role or language vary correctly. Form tokens and the Drupal cookie names should be listed in the CDN configuration with the vendor's cookie-bypass feature, and the team should confirm that no shared cache key can serve one user's page to another. The check is a logged-in test account whose responses come from the origin with a bypass or miss status, plus an anonymous session that receives cached responses.
Verify cache hits and purges with test edits
The QA team reads the CDN response headers for a set of anonymous pages and confirms that repeated requests return a hit status after the first miss. They then edit a test node, a listing page that references it and a term used in a menu, and confirm that the edge serves the updated content within the time the purge queue takes to run. Each test is recorded with the page URL, the time of the edit, the response header before and after and any page that stayed stale. The step closes when every test case passes, the results are filed with the change record, and the team has agreed who runs these checks after each release.
Setting cache lifetimes for anonymous, authenticated and admin pages
Anonymous content pages are the easiest pages to cache at the edge because the response does not change per visitor. Drupal's page cache and dynamic page cache mark each response with cache tags for the entities it renders and cache contexts for anything that varies the output, such as the user role or the requested format. When those contexts are limited to anonymous defaults, the origin can send a cache header that allows the edge to hold the page for a long time, and the content team can rely on tag-based purging to clear it when a node changes. The decision points are:
- Cache lifetime at the origin: Confirm the
Cache-Controlheaders the origin sends for anonymous responses, and set the edge lifetime deliberately rather than inheriting a default from the CDN. - Tag coverage: Verify that every rendered entity, menu and block contributes its cache tags, because a missing tag means a stale page after an edit.
- Purge trigger: Connect entity save and delete events to a tag-based purge, so an edited node clears only the pages that reference it.
- Cookies: Confirm that anonymous responses do not set session cookies, since a cookie on the response can stop the edge from caching it.
- Testing: Request the page twice from outside your network and check the cache status header changes from miss to hit.
Ask your CDN vendor and your Drupal module maintainers to confirm the exact header and purge behavior for your chosen edge product.
Lists and views pull many entities into one page, such as a news index, a filtered product list or a paginated archive. They are cached as a single response, so any change to a listed entity affects that page even though the page itself was not edited. Views add their own cache metadata, including cache contexts for query arguments, pager state and the current language. A list cached at the edge without these contexts may serve the wrong page of results, so the team should decide which lists are safe to hold at the edge and which should remain at the origin. The points to check are:
- Tag inheritance: Confirm that a view tags its response with the node types it lists, so a new or edited item clears the list.
- Query arguments: Decide which URL parameters the edge should treat as part of the cache key and which it should ignore, such as tracking parameters.
- Pagination: Check that paged lists are purged together when the first page changes, since later pages depend on the same entities.
- Exposed filters: Lists with filters can multiply cache variants quickly, so limit the cached combinations or send them to the origin.
- Lifetime: Use a shorter edge lifetime for lists that change often, and confirm the value with the content owner.
Review the largest lists with the editorial team before setting any edge lifetime.
Authenticated pages carry a session and usually show personal data, such as account pages, saved items or role-specific content. Drupal sends a session cookie for logged-in users and marks these responses with the user cache context, which means they must not be shared between visitors. The safe default is to bypass the edge cache for any request carrying a session cookie and let the origin render the page. Some teams cache anonymous-looking fragments for logged-in users through edge-side includes or client-side personalization, but that design needs careful review. The points to confirm are:
- Cookie bypass rules: Configure the edge to bypass caching when the Drupal session cookie is present, and test the rule with a real logged-in session.
- Personal data leakage: Confirm that no authenticated response is cached under an anonymous key, since a single mistake can expose one user's data to another.
- Cache contexts: Check that user-specific output carries the user or user permissions context so the origin never reuses it for another account.
- Logout and login: Verify that cookies are cleared correctly and that a logged-in response is not served to a logged-out visitor.
- Privacy review: Involve your privacy and security owners before caching any page that displays personal information.
Verify these rules with a test account in a staging environment before the rule goes live.
Forms, checkout steps, login pages and the administrative interface must not be cached at the edge. Forms carry tokens and state that are unique to each submission, and admin routes expose configuration and editorial controls. Drupal marks these responses as uncacheable or sets a zero lifetime, but the CDN can still override that behavior if its rules are too broad. The configuration should therefore protect these paths explicitly, rather than relying only on the origin headers. The points to check are:
- Path bypass: Create edge rules for
/user,/adminand every form path that your site uses, including custom routes. - Method handling: Confirm that POST requests are never cached and that the edge does not cache responses to requests with a body.
- Form tokens: Test a form submission through the CDN to confirm that tokens validate and that the response is not reused.
- Admin access: Restrict administrative paths at the network or identity layer as well, so the edge is not the only control.
- Regression checks: Add these paths to automated tests so a later CDN rule change does not expose them.
Write the bypass list down as part of the change record and ask your security reviewer to sign off on it.
Security risks when Drupal sits behind a shared edge
A CDN in front of Drupal changes where caching decisions, purge requests, cookies and certificates live, and each of those becomes part of the site's attack surface. The cards below cover the failure modes we check first, from personalized pages cached for the wrong visitor to edge logs that nobody reviews until an incident.
Caching personalized responses
A page that shows one visitor's account data, cart or role-specific content can be stored at the edge and served to everyone who requests the same URL. Drupal marks such responses with cache metadata, but the CDN only honors that metadata if the module and VCL, rules or configuration pass it through correctly. Check that authenticated responses carry no-cache headers at the edge, and test with a logged-out browser against pages that show user-specific blocks. Ask the CDN provider which headers it honors by default.
Origin reachable around the CDN
If the origin server accepts traffic from the public internet, an attacker or a cached-copy scraper can bypass the CDN's WAF, rate limits and cache rules entirely. Restrict origin ingress to the provider's published address ranges or use an authenticated origin pull or private connection where the provider supports it. Confirm that DNS records for the origin are not publicly discoverable through old records, certificate transparency logs or test subdomains.
Purge endpoint access control
Purge requests that remove cached pages by cache tag or URL are powerful, and a purge endpoint left open lets anyone clear the cache repeatedly and load the origin. Keep purge credentials or tokens in the secrets store, limit which hosts and IP ranges may call the purge path, and log each purge with the requester and tag. Test that an unauthenticated request to the purge path fails and that a rejected request does not reach Drupal.
Cookie and session handling at the edge
Drupal sets session cookies for logged-in users, and an edge configuration that caches responses regardless of cookies can share one session with another visitor. Decide which cookies the CDN must see and which it must strip, keep the session cookie on the origin path, and mark cookies Secure and HttpOnly where Drupal sets them. Review how the edge treats cookies on login, logout and form submission pages, since errors are most common there.
TLS and certificate ownership
Someone must hold the private key or the delegated certificate for the public hostname, and the edge terminates TLS for visitors. Record who issued the certificate, who can renew or revoke it, and whether the origin also uses TLS between the CDN and the web server. Track expiry dates in monitoring, and confirm that the domain account at the provider cannot be changed without your organization's approval, since a changed DNS record can redirect the whole site.
Edge logs and incident response
The CDN sees requests your origin logs may never record, including blocked attacks and purge calls, so incident response depends on getting those logs out of the provider's console. Agree on log retention, export format and who can request them, and add edge events to your incident runbook. Drupal's advisory process, run by the Drupal Security Team, tells you when core or a contributed module needs patching, and the edge logs show whether attackers were reaching the affected paths before you patched.
Keeping purges and cache rules correct after launch
A CDN layer stays correct only if someone owns a recurring routine. The first item is purge queue health. Purge modules such as Purge, and the CDN-specific purgers built on it, normally queue invalidation requests and send them after cron or a queue worker runs. If that queue stops draining, editors will see stale pages with no error on screen. Put an alert on queue depth and on the age of the oldest queued item, and check the CDN's own API logs for rejected requests. Confirm with your CDN vendor which purge limits apply to your plan, since rate limits and batch sizes differ by provider and by product tier.
The second item is tag coverage. Every new content type, view, block or entity reference that influences a page needs its cache tags to reach the edge response header, and the CDN must be configured to purge on those tags. A new view added after launch often renders pages that the old tag set never invalidates. After each feature release, pick a sample of pages that embed the new element, edit the underlying content, and confirm the change appears at the edge within the expected window. Review the cache rules on the CDN side too, including which paths bypass the cache, which cookies vary the cache key, and how authenticated traffic is excluded.
The third item is update review. Drupal core and contributed module updates can change cache metadata, add routes or alter response headers, and a security release can shift behavior without any functional change visible to editors. Treat each core or module update as a test of the edge configuration, not only of the application. Rehearse cache clears in a staging environment that mirrors the production CDN settings before each release, and record how long a full invalidation takes, so the team knows what to expect on release night. Cache warming, queue worker sizing and cron scheduling are separate topics in this group, and their configuration should be checked alongside purge health, since a stalled queue worker and a cold cache often appear together after a deploy.
Limits to confirm in your environment before scoping
A CDN in front of Drupal changes how caching, purging and access work, and the limits that matter depend on your CDN plan, your Drupal version and your data rules. Confirm each item below with the CDN vendor and your own team before a fixed scope is written.
CDN plan limits for purging and tags
Purge rate limits, the number of tags or keys a single request can carry, and whether cache tag purging is included in your plan all shape the design. Drupal can generate many cache tags per page, so a plan that allows only URL purges may force broad invalidations after each content change. Ask the vendor for the current purge rate, the tag or key limits, and any overage charges, and confirm them in writing.
Drupal and PHP compatibility with the module
The CDN integration module must support your Drupal core version, and the core version must run on a PHP version the platform still supports. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later. Check the module's supported core versions on its Drupal.org page and confirm the release you plan to use is maintained before you commit to a design.
Whether the origin can be locked to the CDN
If visitors can reach the origin server directly, they can bypass the CDN's access rules, WAF and caching, and purges will not cover the copies they see. Confirm whether your network, load balancer or firewall can accept traffic only from the CDN's published address ranges or from a signed header. Also confirm how the CDN authenticates to Drupal for purge requests, and who owns rotation of those credentials.
Third-party scripts and consent banners
Analytics tags, chat widgets and consent banners often set cookies or vary output by visitor, which can stop pages from being cached at the edge or leak personal data into shared caches. Inventory every script and cookie on anonymous pages, then decide which ones load before consent and which must be moved to the client. Confirm with your privacy team how consent state is stored and whether the CDN may set or read cookies on your behalf.
Multisite and multilingual cache keys
Each site, language, currency or user-facing variant can need its own cache key, and a mistake here can serve one language's page to another visitor. Confirm how the CDN treats host names, query strings, language prefixes and cookies in its cache key, and which headers Drupal sends with each response. Test that purges for one site or language do not remove unrelated cached content, using a staging copy with the same CDN configuration.
Data residency and edge caching rules
Caching a copy of a page at edge locations may count as storing or transferring data outside the region your rules allow, even when the origin stays in your data center. Confirm with your legal and compliance owners which content may be cached at the edge, which regions the CDN uses for caching and logs, and whether personal data appears in cached responses. Record the answer before choosing which routes and content types to cache.
Questions teams ask before hiring help with a Drupal CDN
What drives the cost of putting Drupal behind a CDN?
The main cost driver is how much of the site can be cached safely at the edge, which depends on the number of content types, views, blocks and personalized regions that vary by user. Cost also grows with the number of CDN properties, the purge rules you need, the number of environments, and how many systems must be tested before go-live. Ask for a quote that lists the CDN work, the Drupal module configuration, the purge testing, and the documentation handover as separate lines. One-time work covers design, configuration and testing. Recurring costs sit mostly with the CDN subscription you hold directly, plus any support retainer you choose.
How long does a Drupal CDN project usually take?
Duration depends mainly on the number of content types, views and blocks that need cache tags, and on how many pages mix anonymous and logged-in content. A site with a small, well-known content model usually moves faster than an estate with many custom entities and personalized regions. Testing of purge behavior across every content change type takes time that teams often underestimate. Ask any partner for a written timeline tied to the agreed scope, and confirm which items depend on your CDN account approvals, DNS changes and staging availability.
What must our team provide before the work starts?
Plan to provide access to the DNS zone that points at the site, an administrator account on the CDN service, a staging environment that mirrors production, and named content owners who can confirm expected behavior. You also need a decision on which hostnames, paths and logged-in areas will be cached, and a contact who can approve changes to the production edge configuration. Missing access is one of the most common causes of delay, so list these items in the statement of work and assign a named owner to each one.
Can our internal team set up a Drupal CDN without outside help?
Yes, a team with Drupal and edge networking experience can do this in house. The hard parts are correct cache tag coverage in custom code, safe handling of cookies and session data, and a purge process that is tested for every content change path. If your engineers have not done cache tag work before, a short fixed-scope review or a configuration review can reduce risk without taking over the whole project. Be clear about who will maintain the configuration after launch, because edge rules change as the site changes.
How is cache purging tested before go-live?
Testing should cover each action that changes content, such as publishing, unpublishing, editing a term, changing a menu, and deleting a node, then check that every affected URL and listing refreshes at the edge. Engineers typically use response headers to confirm cache status and check that logged-in responses are never served from the shared cache. Tests should also cover failure cases, such as a purge request that does not reach the CDN, and confirm what the site shows during the gap. Ask for a written test plan with expected results, and keep it as a regression suite for future upgrades.
What changes after a Drupal upgrade when a CDN is in place?
Core and contributed module upgrades can change cache metadata, headers, route behavior or the way cache tags are emitted, so purge and edge rules should be retested after each upgrade. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, so plan the retest as part of that work. Confirm the module versions that support your CDN connector and your Drupal version before you upgrade. Keep the test suite in version control so the retest is repeatable.
How is a fixed-scope quote built for this work?
A fixed-scope quote starts with a written list of the CDN properties, hostnames, content types, views and purge events in scope, followed by the deliverables and acceptance tests. Each deliverable should name what is built, where it runs, and how it is verified. The quote should also list what the client provides, what is excluded, such as changes to unrelated modules or hosting, and the process for change requests. DeployOpen does not publish a price list, and a quote follows from the written scope, so the more precise the scope, the more precise the quote.
How DeployOpen scopes and delivers a Drupal CDN build
DeployOpen plans, implements, hardens and documents self-hosted Drupal inside your own infrastructure, including the CDN layer in front of it. The work is usually a fixed-scope engagement with scope, deliverables and timelines agreed in writing before any build starts. Scoping starts with an inventory of which page types are anonymous and cacheable, which are personalized, which forms and endpoints must bypass the edge, and which content changes trigger purges. Those answers decide the cache configuration, the purge design and the testing effort, so they belong in the written scope rather than in a later change request.
The deliverables typically cover the decisions and the working system: the CDN configuration and origin rules, the cache-control and cookie policy Drupal sends to the edge, the contributed module set and its settings for cache tag or URL purging, the purge queue and its failure handling, a verification test plan with cache hit checks for anonymous and authenticated traffic, and runbooks for purging, rollback and CDN incidents. DeployOpen documents the configuration as code where the platform allows it, so your team can review changes and reproduce the setup. Confirm with the chosen CDN vendor which features, plans and API limits apply to your account, since those details depend on the vendor and your contract.
Handover should be planned as a step in the scope, not an afterthought. Ask for a walkthrough with the engineers who will operate the edge configuration, a written list of credentials and API tokens with owners, and a supervised purge exercise on a staging copy before production. Ongoing support, upgrades and continuous testing are available as optional retainers, which suit teams that want the CDN rules reviewed after each Drupal security release. DeployOpen does not issue audit reports or certifications for the resulting setup; if you need an independent assessment, your auditor or certification body performs it, and DeployOpen prepares the evidence and controls for that review.
