feat: Bring-your-own Cloudflare Workers + R2 encrypted sync provider

[mrchatam]

Summary

I'd like to contribute a bring-your-own Cloudflare Workers + R2 encrypted sync backend, as an optional sync provider alongside the existing GitHub Gist Sync plugin and Voltius cloud sync.

Motivation

Many users want cross-device vault sync without:

• a vendor-hosted sync service, or
• relying on GitHub Gists

Cloudflare Workers + R2 is a natural fit: the user deploys and owns the Worker, R2 stores only ciphertext + non-sensitive sync metadata, and encryption stays client-side (same model as Gist sync).

Proposed architecture

Voltius client
  → local vault encryption (existing)
  → sync plugin (new): plugin-cloudflare-sync
  → user's Cloudflare Worker
  → R2 (opaque device blobs + plaintext manifest: salt, device ids, pushedAt)

Client (plugin)

Mirror src/plugins/gist-sync/:

• Reuse api.sync.exportState / api.sync.importStates and api.crypto.deriveKey
• No changes to SSH core or official src/services/sync.ts
• Secrets in api.vault (Worker token + passphrase; passphrase required — do not derive the enc key from the transport token)
• Poll-based sync (default ~60s), pull-then-push, same conflict approach as Gist (LWW via importStates)

Server (user-owned)

Clean-room Worker template (MIT), e.g. under examples/cloudflare-sync-worker/:

• Bearer token auth (SYNC_TOKEN secret)
• R2 only for MVP (no D1/KV required)
• Endpoints roughly: /health, /v1/manifest, /v1/devices/:id
• Worker never runs Argon2 / vault crypto

Why a plugin (not a sync.ts backend)

PluginAPI already exposes the encrypted export/import path that Gist uses. A Cloudflare provider can ship as:

1. Seeded optional plugin (like Gist Sync), or
2. Marketplace MIT plugin + docs linking a Worker template

I can implement either; maintainers' preference welcome.

Security requirements

• Worker/R2 must only ever see ciphertext + sync metadata (device id/label/timestamps/salt/size)
• Transport token ≠ encryption secret
• Offline export/recovery remains possible without Cloudflare
• No Voltius Pro bypass — this is BYO infrastructure, complementary to hosted sync

Scope / non-goals (MVP)

• Not replacing Pro cloud / SSE realtime
• Not team vaults
• Not multi-tenant hosted SaaS on Cloudflare
• Poll first (no Durable Objects realtime in MVP)

Implementation plan (on fork)

Working fork: https://github.com/mrchatam/voltius
Branching from dev, small phases with tests, aligning with CI (pnpm test / pnpm build, plugin seed list / Windows plugin assert if seeded).

Happy to adjust shape (seeded vs marketplace-only, API details) before/during review.

Checklist

• Maintainer preference: seeded in-app vs marketplace-only
• Confirm Worker template path (examples/ vs separate repo) is acceptable
• Any API/naming constraints before PR

[mrchatam]

Progress update (fork)

Working branch on fork: https://github.com/mrchatam/voltius/tree/feat/cloudflare-sync

Implemented so far:

Worker (examples/cloudflare-sync-worker/, MIT):

• GET /health
• Bearer SYNC_TOKEN on /v1/*
• GET|PUT /v1/manifest
• GET|PUT|DELETE /v1/devices/:id (R2 + manifest upsert)
• CORS/OPTIONS
• vitest suite green

Plugin (src/plugins/cloudflare-sync/, seeded):

• Manifest + register lifecycle
• worker-api client
• sync-engine: setup/link, passphrase-required KDF, push/pull/syncNow/poll
• Settings UI (URL, token, passphrase, create/link/health/sync/disconnect)
• Seeded in build-plugins.mjs, src-tauri/build.rs, CI Windows assert (7 plugins)
• Unit tests green; plugin Vite bundle builds

Open questions still welcome from maintainers:

1. Prefer seeded in-app (current) vs marketplace-only?
2. OK to keep Worker template under examples/?

Will open a PR targeting dev once you indicate preference / after any feedback.

[kipavy]

Thanks for the detailed proposal and the fork work already done — this is a well-scoped design.

Our preference: marketplace-only, not seeded in-app.

Reasoning: Gist Sync got seeded because its setup barrier is near-zero — most users already have a GitHub account, just paste a token. Cloudflare Workers + R2 asks users to deploy and own a Worker (wrangler, R2 bucket, token) before sync works at all — a much narrower audience, self-hosters/devs comfortable with Cloudflare infra. That's a better fit for opt-in marketplace than default-seeded, where it'd sit unused for most installs while still coupling the seed list (build-plugins.mjs, src-tauri/build.rs) and Windows CI plugin-count assert to your release cadence.

Marketplace path gets you full reach for the users who do want it, no core coupling, matches your own "why a plugin" reasoning in the issue. Open to revisiting seeded status later if adoption proves it out.

On the other two open questions:

• examples/cloudflare-sync-worker/ — fine to keep versioned in your own repo/marketplace listing rather than upstream examples/.
• No objections on API/naming as described; happy to review specifics at PR time.

Feel free to open the marketplace submission whenever ready — thanks again for building this out.

[mrchatam]

Thanks @kipavy — that makes total sense.

Gist is basically “paste a token”; Cloudflare asks people to own a Worker + R2 first, so marketplace-only is the better fit. We’ll pivot off the seeded approach:

• keep the plugin marketplace-only (not in the seed list / core CI asserts)
• host the Worker template in our repo and point the marketplace listing at that
• close the current core PR that seeded the plugin + dropped examples/ upstream — wrong shape for what you asked

We’ll open a marketplace submission when the standalone plugin + Worker docs are ready. Appreciate the clear guidance.

[kipavy]

Shipped. Cloudflare Sync is live in the marketplace and Voltius 0.37.0 shows it as a first-class sync provider.

Plugin — plugin-cloudflare-sync 0.4.0, served from the catalogue, installable from Settings → Plugins → Marketplace or straight from the sync menu. Architecture is the one proposed here: client-side E2EE with a passphrase-derived key (never the transport token), exportState/importStates, R2 holding opaque device blobs, Bearer SYNC_TOKEN for transport auth only. Setup is a three-step wizard that deploys the Worker from inside Settings via the Cloudflare API, creating the R2 bucket and generating the sync token; the API token is never stored. The Worker source lives in the plugin directory and is inlined into the built bundle, so the catalogue hash covers the exact Worker that gets uploaded.

App — 0.37.0 added a sync-provider contract, so any plugin holding sync:write appears alongside Voltius cloud sync in the title bar, the sync menu, the mobile header, Settings → Sync and the MCP sync_status tool, each with its own status and Sync now. Uninstalled providers are offered for install from those surfaces.

Docs — Cloudflare sync for users, Building a sync provider for plugin authors.

Thanks @mrchatam — the plugin and the Worker are your design and your code; the copy in the marketplace repo is the reviewed version the catalogue serves, and it has now been run against the real Cloudflare API.