Product Docs Pricing Changelog
Start free Sign in
Trust & verification

Don't trust us. Verify us.

Flarelink holds a scoped token to your Cloudflare account, and our orchestrator is closed source. That's a lot to ask. So we made it so you don't have to take our word for any of it — the auth Worker we deploy is reproducible from public source, you can prove the bytes running in your account match it in one command, and the secrets stay on your side.

What's open, what's not

The orchestrator is closed. Its effects are not.

The dashboard that does the provisioning is the product, and it stays closed. But it never needs to be audited, because everything it creates lands in your account where you can inspect it — and the one credential-holding part, the auth Worker, is fully public and reproducible.

Public & verifiable
Closed source
  • The dashboard / orchestrator. Provisioning, the table editor, the file browser, billing.
  • Why it doesn't matter for trust:
  • → Everything it creates is in your account, inspectable via the Cloudflare dashboard + wrangler.
  • → Every change it makes is logged in the dashboard's Activity page, and its token usage is independently recorded in Cloudflare's own audit log.
  • → If Flarelink disappears, you lose only the closed part. Your backend keeps running.

A note on wording: the auth Worker is source-available (FSL-1.1-MIT — each release converts to MIT two years later, with a no-competing-use clause until then), not "open source". The SDK, starters, and verify CLI are MIT and genuinely open source. We keep that distinction straight on purpose.

Verify it yourself

Two checks, neither requiring trust in us.

1 · The published bundle reproduces from source

Clone the repo at the version tag, rebuild from pinned dependencies, and the hash matches what's published in HASHES.md — byte-for-byte.

# in flarelink-dev/auth-module git checkout v0.3.0 npm ci && npm run build shasum -a 256 dist/worker.mjs

2 · The deployed bundle matches the published one

One command downloads the Worker live from your account (using your own token), extracts it, and compares its hash to the published value.

CF_API_TOKEN=… CF_ACCOUNT_ID=… \ npx @flarelink/verify \ --url https://your-auth.workers.dev

Together: the bytes Cloudflare runs for your users → the published hash → public source you can read and rebuild. The closed dashboard sits entirely outside that chain.

The token

What the API token can do — and what it can't.

The Cloudflare API token is the only secret Flarelink holds (AES-256-GCM encrypted). It's scoped to exactly what's needed, all account-level:

Workers Scripts: EditDeploy your auth Worker.
D1: EditYour database + the table editor.
Workers KV Storage: EditSessions (in KV, never D1).
Workers R2 Storage: EditBuckets + the file browser.
User → API Tokens: Edit optionalMints an R2 keypair for you in one click. It's a token-minting permission — leave it out and paste your own R2 keypair instead. Connect works either way.

Every R2 keypair Flarelink mints shows up in your Cloudflare dashboard (named flarelink-r2-…) where you can revoke it any time, and every call made with the token is recorded in Cloudflare's audit log — independent of anything Flarelink reports. Revoke the token and Flarelink loses all access instantly; your deployed backend keeps running. Full detail in the docs.

Security facts

The specifics, stated plainly.

Password hashing

PBKDF2-SHA256, 16-byte random salt, 32-byte key. Iteration count is per-deployment: 100,000 by default (fits the Workers free-tier CPU budget), raisable to 600,000 (OWASP baseline) on the Workers paid plan. Existing hashes upgrade transparently on next sign-in. The exact number is published, not hidden.

Sessions

Stored in Cloudflare KV, never in D1 — auth checks are ~10 ms edge reads. KV is eventually consistent, so sign-out / revocation propagates within KV's consistency window (seconds).

Service key

High-entropy, stored only as a SHA-256 hash on your D1, constant-time compared, shown exactly once, and rotatable. Flarelink keeps no copy of the plaintext.

Cookies

__Secure-…; SameSite=None; Secure; Partitioned. Because that's a cross-site cookie on a workers.dev URL, Safari needs the auth Worker on a custom domain on your app's own domain in production — surfaced in the dashboard + docs.

What we store

Your CF API token (AES-256-GCM encrypted) and a SHA-256 hash of the service key. Nothing else — every other secret (auth secret, OAuth credentials, R2 keys, email config) lives in flarelink_config on your D1.

No telemetry

The auth Worker makes no outbound calls except to R2 (S3 API), Cloudflare Email / Resend (if you configure email), and your OAuth providers. No analytics, no phone-home. Auditable in the public source.

Disclosure

Found something? Tell us.

Email [email protected] with [SECURITY] in the subject. Each public repo also carries a SECURITY.md with the same contact. We'll acknowledge and work the issue with you; please give us a reasonable window before public disclosure.