Data-flow description

Dated 17 September 2026. Next review by 19 March 2027.

The current version is on our security page: https://barrierops.com/security#data-flow.

  1. A visitor loads this site: barrierops.com, served by Cloudflare Workers static assets. The pages are static files; a form you submit goes to our API through a Cloudflare Worker that keeps nothing. Every page but the barrier-report pages and the error pages also loads Google Tag Manager and the Cookiebot cookie banner, from Google and Usercentrics, as the privacy notice describes.
  2. A signed-in user loads the application: app.barrierops.com, a static single-page bundle served by Cloudflare Workers static assets.
  3. The application calls the API: api.barrierops.com, on a Vultr cloud instance in New Jersey.
  4. Sign-in redirects to the identity provider: WorkOS AuthKit. The application never renders a credential field and never sees a password.
  5. The API reads and writes the database: Vultr Managed PostgreSQL 18 in New Jersey, over a connection that requires TLS.
  6. A scan job runs in a worker: A Vultr instance in New Jersey fetches your public pages. Each page is scanned in a child process the worker can kill.
  7. Heavy artifacts are written to object storage: Cloudflare R2, in a bucket created in the US jurisdiction. The database stores the object key, never the bytes.
  8. The database is backed up: Automated backups taken by the managed database provider, in the same account and the same region. There is no second copy at a different provider yet — see business continuity below.

Every component above, except the two services from other companies that the marketing site loads, is in the United States: New Jersey for compute, the database and the backups, and a Cloudflare R2 bucket created in the US jurisdiction. Static hosting runs on Cloudflare’s global edge and holds nothing at rest.