Cloudflare

@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

Get Started Cloudflare Workers provides a serverless execution environment that makes it possible to create, deploy, and run applications without the need to configure or maintain infrastructure. In this tutorial, you will learn how to use Cloudflare Workers and Notion API to handle form submissions by collecting data from a HTML form and storing it in a Notion Database. Notion is an all-in-one productivity tool for your notes, tasks, wikis and databases. Notion provides an extensable API that allows you to interact with Notion data programmatically, so that you can connect that data to other tools. Cloudflare Workers will handle incoming form submissions and use Notion’s REST API to persist the data in a Notion Database. Prerequisties In order for you to continue with this tutorial, you need to have the following: Working knowledge of HTML, CSS, JavaScript How to work with APIs A Notion account Step 0: Running Workers on Replit Everything needed to start building with Workers is available directly in this Repl. To get started with this learn module, you need to click Run in your Replit workspace to set up a Workers project using Wrangler. The run command will set up a new Workers project, initialize a Git repository, set up a TypeScript project, and create a Fetch handler. You should see a new directory /src/ and configuration files like wrangler.toml and tsconfig.json created. export default { async fetch( request: Request, env: Env, ctx: ExecutionContext ): Promise<Response> { return new Response("Hello World!"); }, }; Once you're done with that, we're ready to start building our application!