What we receive, and what we refuse

VibeBeacon receives stack inventory and account metadata. This page explains the documented payload and what the scanner excludes.

The rule we do not bend

We store package names, versions, ecosystem, framework, runtime, hosting provider and service names, including your dev dependencies (test runners, build tools and the like, scanned by default so you see the same supply-chain risk a tool like Dependabot does). The payload also includes scan date, generator version, app identity, optional group/tags, dependency flags, tool names and workspace counts. No source code, no file paths, no environment values, no keys, no URLs with credentials, no repository URLs, no database names.

The exact JSON we receive

This example shows the manifest shape. Optional metadata is documented in the manifest reference. VibeBeacon authentication travels separately in the request header; it is never part of the scan JSON.

vibebeacon.json

{
  "schemaVersion": 1,
  "generator": { "name": "vibebeacon-cli", "version": "0.1.0" },
  "generatedAt": "2026-09-03T10:00:00Z",
  "app": {
    "name": "My Coffee Shop POS",
    "description": "Orders and payments for one cafe",
    "kind": "web",
    "hosting": ["vercel", "supabase"],
    "aiTools": ["cursor", "claude-code"]
  },
  "runtimes": [
    { "name": "node", "version": "22.11.0" }
  ],
  "frameworks": [
    { "name": "next", "version": "15.1.0", "ecosystem": "npm" }
  ],
  "dependencies": [
    { "name": "react", "version": "18.3.1", "ecosystem": "npm", "direct": true, "dev": false },
    { "name": "stripe", "version": "17.4.0", "ecosystem": "npm", "direct": true, "dev": false }
  ],
  "services": [
    { "name": "stripe" },
    { "name": "supabase" }
  ],
  "infrastructure": [
    { "name": "postgres", "version": "16" }
  ]
}

Field by field notes live in the manifest format reference.

What we store, and what we never see

We store

Package names and reported versions, with direct, development and resolution flags
The ecosystem for each package, such as npm or PyPI
Runtime and framework versions, such as Node 22.11.0 and Next 15.1.0
Hosting provider names, such as Vercel or Fly
Service names, such as Stripe or Supabase
Your email address and app identity, optional groups and tags
Scan date, generator version, tool names and workspace counts

We never see

Your source code
Your .env files. The CLI will not open them
Application secrets, passwords or connection strings in scan payloads
File paths, repo URLs or database names
Your customers, your data or your traffic
Access to your GitHub, your host or your database

It refuses to read .env files

This is not a policy, it is behaviour. The scanner has an allow list of files it opens.

Files it opens

package.json and the lockfile
requirements.txt, poetry.lock, uv.lock, Pipfile.lock
go.mod, Cargo.lock, Gemfile.lock, composer.lock
.nvmrc, .node-version, .python-version
Dockerfile FROM lines, vercel.json, netlify.toml

What it will not do

Open .env, .env.local or any file matching .env*, even when you ask it to
Read source files, migrations or SQL
Send file paths. Only the manifest file name travels
Send anything at all without the --upload flag

Belt and braces on our side too

Before anything is written to the database, the server scans every string for secret shapes: AWS keys, sk_live_ and ghp_ prefixes, JWT shapes, long hex or base64 runs, password= and credentials embedded in URLs. A manifest that trips any of these is rejected with an error naming the field. It is never stored, not even to log the failure.

What we delete, and when

Deletion is real deletion from the primary database. Encrypted backups roll off within 30 days.

Data	How long we keep it	When it goes
Groups and tags	Group names, slugs and tags are not encrypted by the application	Tags go with the app. Groups remain until removed or the account is deleted.
Authentication records	Session tokens, expiry, IP address and browser information; linked sign-in and passkey records	Sessions expire or can be revoked. Account deletion removes linked authentication records.
Manifests you upload	The latest 12 versions per app	Older versions are deleted nightly. All of them go the moment you delete the app.
App name and description	While the app exists, encrypted	Deleted with the app. Stripped out of the stored manifest as well.
Component list (names and versions)	While the app exists, not encrypted	Deleted with the app, immediately, not on a schedule.
Alerts	While the app exists, so you can see what was fixed and when	Deleted with the app.
Email delivery records	90 days	Kept only to prove an alert was sent and to handle bounces. Then deleted.
API keys	SHA-256 hash plus the first 14 characters, while the key is active. The name you gave the key is encrypted.	Revoke removes the hash. We never hold the key itself.
Account and email address	While your account exists, encrypted	Delete your account and everything above goes within 24 hours.
Billing identifiers	The Stripe customer and subscription ids, encrypted, while your account exists	Deleted with your account. Card numbers never reach us at all.
Server logs	14 days	IP address and request path only. No request bodies are logged.

What you can do at any time

See everything we hold

Each app has a page listing every component we have on file, and every manifest version we received.

Delete an app

One button. Manifests, components and alerts go with it, straight away.

Delete your account

Removes every app, every alert and your email address within 24 hours. No exit survey, no retention offer.

Turn email down

Set your severity threshold, change digest frequency, or unsubscribe from the footer of any email.

Revoke a key

API keys are shown once and stored as a hash. Revoking one stops it immediately.

Read the scanner

The source repository is private. The CLI is MIT licensed, and the npm package is readable JavaScript. Read it, or run it without --upload and look at the file first.

Where the data lives, and who sees it

Where the data lives. Postgres hosted in the Sydney region, with full-disk encryption. The app runs on Vercel.

What is encrypted, and what is not. On top of the disk encryption, selected identity and billing fields are encrypted individually, with a key the database server never holds: your email address, your app names and descriptions and their slugs, the labels you give API keys, any quick links you add to an app, and our Stripe customer and subscription ids. Legacy plaintext copies can remain until a separate cleanup step is completed. Your component list (“npm, next, 15.1.0”), the advisories, the alerts and timestamps are not encrypted by the application. Group names, slugs and tags are ordinary database text too; avoid putting sensitive client details in them. These fields and combinations of versions may identify a business or help attackers target it. Session records include tokens, IP addresses and browser information.

Who we share it with. Vercel hosts the app. Neon holds the database. Resend delivers email and receives your address to do that. Stripe receives billing details directly, and we never see a card number. Vercel Analytics records page views on the public site, not account data. Nobody else, and we do not sell or share data for advertising. If that list of processors changes, this page is the notice.

Sign-in. Passwords do not exist here. You get a magic link by email, you sign in with GitHub, or you use a passkey you have added in Settings. The GitHub scope covers your email address only.

Email rules. Security alerts are transactional and go to the address on your account. Anything promotional needs separate consent and has its own unsubscribe. Every email carries one-click unsubscribe headers.

Cookies. One session cookie so you stay signed in. Vercel Analytics is a first-party script on the site; it is not an advertising cookie. No other third-party tracking cookies.

If something goes wrong. If a breach affects your data we email you within 72 hours with what happened and what we did. Exposed inventory, email addresses, app details or account records could help attackers target you. Encryption reduces some risks; it does not make a breach harmless. We investigate the scope, contain the incident and explain the steps affected customers should take.

The full detail. This page covers what we hold and for how long. For how it is protected, encryption, sign-in, transport and infrastructure, read how we protect you.