#16435c4d321b Thanks @jamesopstad! - Add support for Preview deployments (currently in private beta)
Non-inheritable bindings set internally by the Cloudflare adapter are now also set in the previews section of the config so that they are inherited by Preview deployments.
#16320a43eb4b Thanks @matthewp! - Uses redirect: 'manual' for remote image fetches in the Cloudflare binding image transform, consistent with all other image fetch paths
#16307a81dd3e Thanks @matthewp! - Surfaces console.log and console.warn output from workerd during prerendering
#16210e030bd0 Thanks @matthewp! - Fixes .svelte files in node_modules failing with Unknown file extension ".svelte" when using the Cloudflare adapter with prerenderEnvironment: 'node'
#16225756e7be Thanks @travisbreaks! - Fixes ERR_MULTIPLE_CONSUMERS error when using Cloudflare Queues with prerendered pages. The prerender worker config callback now excludes queues.consumers from the entry worker config, since the prerender worker only renders static HTML and should not register as a queue consumer. Queue producers (bindings) are preserved.
#161514978165 Thanks @matthewp! - Fixes a dev-mode crash loop in the Cloudflare adapter when using Starlight by excluding @astrojs/starlight from SSR dependency optimization
#16109c887b4a Thanks @matthewp! - Fix HMR crash when editing content collection files caused by Vite’s SSR transform colliding with zod v4’s meta export
#15888925252e Thanks @matthewp! - Fixes a bug where dependencies imported by prerender-only server:defer islands could remain as bare imports in server output, causing module resolution failures in preview and Cloudflare Workers.
#15875c43ef8a Thanks @matthewp! - Include workerd response details in Cloudflare prerenderer errors to make getStaticPaths() failures easier to diagnose.
#15815d1872ee Thanks @matthewp! - Prebundle additional Astro runtime dependencies for Cloudflare development server, speeding up initial start time and preventing required restarts.
#158723b47b89 Thanks @Princesseuh! - Fixes images not working in dev mode when using the cloudflare option
By default, Cloudflare uses its workerd runtime for prerendering static pages. Set prerenderEnvironment to 'node' to use Astro’s built-in Node.js prerender environment instead, giving prerendered pages access to the full Node.js ecosystem during both build and dev. This is useful when your prerendered pages depend on Node.js-specific APIs or NPM packages that aren’t compatible with workerd.
astro.config.mjs
import cloudflare from'@astrojs/cloudflare';
import { defineConfig } from'astro/config';
exportdefaultdefineConfig({
adapter: cloudflare({
prerenderEnvironment: 'node',
}),
});
🐞 Patch Changes
#1584550fcc8b Thanks @aqiray! - fix: show actionable error when running astro preview without prior build
#15794d1ac58e Thanks @OliverSpeir! - Fixes image serving in passthrough mode by using the Cloudflare ASSETS binding instead of generic fetch, which does not work in Workers for local assets
#15850660da74 Thanks @tristanbes! - fix(cloudflare): forward configPath and other PluginConfig options to the Cloudflare Vite Plugin
Options like configPath, inspectorPort, persistState, remoteBindings, and auxiliaryWorkers were accepted by the type system but never forwarded to cfVitePlugin(), making them silently ignored.
Also fixes addWatchFile for configPath which resolved the path relative to the adapter’s node_modules directory instead of the project root.
#1583295e12a2 Thanks @Princesseuh! - Fixes return; syntax not working in the frontmatter correctly in certain contexts
#15803e42b015 Thanks @merlinnot! - Fixes the Cloudflare adapter adding a SESSION KV binding even when sessions are explicitly configured to use a different driver, such as unstorage/drivers/null.
#14306141c4a2 Thanks @ematipico! - Changes the API for creating a custom entrypoint, replacing the createExports() function with a direct export pattern.
What should I do?
If you’re using a custom entryPoint in your Cloudflare adapter config, update your existing worker file that uses createExports() to reflect the new, simplified pattern:
console.log(`consumed from our queue: ${messages}`);
}
} satisfiesExportedHandler<Env>,
The manifest is now created internally by the adapter.
#15435957b9fe Thanks @rururux! - Changes the default image service from compile to cloudflare-binding. Image services options that resulted in broken images in development due to Node JS incompatiblities have now been updated to use the noop passthrough image service in dev mode. - (Cloudflare v13 and Astro6 upgrade guidance)
#1540041eb284 Thanks @florian-lefebvre! - Removes the workerEntryPoint option, which wasn’t used anymore. Set the main field of your wrangler config instead
astro dev now runs your Cloudflare application using Cloudflare’s workerd runtime instead of Node.js. This means your development environment is now a near-exact replica of your production environment—the same JavaScript engine, the same APIs, the same behavior. You’ll catch issues during development that would have only appeared in production, and features like Durable Objects, Workers Analytics Engine, and R2 bindings work exactly as they do on Cloudflare’s platform.
New runtime
Previously, Astro.locals.runtime provided access to Cloudflare-specific APIs. These APIs have now moved to align with Cloudflare’s native patterns.
What should I do?
Update occurrences of Astro.locals.runtime:
Astro.locals.runtime.env → Import env from cloudflare:workers
Astro.locals.runtime.cf → Access via Astro.request.cf
Astro.locals.runtime.caches → Use the global caches object
Astro.locals.runtime (for ExecutionContext) → Use Astro.locals.cfContext
Here’s an example showing how to update your code:
The cloudflareModules option has been removed because it is no longer necessary. Cloudflare natively supports importing .sql, .wasm, and other module types.
What should I do?
Remove the cloudflareModules option from your Cloudflare adapter configuration if you were using it:
The Astro Cloudflare adapter now only supports deployment to Cloudflare Workers by default in order to comply with Cloudflare’s recommendations for new projects. If you are currently deploying to Cloudflare Pages, consider migrating to Workers by following the Cloudflare guide for an optimal experience and full feature support.
🍿 Minor Changes
#15435957b9fe Thanks @rururux! - Adds support for configuring the image service as an object with separate build and runtime options
It is now possible to set both a build-time and runtime service independently. Currently, 'compile' is the only available build time option. The supported runtime options are 'passthrough' (default) and 'cloudflare-binding':
#15077a164c77 Thanks @matthewp! - Adds support for prerendering pages using the workerd runtime.
The Cloudflare adapter now uses the new setPrerenderer() API to prerender pages via HTTP requests to a local preview server running workerd, instead of using Node.js. This ensures prerendered pages are built using the same runtime that serves them in production.
Developers can now use astro preview to test their Cloudflare Workers application locally before deploying. The preview runs using Cloudflare’s workerd runtime, giving you a staging environment that matches production exactly—including support for KV namespaces, environment variables, and other Cloudflare-specific features.
#150378641805 Thanks @matthewp! - The Wrangler configuration file is now optional. If you don’t have custom Cloudflare bindings (KV, D1, Durable Objects, etc.), Astro will automatically generate a default configuration for you.
What should I do?
If your wrangler.jsonc only contains basic configuration like this:
{
"main": "@astrojs/cloudflare/entrypoints/server",
"compatibility_date": "2026-01-28",
"assets": {
"directory": "./dist",
"binding": "ASSETS",
},
}
You can safely delete the file. Astro will handle this configuration automatically.
You only need a wrangler config file if you’re using:
For greater flexibility and improved consistency with other Astro code, session drivers are now specified as an object:
import { defineConfig } from 'astro/config'
import { defineConfig, sessionDrivers } from 'astro/config'
export default defineConfig({
session: {
driver: 'redis',
options: {
url: process.env.REDIS_URL
},
driver: sessionDrivers.redis({
url: process.env.REDIS_URL
}),
}
})
Specifying the session driver as a string has been deprecated, but will continue to work until this feature is removed completely in a future major version. The object shape is the current recommended and documented way to configure a session driver.
#15080f67b738 Thanks @gameroman! - Updates wrangler dependency to be a peerDependency over a dependency
#150396cc96e7 Thanks @matthewp! - Fixes static content deployment by moving it to another folder, so Wrangler can tell the static and worker content apart
#15452e1aa3f3 Thanks @matthewp! - Fixes server-side dependencies not being discovered ahead of time during development
Previously, imports in .astro file frontmatter were not scanned by Vite’s dependency optimizer, causing a “new dependencies optimized” message and page reload when the dependency was first encountered. Astro is now able to scan these dependencies ahead of time.
#153915d996cc Thanks @florian-lefebvre! - Fixes types of the handle() function exported from /handler, that could be incompatible with types generated by wrangler types
#15696a9fd221 Thanks @Princesseuh! - Fixes duplicate logging showing up in some cases when prerendering pages
#153094b9c8b8 Thanks @ematipico! - Update the underneath @cloudflare/workers-types library to address a warning emitted by the package manager during the installation.
#150794463a55 Thanks @ascorbic! - Fixes auto-provisioning of default bindings (SESSION KV, IMAGES, and ASSETS). Default bindings are now correctly applied whether or not you have a wrangler.json file.
Previously, these bindings were only added when no wrangler config file existed. Now they are added in both cases, unless you’ve already defined them yourself.
#1569466449c9 Thanks @matthewp! - Fixes deployment of static sites with the Cloudflare adapter
Fixes an issue with detecting and building fully static sites that caused deployment errors when using output: 'static' with the Cloudflare adapter
#1556530cd6db Thanks @ematipico! - Fixes an issue where the use of the Code component would result in an unexpected error.
#1512106261e0 Thanks @ematipico! - Fixes a bug where the Astro, with the Cloudflare integration, couldn’t correctly serve certain routes in the development server.
#157784ebc1e3 Thanks @ematipico! - Fixes an issue where the computed clientAddress was incorrect in cases of a Request header with multiple values. The clientAddress is now also validated to contain only characters valid in IP addresses, rejecting injection payloads.
This CommonJS dependency could sometimes cause errors because Astro is ESM-only. It is now replaced with a built-in ESM-friendly implementation.
#15075ee2c260 Thanks @matthewp! - Adds deprecation errors for Astro.locals.runtime properties to help migrate from Astro v5 to v6
When accessing the removed Astro.locals.runtime properties on Cloudflare, developers now receive clear error messages explaining the migration path:
Astro.locals.runtime.env → Use import { env } from "cloudflare:workers"
Astro.locals.runtime.cf → Use Astro.request.cf
Astro.locals.runtime.caches → Use the global caches object
Astro.locals.runtime.ctx → Use Astro.locals.cfContext
#153369cce92e Thanks @ascorbic! - Fixes a dev server issue where framework components from linked packages would fail to load with a 504 error.
This could occur when using client:only or other client directives with components from monorepo packages (linked via file: or workspace protocol). The first request would trigger Vite’s dependency optimizer mid-request, causing concurrent client module requests to fail.
#15255a66783a Thanks @florian-lefebvre! - Fixes a case where the types of handle() could mismatch with the ones from the user’s project. They now rely on globals, that can be obtained by running wrangler types
#1504531074fc Thanks @ematipico! - Fixes an issue where using the Vue integration with the Cloudflare adapter resulted in some runtime errors.
#15386a0234a3 Thanks @OliverSpeir! - Updates astro add cloudflare to use the latest valid compatibility_date in the wrangler config, if available
#15432e2ad69e Thanks @OliverSpeir! - Removes unnecessary warning about sharp from being printed at start of dev server and build
#15588425ea16 Thanks @rururux! - Fixes an issue where esbuild would throw a “Top-level return cannot be used inside an ECMAScript module” error during dependency scanning in certain environments.
#1545050c9129 Thanks @florian-lefebvre! - Fixes a case where build.serverEntry would not be respected when using the new Adapter API
#15030b5aa52b Thanks @ematipico! - Fixed an issue where the feature experimental.chromeDevtoolsWorkspace wasn’t supported by the new version of the adapter.
#15648802426b Thanks @rururux! - Restore and fix <Code /> component functionality on Cloudflare Workers.
#15478ee519e5 Thanks @matthewp! - Fixes fully static sites to not output server-side worker code. When all routes are prerendered, the _worker.js directory is now removed from the build output.
#152696f82aae Thanks @ematipico! - Fixes a regression where build.serverEntry stopped working as expected.
#1579805771cf Thanks @rururux! - Fixes a regression where using the adapter would throw an error when using an integration that uses JSX.
#15053674b63f Thanks @matthewp! - Excludes astro:* and virtual:astro:* from client optimizeDeps in core. Needed for prefetch users since virtual modules are now in the dependency graph.
#154955b99e90 Thanks @leekeh! - Refactors to use middlewareMode adapter feature (set to classic)
#157784ebc1e3 Thanks @ematipico! - Fixes an issue where the computed clientAddress was incorrect in cases of a Request header with multiple values. The clientAddress is now also validated to contain only characters valid in IP addresses, rejecting injection payloads.