Configuration

Caution

If your project contains an existing wrangler.toml file that you previously used for local development, make sure you verify that it matches your project settings in the Cloudflare dashboard before opting-in to deploy your Pages project with wrangler.toml. Instead of writing your wrangler.toml file by hand, Cloudflare recommends using npx wrangler pages download config to download your current project settings into a wrangler.toml file.

Pages Functions can be configured two ways, either via the Cloudflare dashboard or wrangler.toml, a configuration file used to customize the development and deployment setup for Workers and Pages Functions.

This page serves as a reference on how to configure your Pages project via wrangler.toml.

If using wrangler.toml, you must treat your wrangler.toml as the source of truth for your Pages project configuration.

Configuration via wrangler.toml is in open beta.

Cloudflare welcomes your feedback. Join the #functions channel in the Cloudflare Developers Discord to report bugs and request features.

Using wrangler.toml to configure your Pages project allows you to:

• Store your configuration file in source control: Keep your configuration in your repository alongside the rest of your code.
• Edit your configuration via your code editor: Remove the need to switch back and forth between interfaces.
• Write configuration that is shared across environments: Define configuration like bindings for local development, preview and production in one file.
• Ensure better access control: By using a configuration file in your project repository, you can control who has access to make changes without giving access to your Cloudflare dashboard.

Example wrangler.toml file

name = "my-pages-app"
pages_build_output_dir = "./dist"

[[kv_namespaces]]
binding = "KV"
id = "<NAMESPACE_ID>"

[[d1_databases]]
binding = "DB"
database_name = "northwind-demo"
database_id = "<DATABASE_ID>"

[vars]
API_KEY = "1234567asdf"

Requirements

V2 build system

Pages Functions configuration via wrangler.toml requires the V2 build system or later. To update from V1, refer to the V2 build system migration instructions.

Wrangler

You must have Wrangler version 3.45.0 or higher to use wrangler.toml for your Pages project’s configuration. To check your Wrangler version, update Wrangler or install Wrangler, refer to Install/Update Wrangler.

Migrate from dashboard configuration

The migration instructions for Pages projects that do not have a wrangler.toml file currently are different than those for Pages projects with an existing wrangler.toml file. Read the instructions based on your situation carefully to avoid errors in production.

Projects with existing wrangler.toml file

Before you could use wrangler.toml to define your preview and production configuration, it was possible to use wrangler.toml to define which bindings should be available to your Pages project in local development.

If you have been using wrangler.toml for local development, you may already have a file in your Pages project that looks like this:

[[kv_namespaces]]
binding = "KV"
id = "<NAMESPACE_ID>"

If you would like to use your existing wrangler.toml file for your Pages project configuration, you must:

1. Add the pages_build_output_dir key with the appropriate value of your build output directory (for example, pages_build_output_dir = "./dist".)
2. Review your existing wrangler.toml configuration carefully to make sure it aligns with your desired project configuration before deploying.

If you add the pages_build_output_dir key to wrangler.toml and deploy your Pages project, Pages will use whatever configuration was defined for local use, which is very likely to be non-production. Do not deploy until you are confident that your wrangler.toml is ready for production use.

Overwriting configuration

Running wrangler pages download config will overwrite your existing wrangler.toml file with a generated wrangler.toml file based on your Cloudflare dashboard configuration. Run this command only if you want to discard your previous wrangler.toml file that you used for local development and start over with configuration pulled from the Cloudflare dashboard.

You can continue to use your wrangler.toml file for local development without migrating it for production use by not adding a pages_build_output_dir key. If you do not add a pages_build_output_dir key and run wrangler pages deploy, you will see a warning message telling you that fields are missing and that the file will continue to be used for local development only.

Projects without existing wrangler.toml file

If you have an existing Pages project with configuration set up via the Cloudflare dashboard and do not have an existing wrangler.toml file in your Project, run the wrangler pages download config command in your Pages project directory. The wrangler pages download config command will download your existing Cloudflare dashboard configuration and generate a valid wrangler.toml file in your Pages project directory.

npm

$ npx wrangler pages download config <PROJECT_NAME>

yarn

$ yarn wrangler pages download config <PROJECT_NAME>

pnpm

$ pnpm wrangler pages download config <PROJECT_NAME>

Review your generated wrangler.toml file. To start using wrangler.toml for your Pages project’s configuration, create a new deployment, via Git integration or Direct Upload.

