cloudflareAug 7, 2026

Unveiling good and bad behaviors on the Agentic Internet (opens in new tab)

The Internet contains a mix of human, automated, and hybrid traffic, so classifying visitors simply as “good humans” or “bad bots” no longer works. Cloudflare argues that website owners should evaluate continuous behavior and build trust over time, rather than rely only on isolated risk checks. Its strategy combines transparent bot classification through BotBase with behavioral detection through Precursor. ## Risk and Trust Are Different - **Risk** measures how likely a request or action is to be harmful, often based on a momentary event. - **Trust** develops over time through reputation and observed behavior. - A suspicious action should not automatically lead to rejection if the actor has an established, trustworthy identity. - Cloudflare’s goal is to create incentives for safer behavior, from blocking malicious activity to enabling beneficial automated participation. ## Verified Bots and Transparency - Cloudflare defines verified bots and agents through two requirements: - They honestly declare who they are. - They do not abuse the trust they receive. - Transparency helps site owners decide which behaviors and data uses to permit. - BotBase is designed as a directory of all known bots and agents, not just approved ones. - Actors that violate expectations can lose their verified status and become harder to trust across Cloudflare’s network. ## Continuous Detection with Precursor - Precursor is a client-side system that continuously analyzes behavior throughout a session. - Its JavaScript is injected at the CDN, so customers do not need to manually place or rerun detection code. - Unlike CAPTCHAs and other one-time challenges, Precursor evaluates behavior in context over multiple pages. - Continuous analysis makes it more expensive for bot developers to imitate human behavior across an entire session. ## What Cloudflare Has Observed - In a 24-hour snapshot, Precursor processed **206 million evaluation events across 73,438 zones**. - Suspicious behavior frequently begins in the middle of a session, meaning point-in-time checks can miss it. - A single session may shift between human and automated behavior, such as when a user hands part of a shopping journey to an agent. - Site owners therefore need classifications based on use case, purpose, and data usage rather than a simple human-versus-bot decision. ## Understanding Human Cursor Behavior - **Precursor Trace** is an interactive demonstration of part of Precursor’s detection process. - It examines cursor acceleration, corrections, rhythm, and movement texture. - The demo illustrates how behavioral signals can distinguish natural interaction from automated movement. ## Adaptive Intelligence - Cloudflare indicates that its bot detection engines will soon provide more adaptive outcomes for requests identified as automated. - The excerpt ends before detailing how this upcoming capability will work. Website owners should treat automation as a spectrum: verify transparent actors, monitor behavior continuously, and make decisions based on trust, intent, and use case rather than isolated signals.

cdncloudflarejavascriptagentic-ai+3

cloudflareJul 31, 2026

An API for MoQ: provision your own isolated relays (opens in new tab)

