Security & Trust Model
FlareWatch deploys resources into your Cloudflare account, then those resources run there.
How Cloudflare access is handled
You connect through Cloudflare OAuth. There is no API token to create or paste.
FlareWatch stores only an encrypted refresh token. It never stores a long-lived API token.
At deploy time, the access token is minted server-side from the refresh token. It is short-lived and never sent to your browser.
You can revoke access any time from your Cloudflare dashboard, or with Disconnect in the wizard. Access is used for deploy, update, and delete operations. It is not part of your deployed runtime.
What is stored during wizard sessions
Session data in wizard KV can include:
- selected account ID and workers subdomain,
- monitor/branding/notification/security selections,
- the encrypted refresh token and encrypted temporary passwords.
Session records use TTL-based expiration and can also be cleared explicitly.
Runtime ownership
After deployment, runtime resources are in your account. Your deployed resources are described in You Own Everything.
Password storage
When auth is enabled, credentials are deployed to your status-page worker as Cloudflare Worker secrets using PBKDF2-SHA256 password hashing (salted; no plaintext password storage in deployed secrets). During wizard setup, temporary password values are encrypted in session KV with a short TTL.
Data flow notes
- Monitor state/history stays in your Cloudflare KV.
- If you configure external webhooks, alert payloads are intentionally sent to those endpoints.
- FlareWatch control-plane availability is not required for already-deployed workers to serve traffic.