9ecf359 Thanks @alexanderniebuhr! - Improves the image proxy endpoint when using the default compile option to adhere to user configuration regarding the allowed remote domains
#1425902366e9 Thanks @ascorbic! - Removes warning when using the adapter with a static build.
The Cloudflare adapter now has several uses outside of on-demand rendered pages, so this warning is misleading. Similar warnings have already been removed from other adapters.
#1423415b55f3 Thanks @yanthomasdev! - Fixes an issue that could cause duplicate exports when configuring workerEntrypoint.namedExports
#1424077b18fb Thanks @delucis! - Increases the minimum supported version of Astro to 5.7.0
#140667abde79 Thanks @alexanderniebuhr! - Refactors the internal solution which powers Astro Sessions when running local development with Λastro devΛ.
The adapter now utilizes Cloudflareβs local support for Cloudflare KV. This internal change is a drop-in replacement and does not require any change to your projectct code.
However, you now have the ability to connect to the remote Cloudflare KV Namespace if desired and use production data during local development.
#138377cef86f Thanks @alexanderniebuhr! - Adds new configuration options to allow you to set a custom workerEntryPoint for Cloudflare Workers. This is useful if you want to use features that require handlers (e.g. Durable Objects, Cloudflare Queues, Scheduled Invocations) not supported by the basic generic entry file.
This feature is not supported when running the Astro dev server. However, you can run astro build followed by either wrangler deploy (to deploy it) or wrangler dev to preview it.
The following example configures a custom entry file that registers a Durable Object and a queue handler:
#135272fd6a6b Thanks @ascorbic! - The experimental session API introduced in Astro 5.1 is now stable and ready for production use.
Sessions are used to store user state between requests for on-demand rendered pages. You can use them to store user data, such as authentication tokens, shopping cart contents, or any other data that needs to persist across requests:
---
exportconstprerender=false; // Not needed with 'server' output
Sessions require a storage driver to store the data. The Node, Cloudflare and Netlify adapters automatically configure a default driver for you, but other adapters currently require you to specify a custom storage driver in your configuration.
If you are using an adapter that doesnβt have a default driver, or if you want to choose a different driver, you can configure it using the session configuration option:
import { defineConfig } from'astro/config';
import vercel from'@astrojs/vercel';
exportdefaultdefineConfig({
adapter: vercel(),
session: {
driver: 'upstash',
},
});
Using sessions
Sessions are available in on-demand rendered pages, API endpoints, actions and middleware.
In pages and components, you can access the session using Astro.session:
In endpoints, actions, and middleware, you can access the session using context.session:
exportasyncfunctionGET(context) {
constcart=await context.session.get('cart');
return Response.json({ cart });
}
If you attempt to access the session when there is no storage driver configured, or in a prerendered page, the session object will be undefined and an error will be logged in the console:
---
exportconstprerender=true;
constcart=await Astro.session?.get('cart'); // Logs an error. Astro.session is undefined
---
Upgrading from Experimental to Stable
If you were previously using the experimental API, please remove the experimental.session flag from your configuration:
#13514a9aafec Thanks @ascorbic! - Automatically configures Cloudflare KV storage when experimental sessions are enabled
If the experimental.session flag is enabled when using the Cloudflare adapter, Astro will automatically configure the session storage using the Cloudflare KV driver. You can still manually configure the session storage if you need to use a different driver or want to customize the session storage configuration. If you want to use sessions, you will need to create the KV namespace and declare it in your wrangler config. You can do this using the Wrangler CLI:
Terminal window
npxwranglerkvnamespacecreateSESSION
This will log the id of the created namespace. You can then add it to your wrangler.json/wrangler.toml file like this:
wrangler.json
{
"kv_namespaces": [
{
"binding": "SESSION",
"id": "<your kv namespace id here>",
},
],
}
By default it uses the binding name SESSION, but if you want to use a different binding name you can do so by passing the sessionKVBindingName option to the adapter. For example: