Environments
Environments provide isolated spaces where your code runs with specific dependencies and configurations. This can be useful for a number of reasons, such as compatibility testing or version management. Using different environments can help with code consistency, testing, and production segregation, which reduces the risk of errors when deploying code.
Wrangler allows you to deploy the same Worker application with different configuration for each environment.
If you are using Wrangler environments, you must specify any Durable Object bindings you wish to use on a per-environment basis.
Durable Object bindings are not inherited. For example, you can define an environment named staging
as below:
{ "env": { "staging": { "durable_objects": { "bindings": [ { "name": "EXAMPLE_CLASS", "class_name": "DurableObjectExample" } ] } } }}
[env.staging]durable_objects.bindings = [ {name = "EXAMPLE_CLASS", class_name = "DurableObjectExample"}]
Because Wrangler appends the environment name to the top-level name when publishing, for a Worker named worker-name
the above example is equivalent to:
{ "env": { "staging": { "durable_objects": { "bindings": [ { "name": "EXAMPLE_CLASS", "class_name": "DurableObjectExample", "script_name": "worker-name-staging" } ] } } }}
[env.staging]durable_objects.bindings = [ {name = "EXAMPLE_CLASS", class_name = "DurableObjectExample", script_name = "worker-name-staging"}]
"EXAMPLE_CLASS"
in the staging environment is bound to a different Worker code name compared to the top-level "EXAMPLE_CLASS"
binding, and will therefore access different Durable Objects with different persistent storage.
If you want an environment-specific binding that accesses the same Objects as the top-level binding, specify the top-level Worker code name explicitly using script_name
:
{ "env": { "another": { "durable_objects": { "bindings": [ { "name": "EXAMPLE_CLASS", "class_name": "DurableObjectExample", "script_name": "worker-name" } ] } } }}
[env.another]durable_objects.bindings = [ {name = "EXAMPLE_CLASS", class_name = "DurableObjectExample", script_name = "worker-name"}]
Local development sessions create a standalone, local-only environment that mirrors the production environment, so that you can test your Worker and Durable Objects before you deploy to production.
An existing Durable Object binding of DB
would be available to your Worker when running locally.
Refer to Workers Local development.
KV-backed Durable Objects support remote development using the dashboard playground. The dashboard playground uses a browser version of Visual Studio Code, allowing you to rapidly iterate on your Worker entirely in your browser.
To start remote development:
- Log in to your Cloudflare dashboard, and go to Workers & Pages > Overview ↗.
- Select an existing Worker.
- Select the Edit code icon located on the upper-right of the screen.
Was this helpful?
- Resources
- API
- New to Cloudflare?
- Products
- Sponsorships
- Open Source
- Support
- Help Center
- System Status
- Compliance
- GDPR
- Company
- cloudflare.com
- Our team
- Careers
- 2025 Cloudflare, Inc.
- Privacy Policy
- Terms of Use
- Report Security Issues
- Trademark