Agents SDK available for building AI agents on Cloudflare Workers
The Agents SDK is available for building AI agents on Cloudflare Workers. It provides a framework for implementing agent functionality within the Workers platform.
Cloudflare Workers · all subjects
framework-guides
313 notes in this subject, read out of this brain and free to use. This is page 1 of 6.
Agents SDK documentation link
The Agents SDK documentation is located at the /agents/ path in the Cloudflare documentation.
AI and agent frameworks for Cloudflare Workers
Cloudflare Workers supports deploying full-stack applications with AI and agent frameworks.
LangChain framework guide on Cloudflare Workers
LangChain is a framework for building AI-powered applications on Cloudflare Workers. Documentation and guidance for using LangChain with Workers is available in the framework guides section.
LangChain Python packages documentation
LangChain documentation for Python packages on Cloudflare Workers is located at /workers/languages/python/packages/langchain/
FastAPI documentation location
FastAPI framework documentation and guide for Cloudflare Workers is located at /workers/languages/python/packages/fastapi/.
FastAPI framework support on Cloudflare Workers
Cloudflare Workers supports deploying FastAPI applications. FastAPI can be used with Python on Cloudflare Workers.
Expo EAS hosting on Worker runtime
Expo provides documentation on hosting with the Worker runtime as part of their EAS (Expo Application Services) hosting reference. The external documentation link is available at https://docs.expo.dev/eas/hosting/reference/worker-runtime/.
Expo backend deployment on Cloudflare Workers
Expo mobile app backends can be deployed on Cloudflare Workers. The framework guide for Expo is located in the mobile-apps documentation section and provides guidance for this deployment pattern.
Next.js automatic R2 caching configuration
For Next.js projects, automatic configuration will set up R2 for caching if your Cloudflare account has R2 enabled. R2 caching improves performance for Incremental Static Regeneration (ISR) and other Next.js caching features. If R2 is enabled, automatic configuration creates an R2 bucket and configures caching automatically. If R2 is not enabled, your project is configured without caching, but you can enable R2 later and manually configure caching by following the OpenNext caching documentation.
Supported frameworks for automatic configuration
Automatic configuration supports: Next.js (adapter: `@opennextjs/cloudflare`, runs migrate automatically with optional R2 caching), Astro (adapter: `@astrojs/cloudflare`, runs astro add cloudflare automatically), SvelteKit (adapter: `@sveltejs/adapter-cloudflare`, runs sv add sveltekit-adapter automatically), Nuxt (built-in Cloudflare preset), React Router (Cloudflare Vite plugin), Solid Start (built-in Cloudflare preset), TanStack Start (Cloudflare Vite plugin), Angular, Analog (built-in Cloudflare preset), Vite (Cloudflare Vite plugin), Vike, Waku, and static sites (any directory with an `index.html`). Automatic configuration may also work with other projects such as React or Vue SPAs.
Web applications framework guide
The Cloudflare Workers documentation includes a framework-guides section for creating full-stack web applications deployed to Cloudflare Workers.
Bindings unavailable for static Astro sites
Bindings cannot be used if you are using Astro to generate a purely static site. Bindings are only available when your Astro application uses on-demand rendering (SSR).
Astro local development server
To start a local development server for an Astro project after creation, run: npm run dev in your project directory.
Astro framework scaffolding with create-cloudflare CLI
To scaffold a new Astro project on Workers, run: npm create cloudflare@latest my-astro-app --framework=astro. This creates a new project directory, initiates Astro's official setup tool, and configures the project for Cloudflare, with an option to instantly deploy to Cloudflare.
Astro Node.js version requirements
Astro 5.x requires Node.js 18.17.1 or higher. Astro 6 (currently in beta) requires Node.js 22 or higher. If using Workers Builds for CI/CD, ensure your build environment meets these Node.js version requirements.
Astro Sessions API example code
To use Astro Sessions with Workers KV: set export const prerender = false; in your page, then access the session with: const cart = await Astro.session?.get("cart");. This retrieves stored user data like cart contents.
Astro Sessions API with Workers KV
Astro's Sessions API allows storing user data between requests (preferences, shopping carts, auth credentials). When using the Cloudflare adapter, Astro automatically configures Workers KV for session storage. Wrangler automatically provisions a KV namespace named SESSION on deployment, requiring no manual setup.
Astro prerender for specific routes
In an Astro project with on-demand rendering enabled, you can pre-render specific pages that don't need SSR by setting export const prerender = true in those page or route files. This is useful for static pages like privacy policies.
Installing Astro Cloudflare adapter for SSR
To enable on-demand rendering (SSR) in Astro, install the Cloudflare adapter by running: astro add cloudflare. This installs the adapter and updates astro.config.mjs to set output: 'server' for server rendering all pages by default.
Astro .assetsignore file for SSR deployments
When deploying an Astro project with on-demand rendering to Workers, create a .assetsignore file in the public/ folder containing: _worker.js and _routes.json. This prevents these files from being treated as static assets.
Building and deploying static Astro projects
For static Astro sites, first run: astro build to build your project, then run: wrangler@latest deploy to deploy it to Workers.
Astro static site Wrangler configuration
For a purely static Astro project, create a wrangler.json with: name, compatibility_date set to today's date, and assets.directory set to ./dist. No main field is needed since no Worker code is required for serving only static assets. Update the directory value if assets are in a different location.
Automatic Astro configuration with wrangler deploy
Running wrangler deploy in an Astro project without a Wrangler configuration file automatically detects Astro, generates the necessary configuration, and deploys the project. This uses automatic project configuration.
Astro static site generation without Cloudflare adapter
If you want to use Astro as a static site generator without on-demand rendering, you do not need the Astro Cloudflare adapter. Astro will pre-render all pages at build time by default, and you can simply upload those static assets to be served by Cloudflare.
Astro Cloudflare adapter default output configuration
The Astro Cloudflare adapter sets output: 'server' by default, which means all pages are rendered on-demand in your Cloudflare Worker rather than pre-rendered at build time.
Astro custom 404 page configuration
To serve a custom 404 page in Astro on Workers, add not_found_handling: "404-page" to the assets section of wrangler.json. Cloudflare will then serve your custom 404 page (e.g., src/pages/404.astro) when a route is not found.
Automatic Astro Wrangler configuration values
When Wrangler automatically configures an Astro project, it sets: main to dist/_worker.js/index.js, assets.directory to ./dist with binding ASSETS, compatibility_flags to nodejs_compat, observability.enabled to true, and astro.config.mjs adapter to @astrojs/cloudflare.
Astro project deployment to Workers
Deploy an Astro project to a *.workers.dev subdomain or custom domain by running: npm run deploy. This works from your local machine or any CI/CD system including Workers Builds. For CI services, update your deploy command accordingly.
Customizing Astro session KV binding name
You can customize the KV binding name for Astro sessions from the default SESSION by using the sessionKVBindingName adapter option in astro.config.mjs.
Astro Wrangler configuration for on-demand rendering
For Astro projects using on-demand rendering, create wrangler.json with: name, main set to ./dist/_worker.js/index.js, compatibility_date set to today's date, compatibility_flags set to ["nodejs_compat"], assets.binding set to ASSETS, assets.directory set to ./dist, and observability.enabled set to true.
CSS URL rewriting in microfrontends
The router rewrites CSS files to ensure url() references work correctly. For example, .hero { background: url(/assets/hero.jpg); } becomes .hero { background: url(/app-a/assets/hero.jpg); } when the microfrontend is mounted at /app-a. The router also handles redirect headers by rewriting Location headers to include the mount path, and updates Set-Cookie headers to scope cookies to the mount path.
Independent deployment of microfrontends
Each microfrontend can be deployed independently without redeploying the router or other microfrontends. This enables teams to deploy updates on their own schedule, roll back individual microfrontends without affecting others, and test and release features independently. When you deploy a microfrontend worker, the router automatically routes requests to the latest version via the service binding. No router changes are required unless you are adding new routes or updating the ROUTES configuration.
Adding a new microfrontend to router
To add a new microfrontend after initial setup: (1) Create and deploy the new microfrontend worker as a separate Worker (can be a framework application like Next.js or Astro, or a static site with Workers Static Assets), (2) Add a service binding in your router's Wrangler configuration file with binding = "MICROFRONTEND_C" and service = "my-new-microfrontend", (3) Update the ROUTES environment variable to add your new route, (4) Redeploy the router worker with npx wrangler deploy.
Smooth page transitions between microfrontends
You can enable smooth page transitions between microfrontends using the View Transitions API. To enable smooth transitions, set "smoothTransitions": true in your ROUTES configuration. The router automatically injects CSS into HTML responses with view-transition properties for .3s duration and ease-in-out timing function. This feature only works in browsers that support the View Transitions API. Browsers without support will navigate normally without animations.
Default asset prefixes in microfrontend router
The router only rewrites paths that start with configured asset prefixes to avoid breaking external URLs. The default asset prefixes are: /assets/, /static/, /build/, /_astro/, /fonts/.
HTML attributes rewritten by router
The router rewrites the following attributes across all HTML elements: href, src, poster, action, srcset, data-* attributes like data-src, data-href, data-background, and framework-specific attributes like astro-component-url. For example, <link rel="stylesheet" href="/assets/styles.css" /> becomes <link rel="stylesheet" href="/app-a/assets/styles.css" /> when mounted at /app-a.
Path rewriting behavior in microfrontends
When a request is matched to a route like /app-a, the router forwards the request to the specified microfrontend and strips the /app-a prefix, so the microfrontend receives /dashboard (for a request to /app-a/dashboard). The router uses HTMLRewriter to automatically rewrite HTML attributes to include the mount path prefix, ensuring assets load from the correct location.
Production deployment for microfrontends
To deploy to production, you can use custom domains for your router worker and configure Workers Builds for continuous deployment from your Git repository.
Microfrontend architecture with router worker
A router worker receives incoming browser requests, analyzes the request path, matches it against configured routes, and forwards the request to the appropriate microfrontend via service binding. The router rewrites HTML, CSS, and headers to ensure assets load correctly, then returns the response to the browser. Each microfrontend can be a full-framework application (Next.js, SvelteKit, Astro, etc.), a static site with Workers Static Assets, or built with different frameworks and technologies.
Microfrontends definition and use cases
Microfrontends let you split a single application into smaller, independently deployable units that render as one cohesive application. Different teams using different technologies can develop, test, and deploy each microfrontend. Use microfrontends when you want to enable many teams to deploy independently without coordinating releases, gradually migrate from a monolith to a distributed architecture, or build multi-framework applications (for example, Astro, Remix, and Next.js in one app).
Analog automatic configuration settings
When automatically configured for Cloudflare Workers, Analog projects use the following settings: main entry point at .output/server/index.mjs, assets directory at .output/public, nodejs_compat compatibility flag, and observability enabled in wrangler.jsonc.
Automatic Analog project configuration with wrangler deploy
Running 'wrangler deploy' in an Analog project without a Wrangler configuration file will automatically detect Analog, generate the necessary configuration, and deploy the project.
Deploy Analog with npm run deploy
Run 'npm run deploy' to build and deploy an Analog project to Cloudflare Workers. The project can be deployed to a *.workers.dev subdomain, a custom domain, from your own machine, or from any CI/CD system.
Develop Analog locally with npm run dev
Run 'npm run dev' in the project directory to start a local development server and preview the Analog project during development.
Create new Analog project with create-cloudflare CLI
Use the create-cloudflare CLI (C3) to set up a new Analog project. Run the command 'npm create cloudflare@latest my-analog-app --framework=analog' to create a new project directory with Analog's official setup tool and deployment options.
Analog is a fullstack meta-framework for Angular
Analog is a fullstack meta-framework for Angular, powered by Vite and Nitro. It can be deployed to Cloudflare Workers.
Deploy Angular to Cloudflare Workers
Run 'npm run deploy' to build and deploy an Angular project to Cloudflare Workers. The project can be deployed to a *.workers.dev subdomain or a custom domain from your machine or any CI/CD system.
Create Angular project with create-cloudflare
Use the create-cloudflare CLI (C3) with the command 'npm create cloudflare@latest my-angular-app --framework=angular' to set up a new Angular project configured for deployment to Cloudflare Workers with Workers Assets.
Automatic Angular project configuration with wrangler deploy
Running wrangler deploy in an Angular project without a Wrangler configuration file will automatically detect Angular, generate the necessary configuration, and deploy the project.
Angular deployment with Workers Assets
Angular applications can be deployed to Cloudflare Workers using Workers Assets. The automatic configuration for Angular projects sets the assets directory to dist/browser and enables observability.
Local development for Angular on Workers
Run 'npm run start' in the project directory to start a local development server and preview the Angular project during development.
Create Gatsby project with create-cloudflare
Use the create-cloudflare CLI (C3) to set up a new Gatsby project with Workers Assets. Run the command: npm create cloudflare@latest my-gatsby-app --framework=gatsby
Gatsby local development command
To start a local development server for a Gatsby project on Cloudflare Workers, run: npm run dev
Gatsby with Workers Assets integration
Gatsby applications can be deployed to Cloudflare Workers using Workers Assets for static asset delivery.
Gatsby deployment to Cloudflare Workers
Deploy a Gatsby project to Cloudflare Workers by running: npm run deploy. This command will build and deploy your project to a *.workers.dev subdomain or a custom domain. For CI/CD systems, update the deploy command configuration appropriately.
Deploy Docusaurus from CLI or CI/CD
Docusaurus projects can be deployed to a *.workers.dev subdomain or a custom domain from your local machine or any CI/CD system, including Workers Builds. Use the deploy command: npm run deploy
Docusaurus development server command
Start a local development server for Docusaurus by running: npm run dev
Deploy Docusaurus to Workers with Workers Assets
Docusaurus projects can be deployed to Cloudflare Workers using Workers Assets. A static Docusaurus site requires a wrangler.json configuration file with an assets field pointing to the build directory (e.g., './build'). No main field is needed in the config since only static assets are served. Deploy using: docusaurus build, then wrangler deploy.
Scaffold Docusaurus project on Workers
Use the create-cloudflare CLI (C3) to scaffold a new Docusaurus project on Workers by running: npm create cloudflare@latest my-docusaurus-app --framework=docusaurus --platform=workers. This command creates a new project directory, initiates Docusaurus' official setup tool, and configures the project for Cloudflare, with an option to instantly deploy your application.