Handling compatibility dates set to “Latest”

In the Cloudflare dashboard, you can set compatibility dates for preview deployments to “Latest”. This will ensure your project is always using the latest compatibility date without the need to explicitly set it yourself.

If you download a wrangler.toml from a project configured with “Latest” using the wrangler pages download command, your wrangler.toml will have the latest compatibility date available at the time you downloaded the configuration file. Wrangler does not support the “Latest” functionality like the dashboard. Compatibility dates must be explicitly set when using wrangler.toml.

Refer to this guide for more information on what compatibility dates are and how they work.

Differences using wrangler.toml for Pages Functions and Workers

If you have used Workers, you may already be familiar with wrangler.toml. There are a few key differences to be aware of when using wrangler.toml with your Pages Functions project:

• The configuration fields do not match exactly between Pages Functions wrangler.toml file and the Workers equivalent. For example, configuration keys like main, which are Workers specific, do not apply to a Pages Function’s wrangler.toml.
• The Pages wrangler.toml introduces a new key, pages_build_output_dir, which is only used for Pages projects.
• The concept of environments and configuration inheritance in this file is not the same as Workers.
• This file becomes the source of truth when used, meaning that you can not edit the same fields in the dashboard once you are using this file.

Configure environments

With wrangler.toml you can quickly set configuration across your local environment, preview deployments, and production.

Local development

wrangler.toml works locally when using wrangler pages dev. This means that you can test out configuration changes quickly without a need to login to the Cloudflare dashboard. Refer to the following config file for an example:

name = "my-pages-app"
pages_build_output_dir = "./dist"
compatibility_date = "2023-10-12"
compatibility_flags = ["nodejs_compat"]

[[kv_namespaces]]
binding = "KV"
id = "<NAMESPACE_ID>"

This wrangler.toml configuration file adds the nodejs_compat compatibility flag and a KV namespace binding to your Pages project. Running wrangler pages dev in a Pages project directory with this wrangler.toml configuration file will apply the nodejs_compat compatibility flag locally, and expose the KV binding in your Pages Function code at context.env.KV.

Note

For a full list of configuration keys, refer to inheritable keys and non-inheritable keys.

Production and preview deployments

Once you are ready to deploy your project, you can set the configuration for production and preview deployments by creating a new deployment containing a wrangler.toml file.

Note

For the following commands, if you are using git it is important to remember the branch that you set as your production branch as well as your preview branch settings.

To use the example above as your configuration for production, make a new production deployment using:

$ npx wrangler pages deploy

or more specifically:

$ npx wrangler pages deploy --branch <PRODUCTION BRANCH>

To deploy the configuration for preview deployments, you can run the same command as above while on a branch you have configured to work with preview deployments. This will set the configuration for all preview deployments, not just the deployments from a specific branch. Pages does not currently support branch-based configuration.

Note

The --branch flag is optional with wrangler pages deploy. If you use git integration, Wrangler will infer the branch you are on from the repository you are currently in and implicitly add it to the command.

Environment-specific overrides

There are times that you might want to use different configuration across local, preview deployments, and production. It is possible to override configuration for production and preview deployments by using [env.production] or [env.preview].

Note

Unlike Workers Environments, production and preview are the only two options available via [env.<ENVIRONMENT>].

Refer to the following wrangler.toml configuration file for an example of how to override preview deployment configuration:

name = "my-pages-site"
pages_build_output_dir = "./dist"

[[kv_namespaces]]
binding = "KV"
id = "<NAMESPACE_ID>"

[vars]
API_KEY = "1234567asdf"

[[env.preview.kv_namespaces]]
binding = "KV"
id = "<PREVIEW_NAMESPACE_ID>"

[env.preview.vars]
API_KEY = "8901234bfgd"

If you deployed this file via wrangler pages deploy, name, pages_build_output_dir, kv_namespaces, and vars would apply the configuration to local and production, while env.preview would override kv_namespaces and vars for preview deployments.

If you wanted to have configuration values apply to local and preview, but override production, your file would look like this:

name = "my-pages-site"
pages_build_output_dir = "./dist"

[[kv_namespaces]]
binding = "KV"
id = "<NAMESPACE_ID>"

[vars]
API_KEY = "1234567asdf"

[[env.production.kv_namespaces]]
binding = "KV"
id = "<PRODUCTION_NAMESPACE_ID>"