Cloudflare has moved MoQ from an open testing network toward production use by adding isolated relays and authentication. Its provisioning API and dashboard let applications create globally available relay scopes and issue separate publisher and subscriber credentials, without deploying infrastructure. The beta supports MoQ Transport drafts 14 and 16 and is currently free. ## MoQ and Its Architecture - MoQ is an open IETF publish/subscribe protocol built on QUIC, the transport used by HTTP/3. - Publishers send named data streams, while subscribers request those streams through relays. - Relays copy data to subscribers without inspecting its contents, enabling efficient fan-out. - The same system can support live video, video calls, low-latency messaging, and other real-time workloads. - Using CDN-based relays avoids the cost and complexity of operating specialized media servers. ## From Open Preview to Production - Cloudflare’s initial MoQ preview exposed an unauthenticated relay on servers in more than 330 cities. - Over 1,000 clients continue to use the open endpoints daily for testing and development. - The lack of authentication made the preview unsuitable for applications requiring confidentiality or role-based permissions. - For example, live auction applications need broadcasters to publish while viewers can only subscribe. ## Isolated Cloudflare Relays - Provisioning a relay creates an isolated scope across Cloudflare’s existing global network rather than starting a VM, container, or dedicated process. - Each scope separates an application’s namespaces, tracks, and objects from those of other applications. - Clients connect through an Anycast endpoint, with Cloudflare handling global routing. - Relays become available within seconds, without regional capacity planning, load balancers, or server management. - Cloudflare compares the model to creating a virtual host rather than deploying a new web server. ## Provisioning API and Access Tokens - The control-plane API manages relay configuration and credentials but does not handle the media flowing through relays. - A relay defines the isolated application scope. - Tokens grant `publish`, `subscribe`, or both operations for a specific relay. - Tokens can have expiration times and can be revoked independently. - Creating a relay automatically returns: - A token capable of publishing and subscribing. - A subscribe-only token intended for viewers. - Additional narrowly scoped tokens can be created through the API or dashboard. - Current tokens apply to an entire relay; Cloudflare is working with the MoQ community on more granular authorization. ## Using the API and Dashboard - A relay can be created with one authenticated API request containing its name. - Tokens can be added through an endpoint such as `/moq/relays/$RELAY_ID/tokens`. - The dashboard workflow is available under **Media > Realtime > MoQ Relay**. - Applications should provide broadcasters with publish-capable credentials and viewers with subscribe-only credentials. ## Connecting Clients - Clients send their token when opening a MoQ session. - The relay enforces the token’s permitted operations. - Cloudflare’s open-source `moq-rs` tools can be used with media generated by tools such as `ffmpeg`. Cloudflare’s authenticated, isolated MoQ relays make the protocol more practical for production real-time applications. Developers can use the API or dashboard to provision a globally distributed relay and manage separate, expiring credentials without operating their own media infrastructure.

cdncloudflarejwtwebrtc+3

cloudflareJul 23, 2026

Introducing Cache Response Rules (opens in new tab)

Cache Response Rules let Cloudflare modify an origin response after it arrives but before it is stored in cache. They address response-header problems—such as accidental `Set-Cookie`, restrictive `Cache-Control`, or problematic validators—that can unnecessarily reduce cacheability. This provides an origin-independent fix while preserving the distinction between request-time and response-time caching decisions. ## When Caching Decisions Are Made - CDN caches aim to serve content from the edge and contact the origin only on misses. - Origin response headers determine: - Whether content can be cached - How long it remains fresh - When it should be revalidated - Whether it should be cached at all - Common problems include: - `Set-Cookie` on static assets such as `/static/app.js`, making them uncacheable - `Cache-Control: no-cache` on content that is safe to cache at the CDN - Browser-oriented cache directives that are unsuitable for Cloudflare - Overly aggressive `ETag` values causing repeated revalidation - These issues often require coordination between separate origin and CDN teams, delaying simple fixes. ## Cache Response Rules - Run after the origin responds but before Cloudflare writes the response to cache. - Can: - Rewrite `Cache-Control` directives - Strip `Set-Cookie`, `ETag`, and `Last-Modified` - Manage cache tags for purging - Apply entirely within Cloudflare, without requiring origin code changes. - They solve problems that request-time rules cannot, because response headers are unavailable until after the origin request completes. ## The Missing Piece in Cloudflare’s Cache Controls - Earlier caching behavior was largely handled through Page Rules, which combined caching with unrelated features. - Cloudflare later introduced more focused controls, including: - Cache Rules - CDN-Cache-Control - Custom cache keys - Other cache-specific settings - Most existing controls operate during the request phase. - Before contacting the origin, Cloudflare can evaluate only request information such as the URL, headers, file extension, geography, and device type. - Previously, response-header problems required: - Changing the origin - Deploying a Worker to re-fetch and rewrite responses - Accepting a lower cache hit ratio ## Two Phases, Two Questions - **Cache Rules** run before the origin request and determine: - Whether the response is eligible for caching - What cache key identifies the object - How it should be cached, including TTL and stale-serving behavior - **Cache Response Rules** run after the origin response and determine whether caching behavior should be adjusted: - Remove headers that make content ineligible - Change origin cache directives - Set cache tags - When the two rule types conflict, the Cache Response Rule takes precedence. - Response rules cannot change the cache key, since that must already be established during the request phase. - They can make an otherwise eligible response non-cacheable with `no-store`, or make content eligible by removing `Set-Cookie`, but they cannot recover the latency of a request that was already excluded from caching at request time. Cache Response Rules complement rather than replace Cache Rules. Use request-phase rules for cache eligibility, keys, and general caching behavior; use response-phase rules to correct origin headers before they damage cacheability.

