@astrojs/ cloudflare v12.5.2 GitHub npm Changelog This adapter allows Astro to deploy your on-demand rendered routes and features to Cloudflare, including server islands, actions, and sessions. If you’re using Astro as a static site builder, you don’t need an adapter. Learn how to deploy your Astro site in our Cloudflare deployment guide. Why Astro Cloudflare Section titled Why Astro Cloudflare Cloudflare’s Developer Platform lets you develop full-stack applications with access to resources such as storage and AI, all deployed to a global edge network. This adapter builds your Astro project for deployment through Cloudflare. Installation Section titled Installation Astro includes an astro add command to automate the setup of official integrations. If you prefer, you can install integrations manually instead. Add the Cloudflare adapter to enable server-rendering in your Astro project with the astro add command. This will install @astrojs/cloudflare and make the appropriate changes to your astro.config.mjs file in one step. npm pnpm Yarn Terminal window npx astro add cloudflare Now, you can enable on-demand rendering per page, or set your build output configuration to output: 'server' to server-render all your pages by default. Manual Install Section titled Manual Install First, add the @astrojs/cloudflare adapter to your project’s dependencies using your preferred package manager. npm pnpm Yarn Terminal window npm install @astrojs/cloudflare Then, add the adapter to your astro.config.mjs file: astro.config.mjs import { defineConfig } from 'astro/config'; import cloudflare from '@astrojs/cloudflare'; export default defineConfig({ adapter: cloudflare(), }); Options Section titled Options The Cloudflare adapter accepts the following options: cloudflareModules Section titled cloudflareModules Type: boolean Default: true Enables imports of .wasm, .bin, and .txt modules. This functionality is enabled by default. If you’d like to disable, set cloudflareModules to false. imageService Section titled imageService Type: 'passthrough' | 'cloudflare' | 'compile' | 'custom' Default: 'compile' Determines which image service is used by the adapter. The adapter will default to compile mode when an incompatible image service is configured. Otherwise, it will use the globally configured image service: cloudflare: Uses the Cloudflare Image Resizing service. passthrough: Uses the existing noop service. compile: Uses Astro’s default service (sharp), but only on pre-rendered routes at build time. For pages rendered on-demand, all astro:assets features are disabled. custom: Always uses the image service configured in Image Options. This option will not check to see whether the configured image service works in Cloudflare’s workerd runtime. astro.config.mjs import { defineConfig } from "astro/config"; import cloudflare from '@astrojs/cloudflare'; export default defineConfig({ adapter: cloudflare({ imageService: 'cloudflare' }), }) platformProxy Section titled platformProxy Determines whether and how the Cloudflare runtime is added to astro dev. It contains proxies to local workerd bindings and emulations of Cloudflare specific values, allowing the emulation of the runtime in the Node.js dev process. Read more about the Cloudflare Runtime. Note Proxies provided by this are a best effort emulation of the real production. Although they are designed to be as close as possible to the real thing, there might be a slight differences and inconsistencies between the two. platformProxy.enabled Section titled platformProxy.enabled Type: boolean Default: true Determines whether to enable the Cloudflare runtime in development mode. platformProxy.configPath Section titled platformProxy.configPath Type: string Default: undefined Defines the path to the Wrangler configuration file. If no value is set, it tracks wrangler.toml, wrangler.json, and wrangler.jsonc in the project root. platformProxy.environment Section titled platformProxy.environment Type: string Default: undefined Sets the Cloudflare environment to use. You must select an environment defined in the Wrangler configuration file, otherwise an error occurs. platformProxy.persist Section titled platformProxy.persist Type: boolean | { path: string } Default: true Sets whether and where to save binding data locally to the file system. If set to true, binding data is stored in .wrangler/state/v3/. It is the same as the default setting for wrangler. If set to false, binding data is not stored in file system. If set to { path: string }, binding data is stored in the specified path. Note wrangler’s --persist-to option adds a sub directory called v3 under the hood while the @astrojs/cloudflare persist property does not. For example, to reuse the same location as running wrangler dev --persist-to ./my-directory, you must specify: persist: { path: "./my-directory/v3" }. The following configuration shows an example of enabling the Cloudflare r

