Configuration via wrangler.toml

Pages Functions can be configured two ways, either via the Cloudflare dashboard Open external link 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.

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

wrangler.toml
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:

wrangler.toml
[[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.

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.

$ npx wrangler pages download config <PROJECT_NAME>

$ yarn wrangler pages download config <PROJECT_NAME>

$ 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:

wrangler.toml
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.

​​ 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.

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.

​​ 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].

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

wrangler.toml
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:

wrangler.toml
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:

wrangler.toml
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.

​​ 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:

wrangler.toml
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.

​​ 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.

• 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.

• 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.

• 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.

• 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.

• 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.

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.