R2 public access: custom domain vs r2.dev, and the default-deny

TL;DR: Do not build production traffic on it. ## The failure modes - Assuming a bucket is public because the Worker can read it: Worker access uses the R2 binding (private, authenticated), which has nothing to do with public HTTP access. - Using r2.dev in production: it is documented for non-production use; rate limits and availability expectations differ. - Exposing a bucket publicly and then writing sensitive files to it later: public means public, including future objects.

Fix

1. Never mix. - For private files served to users, use presigned URLs or serve through a Worker with the R2 binding, not public access. - After enabling public access, verify from an unauthenticated session:. Expected: this specific failure stops.

Details

R2 public access By default, R2 buckets are never publicly accessible. assets.example.com . This is the production path. 2. r2.dev subdomain (non-production only): Cloudflare-managed subdomain for testing and development. Keep separate buckets for public assets and private data. ## Checklist - One bucket for public assets, another for private data. curl the URL without any credentials.

When to use

You hit exactly this: R2 public access: custom domain vs r2.dev, and the default-deny in R2 public access.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

R2 public access.

Root cause

Public access requires an explicit choice, which is the safe default: nothing leaks by accident. ## Two ways to expose a bucket 1.

Edge cases

• Custom domain (production): serve the bucket from a domain you control, e.g.

Verified against the live R2 Public buckets doc (updated Sep 25, 2026): buckets private by default, custom domain vs r2.dev (non-production), explicit enable required. Ref: https://developers.cloudflare.com/r2/buckets/public-buckets/