cdncloudflarecachingcache-response-rules+2

discordJun 9, 2026

How We Moved Discord Voice to the Edge (opens in new tab)

Discord migrated its voice and video infrastructure from roughly 30 hyperscaler regions to Cloudflare’s edge network, which spans more than 300 cities. The move brought measurable gains—over 80% of traffic now runs on Cloudflare, with Frankfurt seeing 34% lower ping and 42% lower packet loss—but the rollout exposed important limitations. Local server proximity alone is not enough; call placement and network peering are equally critical. ## Why Discord Moved Voice to the Edge - Traditional cloud regions left users in places such as Reykjavik, Auckland, Hawaii, and Lagos relatively far from voice servers. - Cloudflare’s 300-plus points of presence offered the possibility of hosting Discord’s software much closer to users. - Unlike typical CDN workloads, Discord needed to route live UDP packets for voice and video calls rather than cache static content. - More than 80% of Discord voice and video traffic now uses Cloudflare, and 70% of regions have improved year over year. ## Iceland: Local Servers Can Hurt Mixed Calls - Discord’s first test took place in Reykjavik, where users previously connected to servers in Rotterdam. - Iceland-only calls improved: - Ping decreased 9%. - Packet loss decreased 11%. - Mixed-region calls became worse: - Ping for non-Iceland participants increased 2.7 times. - Packet loss rose 9%. - Discord assigns one SFU to host an entire call, so all participants send traffic to that server. - A call started by one Icelandic user could therefore force German participants to route packets to Iceland and back. - Discord concluded that new edge locations help only when calls hosted there are primarily local; mixed calls require smarter host-placement logic. ## Rotterdam: Network Peering Was the Bottleneck - Discord next moved Rotterdam traffic to Cloudflare’s Amsterdam PoP. - Most regional ISPs performed normally, but Orange users experienced: - More than one second of latency during peak periods. - A 30% regression in voice freeze ratio. - The issue was not Cloudflare’s Amsterdam infrastructure itself, but the path between Orange and Cloudflare. - Traffic traveled through Telia’s transit backbone, where the Telia–Orange connection was already saturated. - Adding more traffic made the congestion worse. - Discord reverted the migration after about ten days. - Cloudflare pursued direct peering with Orange and added SFUs in Paris and London to provide shorter paths. ## A More Careful Migration Strategy - Discord changed its rollout process from capacity-based scheduling to peering-based analysis. - Before shifting meaningful traffic to a region, the team now checks whether Cloudflare has sufficient peering capacity with major local ISPs. - The migration slowed from a planned large-scale rollout to a region-by-region deployment. - The experience demonstrated that: - A geographically closer PoP does not always produce the best call experience. - SFU host placement matters for calls spanning multiple regions. - Transit routes and ISP peering can be more important than physical distance. Discord’s edge migration is succeeding, but only through incremental deployment, detailed traffic analysis, and improved call-placement decisions. The practical lesson is that low-latency infrastructure depends on the complete network path—not simply on adding servers closer to users.

cdncloudflareedge-computingwebrtc+3

cloudflareApr 2, 2026

Why we-re rethinking cache for the AI era (opens in new tab)

AI traffic is fundamentally changing how CDNs should think about caching. Unlike human visitors, AI crawlers make broad, high-volume, often sequential requests for long-tail content, creating low reuse and substantial cache churn. Cloudflare argues that traditional LRU-based caching and techniques such as prefetching are increasingly poorly suited to this traffic, forcing operators to rethink cache design if they want to support AI access without harming human performance. ## Why AI Traffic Is Different - Automated traffic accounts for 32% of Cloudflare’s network traffic, including crawlers, scrapers, and AI assistants. - AI agents often: - Send many requests in parallel. - Scan large portions of a website sequentially. - Request rarely visited or loosely related pages. - Fetch documentation, images, and articles from many sources. - AI crawlers represent approximately 80% of self-identified AI bot traffic. - Most single-purpose AI bot traffic is associated with model training, with search-related crawling a distant second. ## The Three Defining Characteristics of AI Crawlers - **High unique URL ratio:** More than 90% of pages observed in large-scale Common Crawl datasets are unique by content. - **Content diversity:** Different crawlers target different materials, including source code, technical documentation, media, and blog posts. - **Crawling inefficiency:** Many requests lead to 404 errors or redirects because of poor URL handling. - AI crawlers generally lack browser-side caching and shared session behavior, so independent crawler instances may repeatedly appear as new visitors. - They can also repeatedly revisit content while iteratively refining search results, but each iteration still tends to fetch mostly new pages. ## How AI Crawling Disrupts Traditional Caches - Conventional CDN caching keeps frequently requested content available near users and evicts less recently used objects when storage fills. - Cloudflare uses an LRU (least recently used) policy, but broad AI scans introduce large numbers of low-reuse objects. - These objects can evict content that human visitors are more likely to request. - AI-driven long-tail access increases cache misses and sends more requests back to origin servers. - Cache speculation and prefetching become less effective because crawler access patterns are difficult to predict. - Higher miss rates can cause: - Slower responses. - Increased origin-server load. - Greater egress costs. - Reduced cache hit rates for human traffic. ## Implications for Website Operators - Operators face a tradeoff between optimizing infrastructure for human visitors and accommodating AI crawlers. - Some organizations may want to encourage AI access: - Developers may want documentation represented in AI models. - E-commerce companies may want product information included in LLM search results. - Publishers may seek compensation through systems such as pay-per-crawl. - The challenge is supporting useful AI traffic without allowing it to degrade the cache performance experienced by human users. Cloudflare’s analysis, conducted with ETH Zurich researchers, suggests that CDN caching strategies need to evolve beyond traditional assumptions about popularity and reuse. Cache systems designed specifically for AI-era traffic may need to isolate crawler workloads or otherwise prevent broad, low-reuse scans from displacing content valuable to human users.

cdnragai-crawlersdata-fetching+4

discordDec 15, 2025

Discord Patch Notes: December 8, 2025 (opens in new tab)