[env.production.vars]
API_KEY = "8901234bfgd"

You can always be explicit and override both preview and production:

name = "my-pages-site"
pages_build_output_dir = "./dist"

[[kv_namespaces]]
binding = "KV"
id = "<NAMESPACE_ID>"

[vars]
API_KEY = "1234567asdf"

[[env.preview.kv_namespaces]]
binding = "KV"
id = "<PREVIEW_NAMESPACE_ID>"

[env.preview.vars]
API_KEY = "8901234bfgd"

[[env.production.kv_namespaces]]
binding = "KV"
id = "<PRODUCTION_NAMESPACE_ID>"

[env.production.vars]
API_KEY = "6567875fvgt"

Inheritable keys

Inheritable keys are configurable at the top-level, and can be inherited (or overridden) by environment-specific configuration.

• name string required

  • The name of your Pages project. Alphanumeric and dashes only.

• pages_build_output_dir string required

  • The path to your project’s build output folder. For example: ./dist.

• compatibility_date string required

  • A date in the form yyyy-mm-dd, which will be used to determine which version of the Workers runtime is used. Refer to Compatibility dates.

• compatibility_flags string[] optional

  • A list of flags that enable features from upcoming features of the Workers runtime, usually used together with compatibility_date. Refer to compatibility dates.

• send_metrics boolean optional

  • Whether Wrangler should send usage metrics to Cloudflare for this project.

• limits Limits optional

  • Configures limits to be imposed on execution at runtime. Refer to Limits.

• placement Placement optional

  • Specify how Pages Functions should be located to minimize round-trip time. Refer to Smart Placement.

• upload_source_maps boolean

  • When upload_source_maps is set to true, Wrangler will upload any server-side source maps part of your Pages project to give corrected stack traces in logs.

Non-inheritable keys

Non-inheritable keys are configurable at the top-level, but, if any one non-inheritable key is overridden for any environment (for example,[[env.production.kv_namespaces]]), all non-inheritable keys must also be specified in the environment configuration and overridden.

For example, this configuration will not work:

name = "my-pages-site"
pages_build_output_dir = "./dist"

[[kv_namespaces]]
binding = "KV"
id = "<NAMESPACE_ID>"

[vars]
API_KEY = "1234567asdf"

[env.production.vars]
API_KEY = "8901234bfgd"

[[env.production.vars]] is set to override [vars]. Because of this [[kv_namespaces]] must also be overridden by defining [[env.production.kv_namespaces]].

This will work for local development, but will fail to validate when you try to deploy.

• vars object optional

  • A map of environment variables to set when deploying your Function. Refer to Environment variables.

• d1_databases object optional

  • A list of D1 databases that your Function should be bound to. Refer to D1 databases.

• durable_objects object optional

  • A list of Durable Objects that your Function should be bound to. Refer to Durable Objects.

• hyperdrive object optional

  • Specifies Hyperdrive configs that your Function should be bound to. Refer to Hyperdrive.

• kv_namespaces object optional

  • A list of KV namespaces that your Function should be bound to. Refer to KV namespaces.

• queues.producers object optional

  • Specifies Queues Producers that are bound to this Function. Refer to Queues Producers.

• r2_buckets object optional

  • A list of R2 buckets that your Function should be bound to. Refer to R2 buckets.

• vectorize object optional

  • A list of Vectorize indexes that your Function should be bound to. Refer to Vectorize indexes.

• services object optional

  • A list of service bindings that your Function should be bound to. Refer to service bindings.

• analytics_engine_datasets object optional

  • Specifies analytics engine datasets that are bound to this Function. Refer to Workers Analytics Engine.

• ai object optional

  • Specifies an AI binding to this Function. Refer to Workers AI.

Limits

You can configure limits for your Pages project in the same way you can for Workers. Read this guide for more details.

Bindings

A binding enables your Pages Functions to interact with resources on the Cloudflare Developer Platform. Use bindings to integrate your Pages Functions with Cloudflare resources like KV, Durable Objects, R2, and D1. You can set bindings for both production and preview environments.

D1 databases

D1 is Cloudflare’s serverless SQL database. A Function can query a D1 database (or databases) by creating a binding to each database for D1’s client API.

Note

When using Wrangler in the default local development mode, files will be written to local storage instead of the preview or production database. Refer to Local development for more details.

