# FlareDrive: a WebDAV file manager on Cloudflare R2 and Workers

> FlareDrive is a React web interface and WebDAV endpoint that turns a Cloudflare R2 bucket into a personal file hosting service, with folder creation, search, thumbnails and drag and drop uploads. It deploys as a Cloudflare Pages project with a Workers function for the API, and the whole thing runs on the free tier of both products.

**longern/FlareDrive** — Free file hosting service (WebUI & WebDAV) using CloudFlare R2

- Repository: https://github.com/longern/FlareDrive
- Website: https://drive.longern.com
- Stars: 560 · Forks: 729
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/longern-flaredrive

## What FlareDrive is built on

FlareDrive is described as a Cloudflare R2 storage manager with Pages and Workers, offering free 10 GB storage and a free serverless backend with a limit of 100,000 invocation requests per day, with a link to the Cloudflare pricing documentation.

That sentence contains the entire architecture and the entire commercial proposition. R2 is the object storage, and R2's free tier gives 10 GB. Pages is the static hosting for the web interface. Workers is the serverless runtime that provides the API and the WebDAV endpoint. And the Workers free tier gives 100,000 invocations a day.

So the project is not a file server you run. It is a set of files and a piece of logic that Cloudflare runs for you, billed against free allowances. The cost of running FlareDrive for a personal drive is therefore not a subscription, it is staying inside two free tiers.

The primary language is TypeScript, the licence is MIT, and the repository topics list the pieces: cloudflare-pages, cloudflare-r2, file-hosting, react, serverless, typescript, webdav and webdav-server.

The top level of the repository is small and shows the split between the two halves. There is Main.tsx at the root, which is the entry point for the Pages side, and a src/ directory, a public/ directory and a utils/ directory for the interface. There is a functions/ directory, which is the Cloudflare Pages Functions directory where the Worker code lives, and a TextPadDrawer.tsx file at the root, which sounds like the text editing drawer component. The tsconfig.json and package.json sit alongside them.

The project is hosted at drive.longern.com, and there is a single published release, v0.2.0 from November 2024, with the last push on 2026-05-14. So the version numbering is still in the zero range and the code is being worked on without cutting a new tag.

## The feature list, and what it implies about the storage layer

The features are six lines long, and each one tells you something about how the R2 bucket is being used.

Upload large files, with the chunking implied. Create folders, which on an object store is not a native concept. Search files, which is also not a native operation on R2. Image, video and PDF thumbnails, which means the Worker is doing media processing rather than just storing bytes. A WebDAV endpoint, so ordinary file managers can mount it. And drag and drop upload in the browser.

The three interesting ones are folders, search and thumbnails, because R2 is a flat key value store. There is no directory hierarchy and no listing index in the naive sense, so all three require the application to impose structure on top of the bucket itself.

Folders on an object store are conventionally implemented as zero byte marker objects with a trailing slash in the key, and the file list is then a filtered prefix listing. Search similarly becomes a prefix or substring scan over the key space rather than an inverted index, which is why search on a large bucket is expensive and why the storage limit and the feature interact.

Thumbnails are the third and most demanding. Producing a thumbnail for an image, a video or a PDF means the Worker has to fetch the object, decode it and produce a smaller image. For video that means extracting a frame, and for PDF it means rasterising a page. That is a substantial amount of work to do inside a request with an execution time limit, and it is the feature most likely to be constrained by the platform.

So the feature list reads as a list of things an object store does not give you for free, each of which the project has implemented on top of R2. That is the engineering story of the whole project.

Drag and drop upload is the least remarkable of the six and the most used. It is the interface everyone expects, and getting it right means handling the drag events properly and streaming the file rather than buffering it.

## Deploying it, on Pages and with Wrangler

The installation is a fork and a few environment variables, and it is written for someone deploying their own copy rather than for someone using a hosted instance.

The prerequisites come first. You need a Cloudflare account, your payment method added, and the R2 service activated with at least one bucket created.

Then four steps for the Pages route. Fork the project and connect your fork with Cloudflare Pages, selecting the Docusaurus framework preset. Set WEBDAV_USERNAME and WEBDAV_PASSWORD. Optionally set WEBDAV_PUBLIC_READ to 1 to enable public read. After the initial deployment, bind your R2 bucket to the BUCKET variable. Then retry the deployment from the Deployments page to apply the changes.

Two details in that sequence are worth understanding. The Docusaurus framework preset is odd for a React application, and it is a hint that the project was scaffolded from a template and the preset is simply what makes the build work with the existing configuration rather than a statement about the site being documentation.

The retry step is the classic Pages pattern. Environment variables and bindings are not applied to a deployment that has already been built, so the second deployment is the one that actually has the bucket attached. That is a well known wrinkle and the readme handles it by telling you to do it.

The alternative route uses the Wrangler CLI:

```bash
npm run build
npx wrangler pages deploy build
```

Which is the same build react-scripts produces followed by a Wrangler deploy of the build directory. The scripts in the package manifest are the react-scripts set, start, build, test and eject, so npm run build is a standard Create React App production build.

The optional custom domain step is the last one, and it is the one that matters for the WebDAV endpoint, because a public read URL and a WebDAV URL both need to be something you can point a client at.

## The WebDAV endpoint and its hard limit

The WebDAV support is the feature that makes FlareDrive useful as a drive rather than just a web page, and it comes with a limitation the readme states plainly.

You can use any client that supports the WebDAV protocol, and the readme names two, Cx File Explorer and BD File Manager. The endpoint URL is https://<your-domain.com>/webdav and the credentials are the username and password you set.

