Enable Early Hints in Cloudflare dashboard
To enable Early Hints on your zone, navigate to the Cloudflare dashboard Speed settings page, go to Content Optimization, and enable the Early Hints toggle.
Cloudflare Workers · all subjects
configuration
366 notes in this subject, read out of this brain and free to use. This is page 3 of 7.
vite.config.ts for ChatGPT App React UI
Create vite.config.ts with cloudflare plugin, react plugin, and viteSingleFile plugin. Set build.minify to false.
wrangler.jsonc configuration for ChatGPT App with Durable Objects
Configure wrangler.jsonc with: name, main pointing to src/index.ts, compatibility_date set to today, compatibility_flags including nodejs_compat, durable_objects bindings with name and class_name, migrations with tag v1 and new_sqlite_classes array, and assets directory pointing to dist with binding ASSETS.
Create ChatGPT App project
Use 'npm create cloudflare@latest my-chess-app' to create a new ChatGPT App project. Then install required dependencies: npm install agents @modelcontextprotocol/sdk chess.js react react-dom react-chessboard. Install dev dependencies: npm install -D @cloudflare/vite-plugin @vitejs/plugin-react vite vite-plugin-singlefile @types/react @types/react-dom
Enable ChatGPT Developer Mode prerequisites
To use ChatGPT Apps (also called connectors), open ChatGPT and go to Settings > Apps & Connectors > Advanced Settings, then toggle Developer mode ON. This allows you to install custom apps during development and testing.
package.json scripts for ChatGPT App
Configure package.json scripts: 'dev' runs vite, 'build' runs vite build, 'deploy' runs vite build && wrangler deploy
Connect deployed app to ChatGPT
Open ChatGPT and go to Settings > Apps & Connectors > Create. Give your app a name, optional description and icon. Enter your MCP endpoint as https://my-chess-app.YOUR_SUBDOMAIN.workers.dev/mcp. Select 'No authentication' and then 'Create'.
Build and deploy ChatGPT App
Run 'npm run build' to compile React app into a single HTML file in the dist directory. Then run 'npx wrangler deploy' to deploy to Cloudflare Workers. The deployment provides a URL like https://my-chess-app.YOUR_SUBDOMAIN.workers.dev
nodejs_compat compatibility flag required for Buffer API
To use the Node.js Buffer API in Workers for HTTP Basic Authentication, the `nodejs_compat` compatibility flag must be enabled in the Worker configuration.
Configure Cron Trigger in wrangler.toml
Set cron triggers in the wrangler configuration file using the triggers.crons array with cron syntax. Example: {"triggers": {"crons": ["0 * * * *"]}}. The cron pattern "0 * * * *" represents once per hour.
Cron Trigger configuration in wrangler environments
Cron triggers can be set per environment by placing the [triggers] table under the environment configuration in wrangler.toml. Example: {"env": {"dev": {"triggers": {"crons": ["0 * * * *"]}}}}
Cookie npm package dependency
The JavaScript cookie parsing example requires the npm package 'cookie' to be installed in your project. The Hono implementation has built-in cookie utilities and does not require external dependencies for cookie handling.
Account hash for image delivery
The account hash is a unique identifier used to proxy requests to imagedelivery.net. It can be found in the Cloudflare dashboard and looks similar to 'ZWd9g1K7eljCn_KDTu_MWA'. This hash is required when constructing image delivery URLs.
Store account hash as environment variable in Hono
When using the Hono framework, the account hash can be stored as a binding variable (environment variable) and accessed via c.env.ACCOUNT_HASH rather than hardcoding it in the Worker code.
Multiple cron triggers in wrangler.toml
You can define multiple cron triggers in wrangler.toml with different schedules. The same scheduled handler processes all triggers and uses the cron property to determine which schedule triggered the execution.
OpenAI SDK installation for Workers
To use the OpenAI SDK (v4) with Cloudflare Workers, install it using npm i openai.
Node.js Buffer API required for signing requests example
The signing requests example Worker uses the Node.js Buffer API, which is available in Workers runtime through Node.js compatibility mode. To run this Worker, enable the nodejs_compat compatibility flag.
SPA deployment with external origin configuration
When the SPA is hosted outside Cloudflare, store the external origin URL and API base URL as environment variables in wrangler.toml. Attach the Worker to a domain using Custom Domain or Route to sit in front of the external origin as a reverse proxy.
Static Assets configuration for SPA shell
When deploying an SPA built entirely on Workers using Static Assets, set the `not_found_handling` option to "single-page-application" so every route returns index.html. Use `run_worker_first` with patterns ["/*", "!/assets/*"] to route all requests through the Worker except hashed assets under /assets/*, which are served directly.
Skipping automatic configuration
To prevent automatic configuration from running, ensure you have a valid Wrangler configuration file (`wrangler.toml`, `wrangler.json`, or `wrangler.jsonc`) in your project before running `wrangler deploy`. You can also manually configure your project by following the framework-specific guides in the Framework guides documentation.
Automatic configuration workflow steps
When you run `wrangler deploy` or `wrangler setup` without a Wrangler configuration file, the process performs five steps: detect your framework, prompt for confirmation of detected settings, install any required Cloudflare adapters, generate a `wrangler.jsonc` file with appropriate settings, and update `package.json` with helpful scripts like `deploy`, `preview`, and `cf-typegen`. Git configuration is also updated with Wrangler-specific entries to `.gitignore`.
Workspace and monorepo limitations for automatic configuration
Support for monorepos and npm/yarn/pnpm workspaces is currently limited. Wrangler analyzes the project directory where you run the command but does not detect dependencies installed at the workspace root. This can cause framework detection to fail if the framework is listed as a dependency in the workspace's root `package.json` rather than in the individual project's `package.json`. If you encounter issues, report them in the Wrangler GitHub repository.
Minimum Wrangler version for automatic configuration
Automatic configuration requires Wrangler version 4.68.0 or later. Check your version by running `wrangler --version`. To update Wrangler, refer to the Install/Update Wrangler documentation.
Existing configuration prevents automatic configuration
If a Wrangler configuration file already exists, automatic configuration will not run. To reconfigure your project, delete the existing configuration file and run `wrangler deploy` or `wrangler setup` again.
Framework detection requires package.json dependency
If your framework is not detected during automatic configuration, ensure your `package.json` includes the framework as a dependency.
Multiple frameworks detected troubleshooting
When importing a repository via Workers Builds in the Cloudflare dashboard, automatic configuration fails if your project contains multiple frameworks. To resolve this, set the root directory to the path containing only one framework. For monorepos, refer to monorepo setup documentation. When running `wrangler deploy` or `wrangler setup` locally, Wrangler prompts you to select which framework to use if multiple frameworks are detected.
Dashboard import triggers automatic configuration
When you import a GitHub or GitLab repository via the Cloudflare dashboard, automatic configuration runs non-interactively. If your repository does not have a Wrangler configuration file, Workers Builds will create a pull request with the necessary configuration. The PR includes all configuration changes and a preview deployment for testing before merging.
Non-interactive mode for automatic configuration
Use the `--yes` flag with `wrangler deploy --yes` to skip confirmation prompts and apply configuration automatically using sensible defaults. This is useful in CI/CD environments or when you want to accept detected settings without reviewing them.
Automatic configuration dry run with --dry-run flag
Run `wrangler setup --dry-run` to see what changes would be made without actually modifying any files. This outputs a summary of the configuration that would be generated.
.assetsignore file for worker output exclusion
For frameworks that generate worker files in the output directory, automatic configuration creates an `.assetsignore` file to exclude them from static asset uploads. The file contains: `_worker.js` and `_routes.json`.
Generated .gitignore entries from automatic configuration
Automatic configuration adds Wrangler-specific entries to `.gitignore`: `.wrangler`, `.dev.vars*`, and `!.dev.vars.example`. The last entry ensures `.dev.vars.example` is tracked in git.
Generated package.json scripts from automatic configuration
Automatic configuration adds three scripts to `package.json`: `"deploy": "npm run build && wrangler deploy"`, `"preview": "npm run build && wrangler dev"`, and `"cf-typegen": "wrangler types"`.
Generated wrangler.jsonc configuration example
Automatic configuration creates a `wrangler.jsonc` file with framework-appropriate settings. Example configuration includes: `"$schema": "node_modules/wrangler/config-schema.json"`, `"name": "my-project"`, `"main": "dist/_worker.js/index.js"`, `"compatibility_date": "$today"`, `"compatibility_flags": ["nodejs_compat"]`, `"assets": {"binding": "ASSETS", "directory": "dist"}`, `"observability": {"enabled": true}`. The exact configuration varies based on your framework.
ASSET_PREFIXES configuration for custom frameworks
Most frameworks work with the default asset prefixes. For frameworks with different build outputs (like Next.js which uses /_next/), you can configure custom prefixes using the ASSET_PREFIXES environment variable. Example: ["/_next/", "/public/"]
Angular assets directory configuration
Angular projects configured for Cloudflare Workers use the assets directory set to 'dist/browser' in the wrangler.jsonc configuration file.
Wrangler configuration for Docusaurus static site
For a static Docusaurus site, create a wrangler.json configuration with the following structure: { "name": "my-docusaurus-app", "compatibility_date": "<date>", "assets": { "directory": "./build" } } The assets.directory field points to where Docusaurus builds the static site. If your assets are in a different directory, update the directory value accordingly.
Waku wrangler.jsonc automatic configuration
Wrangler automatically configures Waku projects with the following settings: main entry point set to dist/worker.js, assets directory set to dist/public, compatibility_flags set to nodejs_compat, and observability enabled set to true.
Manual Next.js Wrangler configuration
For manual configuration of a Next.js project on Cloudflare Workers, create a wrangler.jsonc file with: main set to .open-next/worker.js, compatibility_date set to 2024-09-23 or later, compatibility_flags must include nodejs_compat, and assets configuration with directory set to .open-next/assets and binding set to ASSETS.
nodejs_compat flag requirement for Next.js
The nodejs_compat compatibility flag must be enabled in wrangler configuration for Next.js apps to work with @opennextjs/cloudflare. The compatibility_date must be set to 2024-09-23 or later.
Automatic wrangler.jsonc configuration for React Router
When Wrangler auto-detects React Router, it automatically configures: main pointing to build/server/index.js; assets directory pointing to build/client; compatibility_flags set to nodejs_compat; and observability set to enabled.
wrangler.jsonc main entry point
In wrangler.jsonc, the main field points to worker/index.ts, which contains the Worker backend API that handles requests.
Vike wrangler.jsonc configuration
A Vike project requires the following wrangler.jsonc configuration: main set to 'virtual:photon:cloudflare:server-entry', compatibility_date set to a date like '2025-08-06', name field with the project name, and compatibility_flags including 'nodejs_compat' if the app depends on Node.js APIs.
TypeScript types generation for Vike Cloudflare projects
When changing Cloudflare configuration in a Vike TypeScript project, run `wrangler types` to update the worker-configuration.d.ts file. Add 'types': ['./worker-configuration.d.ts'] to tsconfig.json compilerOptions to ensure TypeScript loads the generated types.
Dashboard: Create application options
When creating a new application in the dashboard, you can select from the gallery of production-ready templates, import an existing Git repository on your own account, or let Cloudflare clone and bootstrap a public repository containing a Workers application.
Deploying changes after local development
After making changes locally, deploy them by committing to git using 'git add .', 'git commit -m "your message"', then pushing to your Git provider with 'git push origin main'.
Dashboard: Workers & Pages location
To create a new Workers application via the dashboard, navigate to the Workers & Pages page in the Cloudflare dashboard.
Local development after dashboard setup
Applications started in the dashboard are set up with Git to help kickstart development. To continue developing, clone the repository locally using git clone, navigate to the root directory, then use Wrangler in your local development environment to preview and test changes.
Dashboard deployment: Default domain
Once deployed via the dashboard, a Worker is automatically accessible at a workers.dev subdomain provided by Cloudflare.
Dashboard: Git integration setup
After connecting to a Git provider and configuring your project, selecting Deploy will kick off a new build and deployment. The Worker is then accessible at its provided workers.dev subdomain.
Wrangler CLI capabilities
Wrangler is the Workers command-line interface that lets you create, test, and deploy your Workers projects. C3 installs Wrangler in Workers projects by default.
C3 generated project files
C3 generates the following files in a new Worker project: wrangler.jsonc (Wrangler configuration file), src/index.js (minimal 'Hello World!' Worker in ES module syntax), package.json (Node dependencies configuration), package-lock.json (npm lock file), and node_modules directory.
Deploy Worker with Wrangler
Deploy a Worker via Wrangler to a *.workers.dev subdomain or a Custom Domain by running 'npx wrangler deploy'. If you have not configured any subdomain or domain, Wrangler will prompt you during the publish process to set one up. The Worker is then accessible at <YOUR_WORKER>.<YOUR_SUBDOMAIN>.workers.dev.
Create Worker from existing Git repository
To create a new Worker project from an existing Git repository, run 'npm create cloudflare@latest -- --template <SOURCE>'. SOURCE can be: user/repo (GitHub), git@github.com:user/repo, https://github.com/user/repo, user/repo/some-template (subdirectories), user/repo#canary (branches), user/repo#1234abcd (commit hash), bitbucket:user/repo (Bitbucket), or gitlab:user/repo (GitLab). The existing template folder must contain at minimum: package.json, wrangler.jsonc, and src/ directory with a worker script referenced from wrangler.jsonc.
Upgrade pywrangler CLI
To upgrade pywrangler globally, run: uv tool upgrade workers-py. To upgrade pywrangler in a specific project, run: uv lock --upgrade-package workers-py
Type hints and autocompletion for Python Workers
The workers-runtime-sdk package provides type hints and autocompletion support for Python Workers. It can be installed manually by adding it to pyproject.toml dependencies. Types can be generated based on Worker configuration using the command: uv run pywrangler types. This generates Env types based on bindings, module rules, and runtime types based on compatibility_date and compatibility_flags.
Wrangler configuration for Python Workers
Python Workers require the compatibility_flags field in wrangler.jsonc set to ["python_workers"] and a main field pointing to the entry point file (e.g., "src/entry.py"). Example configuration: { "$schema": "./node_modules/wrangler/config-schema.json", "name": "hello-python-worker", "main": "src/entry.py", "compatibility_flags": ["python_workers"], "compatibility_date": "<today>", "vars": {"API_HOST": "example.com"} }
Access environment variables and bindings in Python Workers
Environment variables, secrets, and bindings are accessed via the env attribute on the WorkerEntrypoint instance. Variables defined in the Wrangler configuration file's vars section can be accessed as self.env.VARIABLE_NAME within the fetch handler.
Python and Pyodide version release cycle
A new version of Python is released every year in August. A new version of Pyodide is released six months later. When a new Pyodide version is published, it is added to Workers gated behind a Compatibility Flag enabled after a specified Compatibility Date.
Wrangler configuration for Python Workers
Python Workers require a Wrangler configuration file with a main field pointing to the .py file, a compatibility_date field, and a name field. Example: {"name": "hello-world-python-worker", "main": "src/entry.py", "compatibility_date": "$today"}
python_workers compatibility flag required
While Python Workers are in open beta, you must add the python_workers compatibility flag to your Worker configuration.