• Configure D1 database bindings via your wrangler.toml file the same way they are configured with Cloudflare Workers.
• Interact with your D1 Database binding.

Durable Objects

Durable Objects provide low-latency coordination and consistent storage for the Workers platform.

• Configure Durable Object namespace bindings via your wrangler.toml file the same way they are configured with Cloudflare Workers.

Caution

You must create a Durable Object Worker and bind it to your Pages project using the Cloudflare dashboard or your Pages project’s wrangler.toml. You cannot create and deploy a Durable Object within a Pages project.

Durable Object bindings configured in a Pages project’s wrangler.toml require the script_name key. For Workers, the script_name key is optional.

• Interact with your Durable Object namespace binding.

Environment variables

Environment variables are a type of binding that allow you to attach text strings or JSON values to your Pages Function.

• Configure environment variables via your wrangler.toml file the same way they are configured with Cloudflare Workers.
• Interact with your environment variables.

Hyperdrive

Hyperdrive bindings allow you to interact with and query any Postgres database from within a Pages Function.

• Configure Hyperdrive bindings via your wrangler.toml file the same way they are configured with Cloudflare Workers.

KV namespaces

Workers KV is a global, low-latency, key-value data store. It stores data in a small number of centralized data centers, then caches that data in Cloudflare’s data centers after access.

Note

When using Wrangler in the default local development mode, files will be written to local storage instead of the preview or production namespace. Refer to Local development for more details.

• Configure KV namespace bindings via your wrangler.toml file the same way they are configured with Cloudflare Workers.
• Interact with your KV namespace binding.

Queues Producers

Queues is Cloudflare’s global message queueing service, providing guaranteed delivery and message batching. Queue Producers enable you to send messages into a queue within your Pages Function.

Note

You cannot currently configure a queues consumer with Pages Functions.

• Configure Queues Producer bindings via your wrangler.toml file the same way they are configured with Cloudflare Workers.
• Interact with your Queues Producer binding.

R2 buckets

Cloudflare R2 Storage allows developers to store large amounts of unstructured data without the costly egress bandwidth fees associated with typical cloud storage services.

Note

When using Wrangler in the default local development mode, files will be written to local storage instead of the preview or production bucket. Refer to Local development for more details.

• Configure R2 bucket bindings via your wrangler.toml file the same way they are configured with Cloudflare Workers.
• Interact with your R2 bucket bindings.

Vectorize indexes

A Vectorize index allows you to insert and query vector embeddings for semantic search, classification and other vector search use-cases.

• Configure Vectorize bindings via your wrangler.toml file the same way they are configured with Cloudflare Workers.

Service bindings

A service binding allows you to call a Worker from within your Pages Function. Binding a Pages Function to a Worker allows you to send HTTP requests to the Worker without those requests going over the Internet. The request immediately invokes the downstream Worker, reducing latency as compared to a request to a third-party service. Refer to About Service bindings.

• Configure service bindings via your wrangler.toml file the same way they are configured with Cloudflare Workers.
• Interact with your service bindings.

Analytics Engine Datasets

Workers Analytics Engine provides analytics, observability and data logging from Pages Functions. Write data points within your Pages Function binding then query the data using the SQL API.

• Configure Analytics Engine Dataset bindings via your wrangler.toml file the same way they are configured with Cloudflare Workers.
• Interact with your Analytics Engine Dataset.

Workers AI

Workers AI allows you to run machine learning models, on the Cloudflare network, from your own code – whether that be from Workers, Pages, or anywhere via REST API.

Workers AI local development usage charges

Using Workers AI always accesses your Cloudflare account in order to run AI models and will incur usage charges even in local development.

Unlike other bindings, this binding is limited to one AI binding per Pages Function project.

• Configure Workers AI bindings via your wrangler.toml file the same way they are configured with Cloudflare Workers.
• Interact with your Workers AI binding.

Local development settings

The local development settings that you can configure are the same for Pages Functions and Cloudflare Workers. Read this guide for more details.

Source of truth

When used in your Pages Functions projects, your wrangler.toml file is the source of truth. You will be able to see, but not edit, the same fields when you log into the Cloudflare dashboard.

If you decide that you don’t want to use wrangler.toml for configuration, you can safely delete it and create a new deployment. Configuration values from your last deployment will still apply and you will be able to edit them from the dashboard.