Run your own ProtectedShare

Create a D1 database, then put the database_id it prints into apps/api/wrangler.toml. Then create the R2 bucket that holds encrypted file-drop chunks. It has to exist before you deploy, or the deploy fails.

cd apps/api
npx wrangler d1 create protectedshare
npx wrangler r2 bucket create protectedshare-drops

Rather keep chunks in D1? Delete the [[r2_buckets]] block from wrangler.toml; the API notices and stores them in the database. With R2, a lifecycle rule is recommended. It expires anything a delete missed; the cron also sweeps orphaned chunks, but each run scans only the first ~10,000 drops in the bucket:

npx wrangler r2 bucket lifecycle add protectedshare-drops expire-old-drops drops/ --expire-days 31

A new database takes the full schema in one go. schema.sql already includes everything from migrations 0001 to 0009.

npx wrangler d1 execute protectedshare --remote --file=schema.sql

Upgrading an older install? Apply the migrations you're missing, in order: 0005_v2.sql (receipts, file drops, secret requests, chat rooms), 0006_security.sql (download sessions, the request respond hash), 0007_r2_limits_stats_reports.sql (usage counts, abuse reports, lockouts, chunk sizes), 0008_push.sql (read notifications) and 0009_drop_budget.sql (the file-drop spending guard). If one reports a duplicate column, that column is already there and you can move on. The Worker also creates missing tables and columns on first use.

npx wrangler d1 execute protectedshare --remote --file=migrations/0007_r2_limits_stats_reports.sql
npx wrangler d1 execute protectedshare --remote --file=migrations/0008_push.sql
npx wrangler d1 execute protectedshare --remote --file=migrations/0009_drop_budget.sql

wrangler.toml already declares the cleanup cron (*/30 * * * *), Workers observability logs, the R2 binding and six rate limiters. Each limiter's namespace_id (71001 to 71006) must be unique within your Cloudflare account, so change any that clash. Delete a [[ratelimits]] block to skip that check.

npx wrangler deploy

If your web app uses its built-in /api proxy, every request reaches the Worker from your server's IP address, so RL_CREATE (600 new links a minute per IP) becomes a cap for the whole site. Raise it or delete it. A host's rewrite softens this but doesn't remove it: the Worker then sees the host's shared egress IPs. Setting NEXT_PUBLIC_API_ORIGIN removes it, because browsers then call the Worker themselves.

Optional Worker secrets: RESEND_API_KEY emails contact-form messages and abuse reports (without it they're only saved in D1), and ADMIN_TOKEN, at least 32 characters, turns on DELETE /api/admin/:kind/:id for takedowns. The emails go to NOTIFY_EMAIL_TO (default admin@protectedshare.me) from NOTIFY_EMAIL_DOMAIN (default protectedshare.me), which must be a domain your Resend account has verified. Those two aren't secret: set them under [vars] in wrangler.toml, or as secrets.

npx wrangler secret put RESEND_API_KEY
npx wrangler secret put ADMIN_TOKEN

Generate a VAPID key pair and store it, with a contact address for push services, as Worker secrets. Nothing is written to disk.

npm run vapid:generate
npx wrangler secret put VAPID_PUBLIC_KEY
npx wrangler secret put VAPID_PRIVATE_KEY
npx wrangler secret put VAPID_SUBJECT   # e.g. mailto:you@example.com

Then build the web app with NEXT_PUBLIC_VAPID_PUBLIC_KEY set to the same public key. Without the three secrets the API refuses to register browsers; without the web setting the notification bell doesn't appear. Rotating the keys quietly ends existing subscriptions.