Make your apps truly interactive with Cloudflare Realtime and RealtimeKit 2025-04-09 Zaid Farooqui Will Allen Abhishek Kankani 7 min read Over the past few years, we’ve seen developers push the boundaries of what’s possible with real-time communication — tools for collaborative work, massive online watch parties, and interactive live classrooms are all exploding in popularity. We use AI more and more in our daily lives. Text-based interactions are evolving into something more natural: voice and video. When users interact with the applications and tools that AI developers create, we have high expectations for response time and connection quality. Complex applications of AI are built on not just one tool, but a combination of tools, often from different providers which requires a well connected cloud to sit in the middle for the coordination of different AI tools. Developers already use Workers, Workers AI, and our WebRTC SFU and TURN services to build powerful apps without needing to think about coordinating compute or media services to be closest to their user. It’s only natural for there to be a singular "Region: Earth" for real-time applications. We're excited to introduce Cloudflare Realtime — a suite of products to help you make your apps truly interactive with real-time audio and video experiences. Cloudflare Realtime now brings together our SFU, STUN, and TURN services, along with the new RealtimeKit. Say hello to RealtimeKit RealtimeKit is a collection of mobile SDKs (iOS, Android, React Native, Flutter), SDKs for the Web (React, Angular, vanilla JS, WebComponents), and server side services (recording, coordination, transcription) that make it easier than ever to build real-time voice, video, and AI applications. RealtimeKit also includes user interface components to build interfaces quickly.  The amazing team behind Dyte, a leading company in the real-time ecosystem, joined Cloudflare to accelerate the development of RealtimeKit. The Dyte team spent years focused on making real-time experiences accessible to developers of all skill levels, and had a deep understanding of the developer journey — they built abstractions that hid WebRTC's complexity without removing its power. Already a user of Cloudflare’s products, Dyte was a perfect complement to Cloudflare’s existing real-time infrastructure spanning 300+ cities worldwide. They built a developer experience layer that made complex media capabilities accessible. We’re incredibly excited for their team to join Cloudflare as we help developers define the future of user interaction for real-time applications as one team. Interactive applications shouldn't require WebRTC expertise  For many developers, what starts as "let's add video chat" can quickly escalate into weeks of technical deep dives into WebSockets and WebRTC. While we are big believers in the potential of WebRTC, we also know that it comes with real challenges when building for the first time. Debugging WebRTC sessions can require developers to learn about esoteric new concepts such as navigating ICE candidate failures, TURN server configurations, and SDP negotiation issues. The challenges of building a WebRTC app for the first time don’t stop there. Device management adds another layer of complexity. Inconsistent camera and microphone APIs across browsers and mobile platforms introduce unexpected behaviors in production. Chrome handles resolution switching one way, Safari another, and Android WebViews break in uniquely frustrating ways. We regularly see applications that function perfectly in testing environments fail mysteriously when deployed to certain devices or browsers. Systems that work flawlessly with 5 test users collapse under the load of 50 real-world participants. Bandwidth adaptation falters, connection management becomes unwieldy, and maintaining consistent quality across diverse network conditions proves nearly impossible without specialized expertise.  What starts as a straightforward feature becomes a multi-month project requiring low-level engineering to solve problems that aren’t core to your business. We realized that we needed to extend our products to client devices to help solve these problems. RealtimeKit SDKs for Kotlin, React Native, Swift, JavaScript, Flutter RealtimeKit is our toolkit for building real-time applications without common WebRTC headaches. The core of RealtimeKit is a set of cross-platform SDKs that handle all the low-level complexities, from session establishment and media permissions to NAT traversal and connection management. Instead of spending weeks implementing and debugging these foundations, you can focus entirely on creating unique experiences for your users. Recording capabilities come built-in, eliminating one of the most commonly requested yet difficult-to-implement features in real-time applications. Whether you need to capture meetings for compliance, save virtual classroom sessions for students who couldn't attend li

Begin with our "Getting started" and "Core" modules to grasp the essential skills for web development.