R2-Explorer puts a Google Drive style front end on an R2 bucket

A file manager that runs inside your own Cloudflare account

R2-Explorer describes itself as a Google Drive interface for Cloudflare R2 buckets, and the mechanics are simple once you accept the deployment model. It is a web application you run yourself, on your own Cloudflare account, pointed at a bucket you own. The documentation stresses that the interface is enterprise-grade in the way that self-hosting on Cloudflare infrastructure is, which is a claim about where the code runs rather than about the code itself.

The feature set is a file manager, not a developer tool. You get drag and drop upload, folder creation, multi-part upload for large files, a right-click context menu, HTTP and custom metadata editing, and folder upload. Objects can be previewed in the browser for PDF documents, images, text files, Markdown, CSV and Logpush files, and text-like files can be edited in place.

Two integrations make it more than a bucket browser. Cloudflare Email Routing lets the application receive and process emails, with attachments viewable directly in the interface, and the sharable links feature turns an object into a public URL with optional password protection, an expiration time and a download limit.

The documentation site is r2explorer.com, there is a live demo at demo.r2explorer.com, and the interface is translated into Spanish, Portuguese and French in addition to English.

Three install routes, and the GitHub Action is the recommended one

The installation section offers three routes, and the ordering is a recommendation rather than a neutral list.

The first is a GitHub Action, marked as recommended, with a guide on the documentation site. The second is creating the project with the Cloudflare CLI, also with its own guide. The third is a template repository in the project tree that you can copy. There is also a Deploy to Cloudflare button in the README, pointing at a template in Cloudflare's own templates repository, so the shortest path is a single click followed by filling in the bucket and account details.

The split between the dashboard and the worker in the package scripts shows what you are actually deploying. There is a build-dashboard step and a build-worker step, separate deploy-dashboard and deploy-dashboard-dev scripts, and a separate deploy-dev-worker script for a development worker. So the application is at least two deployed pieces, a static dashboard and a Worker that talks to R2, and the install route determines which of them you set up.

Maintenance is documented too, with a separate update guide for maintaining and updating an existing installation, which is the part most self hosted tools leave to you.

The pnpm monorepo and what each script does

The repository is a pnpm workspace, with pnpm-workspace.yaml, a pnpm-lock.yaml and a packages/ directory, and the root package.json names itself r2-explorer-root at version 0.0.0 with private set to true, so it is a workspace root rather than a published package. The packageManager field pins [email protected], so a contributor gets a known toolchain.

The scripts describe the whole pipeline, and the interesting ones are these:

		"build-dashboard": "pnpm run --filter r2-explorer-dashboard build",
		"build-worker": "pnpm run --filter r2-explorer build",
		"build": "pnpm build-dashboard && pnpm build-worker",

		"test:e2e": "pnpm build-dashboard && pnpm exec playwright test --config packages/dashboard/playwright.config.ts",

Unit and component tests are separated from the end to end suite, with the test script running the worker tests and then the dashboard tests, and the end to end suite building the dashboard first and then running Playwright against it. There is a workers-ci script that sets WORKERS_CI and runs a prepareDeploy script in packages/github-action, which is the automation the GitHub Action install route depends on.

Linting is done with Biome, pinned at 1.9.4, and the lint script is written so that a failure triggers a rewrite pass and then still exits non-zero. Releases go through changesets, and the release script builds, runs publint against the published package and then publishes, so package metadata problems are caught before they reach the registry.

Two ways to lock it down, and a known issue with one of them

Access control is handled two ways, and the project expects you to pick one. Basic authentication is the simpler option, and Cloudflare Access integration is the one that puts the login in front of Cloudflare's own identity layer. Either way the application is deployed on your own account, so the bucket never leaves your Cloudflare project.

There is a known issue worth reading before you choose. When basic authentication is used, inline images and assets in emails do not load properly. That is a narrow bug in the email rendering path, but it lands exactly where a team using Cloudflare Email Routing would notice it, and it is listed under known issues rather than fixed.

The rest of the security story rests on the hosting model rather than on features inside the application. The document says the interface maintains enterprise-grade security through Cloudflare's infrastructure, which is a claim you should evaluate on Cloudflare's terms rather than on the application's, since your own account, your own Workers and your own Access policies are what stand between a visitor and your bucket.

