// security
Beaam asks for read-only credentials to your production stack. That deserves a straight account of how they are handled and what happens when something goes wrong.
Monitoring is intrusive by nature: to tell you your database is struggling, something has to be allowed to look at your database. The honest framing is not "Beaam is secure" but "here is exactly what Beaam can do, and what an attacker would get if they took it."
Everything below is implemented, not aspirational. Where a control does not exist, this page says so.
Beaam never writes to a connected provider. There is no code path that mutates your infrastructure — no restarting instances, no scaling, no remediation. If it could act on your stack, a compromise of Beaam would become a compromise of your production; it cannot, so it does not.
You are never asked to create a user or paste a credential that cannot be rotated from your side, because a credential you cannot revoke is one you have lost control of. Each integration documents the narrow read scope it needs and nothing wider, and where a provider supports role assumption with an external ID rather than a long-lived key, Beaam uses it.
Integration credentials are encrypted with AES-256-GCM through the Web Crypto API before they reach the database. The key lives as a Cloudflare Worker secret and is never exposed to browser code. Decryption happens server-side, in the collection path, and nowhere else.
Disconnecting an integration deletes its credentials immediately rather than marking a row inactive.
Earlier builds used XChaCha20-Poly1305 via libsodium. That was replaced because Cloudflare Workers block runtime WASM compilation, and existing rows were migrated in one shot. This page previously still named the old cipher — a stale claim, corrected on 28 July 2026.
Row Level Security is on for every table, and every policy scopes rows to your organization membership. This matters more than it sounds: isolation enforced in application code fails whenever a single query forgets a where clause. Enforced in Postgres, a forgotten check returns nothing rather than someone else's data.
The service role that can bypass RLS exists only in server-side code — it is never shipped to the browser, and the one permitted direct use of the database from a page is reading the current session.
Beaam calls endpoints you supply: HTTP checks, MCP servers, Slack webhooks, your own webhook receivers. That is a server-side request forgery surface, and it is treated as one. All of them pass shared controls on scheme, port, DNS resolution, redirect following, private-network ranges, request duration and response size — so a URL pointing at internal metadata services or a rebound DNS name does not become a way to make Beaam fetch something on an attacker's behalf.
The watchdog runs on a separate cloud account with its own secrets and its own state, sharing no database, no deploy pipeline and no failure domain with the application. This is the difference between a real control and a diagram: a watchdog inside the system it watches goes down with it, precisely when you need it.
It probes the application, collection freshness, the marketing site and alert delivery every minute, and alerts Beaam's operator if the service goes quiet. It is an operational control on the platform, not a per-customer notifier — what reaches you directly is the daily heartbeat and per-account silence detection on your own collectors.
Paid entitlements change only from a verified Polar webhook. There is no client-side upgrade path and no debug route that promotes an account — a browser-side toggle that grants a paid tier is a revenue bug and a security bug at once.
Raw metric samples expire after 30 days in both stores, enforced by a scheduled prune in Postgres and a TTL in the telemetry store. Incidents, alerts and delivery records are retained while your account is active, because that history is what you look back at after an outage. Deleting your account removes your identity and control-plane records immediately.
Every processor is listed publicly on the subprocessors page, along with its data-processing agreement status. Traffic on this marketing site is measured with Plausible — cookieless, EU-hosted, no cross-site identifier, and no IP address stored. There are no advertising networks, no tracking pixels, no session recording, and no cookies beyond the session cookie in the app.
Email support@beaam.app with “Security” in the subject. It reaches the person who wrote the code. Please do not include credentials or production data in a first message. We will acknowledge, and we will tell you honestly if something is a known limitation rather than a finding.
Read-only, always. Beaam never writes to a connected provider. Most integrations take a read-scoped API token you create in the provider and can revoke at any time; where a provider offers something narrower — an assumable role with an external ID rather than long-lived keys — Beaam uses that instead.
Encrypted with AES-256-GCM via the Web Crypto API before they reach the database, using a key held as a Cloudflare Worker secret that is never exposed to browser code. They are deleted the moment you disconnect the integration.
Row Level Security is enabled on every table and every policy is scoped to organization membership, enforced by Postgres rather than by application code. A missing check in a query cannot leak another tenant's rows.
Deleting your account removes your authentication identity and control-plane records immediately, and foreign-key cascades take your telemetry with them. Raw metric samples expire after 30 days regardless.
No. We will say that plainly rather than imply otherwise with security-theatre language. SOC 2 is out of scope until an enterprise customer needs it. If it is a hard requirement today, Beaam is not the right fit.
This page describes implemented controls, not a certification claim.