ZPan

ZPan turns an S3-compatible bucket such as Cloudflare R2, Backblaze B2 or AWS S3 into a multi-user file drive. Browsers upload straight to the bucket through presigned URLs, so the Worker handles accounts, metadata and sharing rather than file traffic.

Day to day, ZPan works like a web drive, with folders, previews, search, trash, quotas and team workspaces. Share links can carry a password, an expiry date and a download limit. Screenshot tools such as PicGo, PicList, uPic, ShareX and Flameshot can upload to it as an image host, and each user can have a public /u/username page. WebDAV mounts the drive in desktop clients. Remote-download tasks pull files from the web into storage, optionally through a downloader deployed somewhere with better network access. Besides R2, B2 and AWS S3, ZPan works with MinIO, RustFS, Tigris and other S3-compatible services. The README names Cloudflare Workers as the recommended target. There ZPan runs as one Worker with static assets, a D1 database, a KV cache namespace, a queue for archive jobs and an R2 bucket for avatars and logos. Cron triggers handle maintenance such as trash purges and monthly traffic-quota resets. Outbound email can go through Cloudflare Email Sending, SMTP or an HTTP API. The GitHub Actions workflow creates the D1 database, the queue and the bucket, and it deploys the latest upstream release rather than the code in the fork. The docs also cover Docker, AWS Lambda, Azure Functions, Cloud Run, Netlify and Vercel.

Built for: Self-hosters and small teams who have, or plan to use, an S3-compatible bucket such as R2 and want a web drive and image host in front of it.

What you can use it for

• Run an S3-backed web drive for one person or a small team
• Host screenshots uploaded from PicGo, ShareX or Flameshot
• Share files with passwords, expiry dates and download limits
• Mount object storage on a desktop over WebDAV
• Pull remote downloads straight into a bucket

Deploy

• Manual

  requires Workers Paid

  Fork the repository, add CLOUDFLARE_ACCOUNT_ID and CLOUDFLARE_API_TOKEN (Workers Scripts, D1 and R2 edit) as Actions secrets, then run the Deploy to Cloudflare Workers workflow. Syncing the fork with a new release redeploys automatically.

  Docs

After the workflow runs, the first account to register becomes the administrator, and S3-compatible storage is added in the admin settings.

What it needs to run

• D1 databaseszpan-db
• KV namespacesCACHE_KV
• Queues (consumer)zpan-archive-jobs
• Queues (producer)zpan-archive-jobs
• R2 bucketszpan-public-images
• Email sendingEMAIL

Good to know

The deploy workflow creates the D1 database, the queue and the R2 bucket, but not a KV namespace. The wrangler.toml in release v2.9.0 binds CACHE_KV to a namespace ID from the maintainer's account, so a deploy to another account fails until the fork's workflow creates its own namespace and writes that ID into the config. User files need an S3-compatible bucket whose endpoint browsers can reach, because uploads use presigned URLs. The free community edition allows up to three storage backends, one extra team workspace and one remote downloader. Open registration, custom branding, audit logs, analytics and image custom domains need a paid Pro or Business license, and selling storage and traffic needs Business. A dedicated WebDAV hostname needs the deploy token extended with Transform Rules edit permission. The scheduled Worker sends an instance heartbeat (instance ID, name, URL and version) to the project's telemetry endpoint every 12 hours.

Cost on Cloudflare

Where this comes from

• Repositoryhttps://github.com/saltbo/zpan
• App websitehttps://zpan.space
• Documentationhttps://zpan.space/docs/

An alternative to Dropbox, Google Drive, MediaFire, OneDrive, SwissTransfer, WeTransfer.