cloudflare/workers-sdk @cloudflare/vite-plugin@1.53.0 on GitHub

Minor Changes

#15026 6529f0c Thanks @petebacondarwin! - Allow containers to be attached to a Durable Object from its exports entry
A container can now be linked to its Durable Object from the export side, using a new container field that names an entry in the containers array. As a result containers[].class_name is now optional — a container that is referenced this way only needs a name:
```
{
  "name": "my-worker",
  "main": "worker.js",
  "compatibility_date": "2026-07-01",
  "containers": [
    { "name": "my-container", "image": "./Dockerfile", "max_instances": 1 }
  ],
  "exports": {
    "MyContainerDO": {
      "type": "durable-object",
      "storage": "sqlite",
      "container": "my-container"
    }
  }
}
```
The existing containers[].class_name direction keeps working and either direction may be used, but the two must agree: a container that names its Durable Object cannot also be claimed by a different one.
container is only valid on live durable-object exports (created and expecting-transfer) and requires storage: "sqlite". Wrangler now also reports an error when:
- a container reference names a container that does not exist
- two Durable Object exports claim the same container
- a container and a Durable Object export disagree about which one they are linked to
- a container ends up linked to no Durable Object at all
- two containers share a name
- a container's class_name names a Durable Object whose storage is legacy-kv
- two containers are attached to the same Durable Object
That last case was previously accepted but could never work: workerd attaches a single container per Durable Object namespace, and in local development every container for a class builds into the same image tag, so one silently overwrote the other. If you have two containers on one class_name, give each its own Durable Object class.

Patch Changes

#15238 3a4fc6b Thanks @jamesopstad! - Honor access.dev when running Workers with @cloudflare/vite-plugin, so ctx.access.getIdentity() returns the configured identity.
#15028 d4f441f Thanks @harshmathurx! - Handle Worker-side request body cancellation without surfacing stream controller errors in local dev.
#15185 1f79ace Thanks @jamesopstad! - Use a fixed default compatibility date rather than the current date
When no compatibility date was set, Wrangler, C3 and the Vitest pool all defaulted to the current date. workerd only accepts a compatibility date up to 7 days beyond its own release, so whenever a workerd release was delayed the default could get ahead of the runtime that had been installed, and local development would fail to start.
The default is now fixed at the release date of the workerd version that ships with each release, which leaves a week of headroom and updates as workerd is upgraded. @cloudflare/vite-plugin previously inlined the date at which it was built. It now shares the same default.
#15239 f431166 Thanks @jamesopstad! - Prevent date-enabled Node.js compatibility from adding conflicting globals to generated runtime types
Runtime type generation now treats Node.js compatibility enabled by a compatibility date the same way as an explicit nodejs_compat flag. Node.js globals continue to come from @types/node instead of being generated as any declarations that override those types.
#15196 8fb2b87 Thanks @skepticfx! - Use the FedRAMP High managed container registry when Wrangler targets the FedRAMP High compliance region
Container builds, pushes, deployments, image commands, and local development now select the corresponding production or staging FedRAMP registry and API from either compliance_region or CLOUDFLARE_COMPLIANCE_REGION.
Updated dependencies [bc5726b, 1277a72, ba54f0d, 6529f0c, b7422b0, 186339c, 4f922dc, 4d74b8d, 2e0c962, 1f79ace, 49f73de, 7cee278, 8777180, 265256a, 1f79ace, f431166, 8fb2b87, 75cf407]:
- wrangler@4.124.0
- miniflare@5.20260815.0-alpha