Skip to content

changelog: add Workers Terraform, API, and Smart Placement fixes #22149

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 7, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
---
title: Dozens of Cloudflare Terraform Provider resources now have proper drift detection
description: Improper drift detection in the Cloudflare Terraform Provider resulted in dozens of resources always indicating they needed to be updated or replaced.
products:
- fundamentals
date: 2025-03-21T00:00:00Z
---

In [Cloudflare Terraform Provider](https://github.com/cloudflare/terraform-provider-cloudflare) versions 5.2.0 and above, dozens of resources now have proper drift detection. Before this fix, these resources would indicate they needed to be updated or replaced — even if there was no real change. Now, you can rely on your `terraform plan` to only show what resources are expected to change.

This issue affected [resources](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs) related to these products and features:

- API Shield
- Argo Smart Routing
- Argo Tiered Caching
- Bot Management
- BYOIP
- D1
- DNS
- Email Routing
- Hyperdrive
- Observatory
- Pages
- R2
- Rules
- SSL/TLS
- Waiting Room
- Workers
- Zero Trust
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
---
title: Cloudflare Terraform Provider now properly redacts sensitive values
description: Resources in the Cloudflare Terraform Provider that have sensitive properties will not show those values in logs.
products:
- fundamentals
date: 2025-03-21T00:00:00Z
---

In the [Cloudflare Terraform Provider](https://github.com/cloudflare/terraform-provider-cloudflare) versions 5.2.0 and above, sensitive properties of resources are redacted in logs. Sensitive properties in [Cloudflare's OpenAPI Schema](https://raw.githubusercontent.com/cloudflare/api-schemas/refs/heads/main/openapi.yaml) are now annotated with `x-sensitive: true`. This results in proper auto-generation of the corresponding Terraform resources, and prevents sensitive values from being shown when you run Terraform commands.

This issue affected [resources](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs) related to these products and features:

- Alerts and Audit Logs
- Device API
- DLP
- DNS
- Magic Visibility
- Magic WAN
- TLS Certs and Hostnames
- Tunnels
- Turnstile
- Workers
- Zaraz
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
---
title: Smart Placement is smarter about running Workers and Pages Functions in the best locations
description: Workers and Pages Functions with Smart Placement enabled will not unexpectedly return to default locations if request traffic dips.
products:
- workers
- pages
date: 2025-03-22T00:00:00Z
---

[Smart Placement](/workers/configuration/smart-placement/) is a unique Cloudflare feature that can make decisions to move your Worker to run in a more optimal location (such as closer to a database). Instead of always running in the default location (the one closest to where the request is received), Smart Placement uses certain “heuristics” (rules and thresholds) to decide if a different location might be faster or more efficient.

Previously, if these heuristics weren't consistently met, your Worker would revert to running in the default location—even after it had been optimally placed. This meant that if your Worker received minimal traffic for a period of time, the system would reset to the default location, rather than remaining in the optimal one.

Now, once Smart Placement has identified and assigned an optimal location, temporarily dropping below the heuristic thresholds will not force a return to default locations. For example in the previous algorithm, a drop in requests for a few days might return to default locations and heuristics would have to be met again. This was problematic for workloads that made requests to a geographically located resource every few days or longer. In this scenario, your Worker would never get placed optimally. This is no longer the case.
60 changes: 60 additions & 0 deletions src/content/changelog/workers/2025-04-15-workers-api-fixes.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
---
title: Fixed and documented Workers Routes and Secrets API
description: The Workers Routes API now returns a correct response and the Secrets API has been added to the Cloudflare API docs.
products:
- workers
- workers-for-platforms
date: 2025-04-15T00:00:00Z
---

## Workers Routes API

Previously, a request to the Workers [Create Route API](/api/resources/workers/subresources/routes/methods/create/) always returned `null` for "script" and an empty string for "pattern" even if the request was successful.

```bash title="Example request"
curl https://api.cloudflare.com/client/v4/zones/$CF_ACCOUNT_ID/workers/routes \
-X PUT \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H 'Content-Type: application/json' \
--data '{ "pattern": "example.com/*", "script": "hello-world-script" }'
```

```json title="Example bad response"
{
"result": {
"id": "bf153a27ba2b464bb9f04dcf75de1ef9",
"pattern": "",
"script": null,
"request_limit_fail_open": false
},
"success": true,
"errors": [],
"messages": []
}
```

Now, it properly returns all values!

```json title="Example good response"
{
"result": {
"id": "bf153a27ba2b464bb9f04dcf75de1ef9",
"pattern": "example.com/*",
"script": "hello-world-script",
"request_limit_fail_open": false
},
"success": true,
"errors": [],
"messages": []
}
```

## Workers Secrets API

The [Workers](/api/resources/workers/subresources/scripts/subresources/secrets/) and [Workers for Platforms](/api/resources/workers_for_platforms/subresources/dispatch/subresources/namespaces/subresources/scripts/subresources/secrets/) secrets APIs are now properly documented in the Cloudflare OpenAPI docs. Previously, these endpoints were not publicly documented, leaving users confused on how to directly manage their secrets via the API. Now, you can find the proper endpoints in our public documentation, as well as in our API Library SDKs such as [cloudflare-typescript](https://github.com/cloudflare/cloudflare-typescript) (>4.2.0) and [cloudflare-python](https://github.com/cloudflare/cloudflare-python) (>4.1.0).

Note the `cloudflare_workers_secret` and `cloudflare_workers_for_platforms_script_secret` [Terraform resources](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs) are being removed in a future release. This resource is not recommended for managing secrets. Users should instead use the:

- [Secrets Store](/api/resources/secrets_store/) with the "Secrets Store Secret" binding on Workers and Workers for Platforms Script Upload
- "Secret Text" Binding on [Workers Script Upload](/api/resources/workers/subresources/scripts/methods/update/) and [Workers for Platforms Script Upload](/api/resources/workers_for_platforms/subresources/dispatch/subresources/namespaces/subresources/scripts/methods/update/)
- Workers (and WFP) Secrets API