The limitation is this: the standard WebDAV protocol does not support large file, at or above 128MB, uploads due to the limitation of Cloudflare Workers. You must upload large files through the web interface which supports chunked uploads.

That constraint is worth unpacking, because it explains a lot of the design. A WebDAV upload is a single PUT request with the file body in it. A 200 MB file in a single PUT is a request body of 200 MB, and Cloudflare Workers caps request body size. Chunked upload, the multipart mechanism the browser uses, splits the file into pieces that each fit under the limit, and each part is a separate invocation with its own state.

So the two upload paths are genuinely different implementations, not one wrapping the other. The browser path can handle files of any size the free tier allows, and the WebDAV path handles anything under 128 MB.

For a personal drive that is a workable arrangement. Large media files go up through the web interface, and the WebDAV endpoint is there for the ordinary case of a document library, a sync folder, or mounting the drive in a desktop file manager for everyday work.

The acknowledgement section notes that the WebDAV related code is based on the r2-webdav project by abersheeran. So the WebDAV layer is adapted from an existing implementation of the same idea, which is a sensible thing to do rather than writing a WebDAV server from scratch, and it also means the hard limits you hit are likely to be the ones that project hits.

The README is MIT licensed, so the licensing of the borrowed code is not a barrier as long as the attribution is present in the repository.

## The dependency choices and what they say

The package manifest is worth reading because it describes the shape of the front end precisely.

The interface is React 18, with react-dom 18, and the component library is MUI at version 5 with @mui/material and @mui/icons-material, which is why the readme talks about a Cogwheel button and a round button and a square button in the same style. The styling underneath is Emotion, with @emotion/react and @emotion/styled.

The build tooling is react-scripts at 5.0.1, the Create React App toolchain, with TypeScript 5.5 and a Web Vitals package for the performance metrics that CRA collects. The scripts are start, build, test and eject, which is the standard set, and the eslintConfig extends the react-app presets.

Two dependencies stand out. p-limit at 6.1.0 is a promise concurrency limiter, and in an application that uploads chunks to a Worker, limiting how many are in flight at once is exactly what you need, since a browser that fires fifty concurrent chunk requests will hit rate limits or exceed the invocation budget. And @testing-library/react with jest-dom and user-event is the testing setup, alongside the jest-dom matchers.

The dev dependencies add @cloudflare/workers-types at 4.20240620.0, which is how the Worker code gets type definitions for the Workers runtime, and @babel/plugin-proposal-private-property-in-object, which is a well known workaround for a react-scripts 5 issue with newer Babel versions.

There is also an override that forces typescript to version 5 inside react-scripts, which is the standard fix for the same class of problem, and a browserslist with a production target of more than 0.2 percent, not dead, and not op_mini all.

The package is marked private and the version field in the manifest is 0.1.0, which is consistent with a project that is deployed by forking rather than consumed from a registry. The name is flare-drive, and the repository is FlareDrive.

## Conclusion

Adopt FlareDrive if you want a personal file drive with a WebDAV endpoint on Cloudflare's free tier and you are willing to host it yourself. Do not adopt it if you need large file uploads over WebDAV, because the readme is explicit that the standard protocol cannot handle files of 128 MB or more due to a Cloudflare Workers limitation, and you have to use the web interface for those instead. Before you commit, read the Cloudflare pricing page yourself, because the free limits the project advertises have changed over time, and remember that setting WEBDAV_PUBLIC_READ to 1 makes your files readable by anyone who has the URL.

## FAQ

### What is FlareDrive?

It is a Cloudflare R2 storage manager built with Pages and Workers that provides free 10 GB of storage and a free serverless backend limited to 100,000 invocation requests per day. It offers a web interface and a WebDAV endpoint, and it is MIT licensed and written in TypeScript.

### What features does FlareDrive provide?

Upload large files, create folders, search files, generate image, video and PDF thumbnails, a WebDAV endpoint and drag and drop upload. Folders, search and thumbnails all require the application to impose structure on R2, which is a flat key value store with no native directory or listing concept.

### How do I deploy FlareDrive?

Create a Cloudflare account, add a payment method, activate R2 and create a bucket, then fork the project and connect your fork to Cloudflare Pages with the Docusaurus framework preset. Set WEBDAV_USERNAME and WEBDAV_PASSWORD, optionally WEBDAV_PUBLIC_READ=1, bind your R2 bucket to the BUCKET variable, then retry the deployment. You can also build with npm run build and deploy with npx wrangler pages deploy build.

### What is the limitation of the FlareDrive WebDAV endpoint?

The standard WebDAV protocol does not support uploads of files of 128 MB or more, because of a Cloudflare Workers limitation. Those files have to be uploaded through the web interface, which uses chunked uploads. Ordinary WebDAV clients such as Cx File Explorer and BD File Manager work against the https://<your-domain.com>/webdav endpoint.

### How do I make FlareDrive files publicly readable?

Set WEBDAV_PUBLIC_READ to 1 in the Cloudflare Pages environment settings during the initial deployment. The optional custom domain step is worth doing at the same time, since both the public read URL and the WebDAV endpoint need an address you can point clients at.

## Sources

- [License: MIT](https://github.com/longern/FlareDrive/blob/main/LICENSE)
- [longern/FlareDrive on GitHub](https://github.com/longern/FlareDrive)
- [Project website](https://drive.longern.com)
- [README](https://github.com/longern/FlareDrive/blob/main/README.md)
- [Releases](https://github.com/longern/FlareDrive/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/longern-flaredrive