Sharable links are the feature to treat carefully, because they deliberately create public URLs. The documentation lists optional password protection, expiration times and download limits, and the order of those protections matters: an unprotected public link on a bucket is a data exposure, and the defaults are yours to verify.

What the roadmap says is still missing

The roadmap is unusually concrete, which makes it the most useful part of the README for anyone deciding whether the tool covers their case.

On file management, the planned items are support for bucket names with spaces, file search, folder renaming, and image thumbnail generation. Search and renaming are the two that a team used to Google Drive will notice immediately, so their absence is a real gap in an interface whose entire premise is familiarity.

Under AI integration there is one item, object detection using workers-ai, which suggests a future feature where uploaded images are classified automatically. Under user experience, the planned items are enhanced timestamp tooltips, email response capabilities, and advanced file type specific editing. Email response in particular would turn the Email Routing integration from a read-only inbox into something conversational.

The document describes this list as what the team is actively working on, and the release history supports a steady pace rather than a burst: v1.2.0 on 2026-04-09, v1.1.14 on 2026-02-03 and v1.1.13 on 2025-12-03, with the last push on 2026-10-18. Patch releases between minor ones, roughly every two months, with continuous work in between.

The alternative is the Cloudflare dashboard, and the difference is who it is for

Cloudflare provides its own dashboard for R2, and it is the default alternative. The difference in approach is that the Cloudflare dashboard is an administration surface, while R2-Explorer is an end-user surface. In the dashboard you configure buckets, lifecycle rules, access policies and custom domains. In R2-Explorer you browse objects, preview them, edit them, share them and receive email.

That gap matters for two specific jobs. If people outside your infrastructure team need to look at a file in a bucket, or send a link to one, the built-in console is a poor fit and something like this fills a real hole. If the job is bucket administration, R2-Explorer is the wrong tool and adds a deployable application where none is needed.

The other alternative is to write a small script against the R2 API, or to use an existing S3-compatible client, since R2 speaks the S3 API. That gives full control and no deployment, at the cost of building a user interface, and the point of R2-Explorer is precisely that the interface is the expensive part.

The trade in every case is the same: a self hosted application inside your Cloudflare account, in exchange for a human interface over your object storage.

MIT terms, a template directory and the documentation as the real spec

The project is licensed under the MIT License, with the LICENSE file at the repository root, so you can run it, modify it and offer it to your own users without a licensing obligation beyond the notice.

The repository layout shows a project with more than a worker and a dashboard. There is a packages/ directory holding the workspace packages, a template/ directory used for the template install route, a .changeset/ directory for the release workflow, biome.json for formatting and linting, and two files that are worth reading before contributing: AGENTS.md and DEVELOPMENT.md.

Releases are published through changesets, with the changelog generated from the changeset entries, and the release script also runs publint, which is a check on the published package metadata and file list.

The specification for behaviour lives on the documentation site rather than in the repository. The install guides, the update guide and the feature descriptions are all at r2explorer.com, with the live demo at demo.r2explorer.com for trying the interface before deploying anything. For a project whose interface is the product, a documentation site with screenshots and per-feature guides is a reasonable choice, and it also means the README stays short enough to be read.

One thing the repository does not make obvious is the deployment's own configuration, since the scripts show how to build and deploy but the environment variables, the bucket binding and the Access settings live in the guides on the site.

Editorial conclusion

R2-Explorer fits a team that stores objects in Cloudflare R2 and needs a human-facing way to browse, preview, edit and share them without writing a console session or an S3 client, and the GitHub Action install route makes it a weekend project rather than a project. It does not fit an environment where a self hosted Worker on your own account is not allowed, and it does not fit a workflow that depends on file search, folder renaming or thumbnails, since the documentation lists those as roadmap items rather than features. Before deploying, decide between basic authentication and Cloudflare Access, and read the known issue about inline images in emails failing under basic authentication.

Frequently asked questions

Official sources

1. G4brym/R2-Explorer on GitHub
2. License: MIT
3. Project website
4. README
5. Releases