Cloudflare enabled FUSE for local Containers on 20 August 2026 but rootful Docker and CI are excluded

Summary. On 20 August 2026 Cloudflare made Miniflare grant local Containers the Docker privileges needed for Filesystem in Userspace, covering wrangler dev, the Cloudflare Vite plugin and direct Miniflare use. The grant is conditional. It applies when the Docker daemon runs inside a virtual machine, which covers macOS and Windows Subsystem for Linux, and on Linux only for rootless Docker where /dev/fuse exists. Cloudflare states plainly that "rootful Docker on Linux does not support FUSE by default during local development" - the exact configuration most Linux CI runners use. Separately, the official R2 FUSE example, last updated 21 August 2026, installs tigrisfs by querying the GitHub releases API at build time with no version pin. That project's latest release is v1.2.1, published 6 May 2025, and its last repository push was 1 October 2025. Every directory listing across that mount bills as an R2 Class A operation at $4.50 per million requests, 12.5 times the Class B read rate of $0.36 per million.

What actually shipped

The changelog entry of 20 August 2026 is four sentences long and every one of them is a condition. Miniflare grants FUSE privileges "when the local Docker daemon runs inside a virtual machine (VM)", and on Linux "for local rootless Docker when /dev/fuse is available". The local development documentation repeats the same wording and adds the failure mode: Miniflare "does not grant FUSE privileges when the Docker daemon does not meet these conditions or cannot be inspected."

Read that last clause carefully. The grant depends on Miniflare being able to inspect the Docker daemon. A daemon reachable over a non-default socket, a remote daemon, or a rootless setup where the inspection call is refused all land in the same bucket as an unsupported daemon, and the failure is a silent absence of a privilege rather than an error.

Environment	Docker daemon	FUSE granted in `wrangler dev`?
macOS with Docker Desktop	Runs in a VM	Yes
Windows with WSL 2	Runs in a VM	Yes
Linux, rootless Docker, `/dev/fuse` present	Rootless	Yes
Linux, rootless Docker, no `/dev/fuse`	Rootless	No
Linux, rootful Docker	Rootful	No, stated explicitly
Any host where the daemon cannot be inspected	Unknown	No

The gap that will bite you in CI, not on your laptop

The split in that table runs along exactly the wrong line. Developer machines are overwhelmingly macOS and Windows, where the Docker daemon lives in a VM and FUSE now works. Continuous integration runners are overwhelmingly Linux with rootful Docker, where Cloudflare says it does not.

So a container test that mounts a bucket and reads a fixture passes on every laptop in the team and fails on the first push. Worse, it may not fail loudly. A FUSE adapter that cannot obtain the device typically fails at mount time and leaves an empty directory behind, so a test asserting on file contents fails with a confusing "file not found" rather than "FUSE unavailable". Teams running self-hosted GitHub Actions runners with version enforcement should check the daemon mode on the runner image before assuming parity with local development.

There is no documented flag to force the grant, and the Containers limits page, last updated 3 July 2026, does not mention FUSE at all. Neither does the Containers pricing page, last updated 21 April 2026.

The R2 mount example installs an unpinned, stale dependency

Cloudflare's Mount R2 buckets with FUSE example, last updated 21 August 2026, gives a working Dockerfile built on alpine:3.20. It installs tigrisfs, an Apache-2.0 licensed S3-compatible FUSE adapter, using this pattern inside the image build:

VERSION=$(curl -s https://api.github.com/repos/tigrisdata/tigrisfs/releases/latest | grep -o '"tag_name": "[^"]*' | cut -d'"' -f4) && \
curl -L "https://github.com/tigrisdata/tigrisfs/releases/download/${VERSION}/tigrisfs_${VERSION#v}_linux_${ARCH}.tar.gz" -o /tmp/tigrisfs.tar.gz

Three problems sit in those two lines.

The version is resolved at build time from releases/latest, so two builds of the same Dockerfile on different days can produce different binaries. That is the definition of a non-reproducible image, and it is being demonstrated in a vendor's own documentation.

The GitHub REST API is being called unauthenticated from inside a Docker build. Unauthenticated requests are rate limited by source IP. On a shared CI network address that limit is reached routinely, at which point curl -s returns a rate-limit JSON body, the grep finds no tag_name, VERSION becomes an empty string, and the download URL degrades to a path with two consecutive slashes and an empty version. The build then fails inside tar, several steps away from the actual cause.

The dependency itself is not moving. As of 23 August 2026 the tigrisfs repository shows a latest release of v1.2.1 published on 6 May 2025, a last push of 1 October 2025, 231 stars and 9 open issues. Nothing about that is disqualifying for a utility binary, but it is a fifteen-month-old release being pulled unpinned into a container that will hold R2 credentials. If you copy this example, pin the tag and verify the published checksums.txt asset shipped alongside the release. This is ordinary software supply chain hardening work, and the same discipline that stops hallucinated package names reaching a build applies here.

One more detail in that Dockerfile: the Alpine package install passes an explicit repository over plain HTTP, http://dl-cdn.alpinelinux.org/alpine/v3.20/main. Alpine signs its package indexes, so this is not an open door, but it is not the default and it is worth a conscious decision rather than a copy-paste.

What the mount costs, which the example does not say

The example page discusses performance and warns that "object storage is not a POSIX-compatible filesystem, nor is it local storage" and that you "should not expect native SSD-like performance". It says nothing about billing, and billing is where a FUSE mount surprises people.

A FUSE adapter turns filesystem syscalls into S3 API calls. R2 prices those in two classes, and the classification is not the one intuition suggests.

Filesystem action on the mount	R2 operation	Rate, standard storage
Listing a directory	`ListObjects`, Class A	$4.50 per million requests
Reading a file	`GetObject`, Class B	$0.36 per million requests
Stat on a file	`HeadObject`, Class B	$0.36 per million requests
Writing a file	`PutObject`, Class A	$4.50 per million requests
Multipart write parts	`UploadPart`, Class A	$4.50 per million requests
Deleting a file	`DeleteObject`, free	No charge

ls is the expensive one. The startup script in Cloudflare's own example ends with ls -lah /mnt/r2, so every container cold start performs at least one Class A listing before it does any work. The free tier covers 1 million Class A and 10 million Class B requests per month, and Cloudflare rounds usage up to the next billing unit, so "one million and one operations" bills as two million. A build tool or a language runtime walking a mounted tree at startup, which is precisely the "bootstrapping containers with assets" use case the page recommends, can turn a few hundred container starts a day into a Class A line item.

Container compute is billed separately. The pricing page sets Workers Paid at $5 USD per month with 25 GiB-hours of memory, 375 vCPU-minutes and 200 GB-hours of disk included, then $0.0000025 per additional GiB-second, $0.000020 per additional vCPU-second and $0.00000007 per additional GB-second. A FUSE mount does not change those rates, but a slow mount extends wall-clock time on an instance whose memory and disk bill on provisioned resources rather than active use.

Sizing, because a mount does not remove the disk limit

Instance disk runs from 2 GB on lite to 20 GB on standard-4, and custom instance types cap at 4 vCPU, 12 GiB memory and 20 GB disk, with a maximum of 2 GB of disk per 1 GiB of memory. Image size is capped at the instance disk space, and total image storage per account is 50 GB.

Mounting R2 sidesteps the image-size ceiling for data, which is the genuine win here and the reason "avoid bloating container images" appears in the use-case list. It does not sidestep local disk pressure from an adapter's cache, and lite at 256 MiB of memory and 2 GB of disk is a thin place to run a caching FUSE client. Teams already sizing Cloudflare Containers alongside Durable Objects should treat the mount as another resident process, not as free storage.

India-specific considerations

Container egress is priced by region, at $0.025 per GB for North America and Europe with 1 TB included, $0.05 per GB for Oceania, Korea and Taiwan with 500 GB included, and $0.04 per GB for everywhere else with 500 GB included. India falls in the third band, so a workload that mounts a bucket and streams data out to Internet clients carries a higher egress rate and a smaller allotment than the same design run for a European audience. R2 itself charges no egress. Where the bucket holds personal data, remember that R2 jurisdictions are set at bucket creation and cannot be changed afterwards, which matters for anything with a Digital Personal Data Protection Act 2023 residency commitment attached, as covered in our note on the R2 us jurisdiction endpoint lock-in.

What to do

Check the daemon mode on your CI image first. If it is rootful Docker on Linux, either move the runner to rootless with /dev/fuse exposed or mark FUSE-dependent tests as skipped rather than letting them fail with a misleading error.

Pin tigrisfs to a tag and verify the checksum rather than resolving releases/latest inside the build. Move the download to a build stage that can be cached, so a GitHub API rate limit does not break an unrelated deploy.

Instrument R2 operations by class before you widen the mount's use, and assume every directory walk is a Class A charge. If your access pattern is mostly whole-file reads, the mount is cheap. If it is a tree walk, it is not.

Size the instance for the adapter, not just the application, and keep the mount out of anything on the request path until you have measured it. The docs are explicit that this is not local storage, and treating it as though it were is how a 2 GB lite instance becomes a latency incident.

What is still unknown

Cloudflare has not published a supported way to force the FUSE grant on rootful Docker, has not said whether the limits or pricing pages will be updated to cover FUSE, and has not stated whether tigrisfs is a recommendation or merely one working example. Nor has it published guidance on which R2 operation classes a typical mount generates. Until it does, measure your own.

The real cost here is rarely the mount. It is the test suite that only fails where nobody is watching.

FAQ

What did Cloudflare change on 20 August 2026?

Miniflare now automatically grants local Containers the Docker privileges required for Filesystem in Userspace. This applies to wrangler dev, the Cloudflare Vite plugin and direct Miniflare use. The grant is conditional on the Docker daemon running inside a virtual machine, or on Linux being rootless with the fuse device available.

Why does FUSE fail on my Linux CI runner?

Cloudflare states that rootful Docker on Linux does not support FUSE by default during local development, and most Linux CI runners use rootful Docker. Miniflare also withholds the privilege when it cannot inspect the daemon at all, so a remote or unusual socket configuration produces the same outcome without an explicit error.

Is the tigrisfs install in Cloudflare's example safe to copy?

It works, but it resolves the version from the GitHub releases API at build time with no pin, which makes the image non-reproducible and dependent on an unauthenticated API call. The project's latest release is v1.2.1 from 6 May 2025. Pin the tag and verify the published checksums file instead.

How does mounting R2 with FUSE affect my bill?

Filesystem operations become R2 API calls. Listing a directory maps to ListObjects, a Class A operation billed at $4.50 per million requests. Reading and stat map to GetObject and HeadObject, Class B at $0.36 per million. Deletes are free. Cloudflare rounds usage up to the next billing unit.

Does a FUSE mount get around the container disk limit?

For data, largely yes, which is the point of the feature. Instance disk still runs from 2 GB on lite to 20 GB on standard-4, custom types cap at 20 GB, and total image storage per account is 50 GB. The adapter itself still consumes local memory and disk on the instance you chose.

Will a FUSE mount be fast enough for my workload?

Cloudflare's own guidance says object storage is not a POSIX-compatible filesystem nor local storage, and that you should not expect native SSD-like performance. It recommends the pattern for reading shared assets, bootstrapping agents or sandboxes, and persisting user state, rather than for high-performance input and output.

Do the Containers limits and pricing pages cover FUSE?

No. The limits page was last updated on 3 July 2026 and the pricing page on 21 April 2026, both before this change, and neither mentions FUSE. The only documentation is the changelog entry, the FUSE support section of the local development page, and the R2 mount example.

How eCorpIT can help

A vendor example that pulls an unpinned binary into an image holding storage credentials is the sort of thing that passes review because it came from the vendor. Our engineering teams pin, checksum and rebuild these paths as part of software supply chain hardening, and align CI runner images so local and pipeline behaviour match. If your container tests pass locally and fail in the pipeline, ask our platform team to review your runner and Dockerfile setup.