Discord’s December 8, 2025 patch focuses on faster uploads, quicker video playback, a redesigned Desktop User Settings experience, and broad reliability improvements. Major infrastructure updates include resumable media uploads, Rust-based retry logic, and CDN changes that substantially reduce video startup latency. The release also contains numerous desktop, mobile, chat, localization, and UI bug fixes. ## Uploads, Performance, and Settings - Media uploads now support resuming after interruptions, which is especially useful for large files. - New Rust-based retry logic reduced upload latency by about 15% overall: - iOS: 21% faster - Android: 10% faster - CDN configuration changes improved video embed startup times: - P90 latency fell from 600 ms to 275 ms. - P95 latency fell from 1,250 ms to 658 ms. - Rare cases involving videos taking up to 40 seconds to start were also addressed. - Desktop User Settings received a redesign intended to make options easier to find, with metrics indicating improved usability. ## Platform and General Improvements - Mobile apps upgraded from React Native 0.78 to 0.81.4. - Desktop upgraded to Electron 37. - Server Hub search is now more performant, particularly for hubs connected to more than 50 servers. - Linux clients no longer display duplicate titlebars. - Various desktop rendering issues were fixed, including stray white pixels, incorrect scrollbars, spacing problems, and MacOS traffic-light alignment. - Server folders, unread channels, invite searches, profile previews, and image previews received multiple correctness fixes. - Emoji Studio now properly re-centers images when using Reset Image. - Search in Settings no longer produces empty categories for certain queries. - Several localization issues were corrected, including “Edit Profiles” and “Search in DMs.” - Users can now dismiss the Upcoming Events banner in voice channels. - Event invites, event popouts, custom-location sharing, and event Join buttons were repaired. - Android and iOS fixes address server folders, server lists, nameplates, role settings, and profile customization controls. ## Chat and Messaging Fixes - Multiline typing in the Desktop Message Forward interface no longer causes visual shifting. - Spoiler timestamps now render correctly before content is revealed. - Mobile fixes improve message-row sizing, reply navigation, forum interactions, and thread rendering. - Android code blocks once again use monospace formatting. - Sticker Picker and Emoji Picker navigation now behaves correctly on Android. - Scrollbars remain interactive when thread previews are present. - Inbox navigation to thread-creation messages has been fixed. - Forum post search no longer includes excessive blank space. - Additional iOS fixes address swiping to reply, navigating to message replies, and displaying the thread spine connecting avatars to threads. Overall, the update combines meaningful performance improvements with a large collection of visual and interaction fixes. Users who depend on large uploads, embedded video, mobile chat, or Desktop settings should benefit most, though the changes may continue rolling out across platforms.

cdnandroidiosrust+4

slackApr 14, 2025

Optimizing Our E2E Pipeline (opens in new tab)

Slack optimized its monorepo E2E pipeline by avoiding frontend rebuilds when a pull request contains no frontend changes. Using `git diff` to detect relevant changes and serving recent frontend artifacts from S3 through an internal CDN, the team reduced build frequency by 60% and cut end-to-end pipeline time from roughly 10 minutes to 2 minutes. The changes also lowered storage and compute costs and improved test reliability. ## The Cost of Unnecessary Frontend Builds - Slack’s E2E pipeline validates frontend, backend, database, and service changes before merging into `main`. - Previously, every run rebuilt the frontend, even when a pull request changed only backend or unrelated files. - A typical pipeline included: - About 5 minutes for the frontend build - Deployment to QA - More than 200 E2E tests taking another 5 minutes - With hundreds of pull requests merged daily, redundant builds caused: - Thousands of unnecessary builds each week - Nearly a gigabyte of S3 data per build - Terabytes of duplicate stored artifacts - Significant developer and cloud-compute costs ## Conditional Frontend Builds - Slack used `git diff` with three-dot notation to compare the checked-out branch against `main`. - If frontend files had changed, the pipeline ran a new frontend build. - If no frontend changes were detected, the build step was skipped. - Git analyzed the repository’s more than 100,000 tracked files in only a few seconds. ## Reusing Prebuilt Assets - When a new build was unnecessary, the pipeline located a recent frontend build already stored in AWS S3. - The selected artifact was still in production, ensuring the E2E tests used sufficiently current frontend assets. - An internal CDN served those assets to the QA environment. - S3 naming and asset-management conventions made it possible to find an appropriate artifact in under three seconds on average. ## Results and Additional Benefits - Frontend build frequency fell by 60%. - Average E2E pipeline time dropped from about 10 minutes to 2 minutes. - Monthly savings included hundreds of hours of compute and developer waiting time. - S3 usage decreased by several terabytes per month. - Test flakiness reached its lowest measured level, partly because asset delivery became more consistent. - The work also exposed legacy systems and generated a backlog of future maintenance improvements. Slack’s experience demonstrates that pipelines should not automatically repeat expensive steps when their inputs have not changed. Detecting affected files and reusing trustworthy build artifacts can substantially improve speed, reliability, and cost without requiring a wholesale rewrite of the CI/CD system.

cdnci-cdgitmonorepo+4