R2 Local Uploads: Cutting Cross-Region Upload Latency
Cloudflare has launched Local Uploads for R2 object storage in open beta. The feature automatically writes object data to storage infrastructure nearest the client first, then asynchronously replicates that data to the bucket's home region. Objects become immediately accessible with strong consistency — there's no waiting period for background replication to complete before reads can occur.
The motivation is straightforward: data must live somewhere, but uploads from distant regions traditionally pay the full network cost of crossing that distance. R2 already caches data globally for fast reads; Local Uploads extends similar performance benefits to writes.
Performance Gains in Testing
In benchmark tests simulating cross-region uploads, Cloudflare saw up to a 75% reduction in Time to Last Byte (TTLB) — measured from when R2 receives the request to when it returns a 200 response. The synthetic workload used a client in Western North America uploading 5 MB objects at roughly 20 PutObject requests per second to a bucket location-hinted for Asia-Pacific. Median TTLB dropped from around 2 seconds without Local Uploads to approximately 500 milliseconds with it enabled.
Understanding the Upload Path
R2's architecture has three main components:
- R2 Gateway Worker: The entry point for all API requests, handling authentication and routing, deployed globally via Cloudflare Workers.
- Durable Object Metadata Service: A distributed layer built on Durable Objects that stores and manages object metadata like keys and checksums.
- Distributed Storage Infrastructure: The physical layer that persistently stores encrypted object data.
Without Local Uploads, a standard upload flow works like this: the Gateway Worker authenticates the request near the user, then the client's data bytes are encrypted and streamed directly into storage in the bucket's home region. Only after that write completes does the Gateway publish metadata and return success. When client and bucket are geographically distant, that long-haul data path introduces latency and variability.
What Changes with Local Uploads
With Local Uploads enabled, the system checks whether the client is in the same region as the bucket:
- Same region: R2 follows the regular flow, writing data to the bucket's storage infrastructure.
- Different region: R2 writes to storage in the client's region while publishing object metadata to the bucket's home region.
In the second case, the object is readable immediately after the initial write. Background replication then copies the data to the bucket's home region. This applies only to buckets without jurisdiction restrictions (e.g., EU, FedRAMP); those buckets don't support Local Uploads.
Ideal Use Cases
Local Uploads suits workloads where upload requests come from regions far from the bucket's primary location. The feature makes sense when:
- Users are globally distributed
- Upload performance and reliability matter to the application
- Write performance needs optimization without relocating the bucket
To check whether this applies to your workload, view the Request Distribution by Region graph on your bucket's Metrics page in the Cloudflare Dashboard.
Under the Hood: Async Replication
The background copy operation is called a replication task. For processing these tasks, Cloudflare uses Cloudflare Queues, which provide rate control, retries, and dead letter queues. R2 shards replication tasks across multiple queues per storage region.
Atomic Metadata Publication
When an object is uploaded with Local Uploads, three operations happen atomically:
- Object metadata is stored
- A pending replica key is created to track outstanding replications
- A replication task marker is created, keyed by timestamp to control when the task enters the queue
The pending replica key holds the full replication plan: task count, source and destination locations, replication mode and priority, and whether the source should be deleted post-replication. This design allows flexibility in data movement — for example, minimizing expensive cross-regional transfers by first creating one replica in the target bucket region, then using that local copy to fan out additional replicas within the region.
Queued Delivery and Pull Processing
A background process periodically scans task markers and enqueues them to queues associated with the destination storage region. Markers guarantee at-least-once delivery: if enqueueing fails, the marker persists and the task retries on the next scan.
For consumption, R2 uses a pull model where a centralized polling service handles tasks as follows:
- Pull from regional queue: The consumer batches tasks into uniform sizes based on data volume.
- Dispatch: The polling service sends replication jobs to the Gateway Worker.
- Execute: The worker reads data from source, writes to destination, and updates metadata — optionally marking the source for garbage collection.
- Report: The worker returns results to the poller, which acknowledges tasks to the queue as completed or failed.
This pull approach lets the system adapt its pace based on real-time health, keeping replication stable and efficient.
Availability and Pricing
Local Uploads is available now in open beta at no additional cost. Upload requests with the feature enabled incur standard Class A operation costs — the same as regular uploads. Enable it via the Local Uploads card in your bucket's settings in the Cloudflare Dashboard or with a Wrangler CLI command. The change is seamless: existing uploads complete as expected with no traffic interruption.
