How we handle your data (and what you should not share)

What we do

Vibe Coding Profiler connects to GitHub, fetches commit history, computes metrics, and stores the results in Supabase Postgres. Access to rows is scoped to your authenticated account via Supabase Row Level Security (RLS) policies for user-facing reads.

The worker that performs analysis uses a server-side Supabase key (service role) and is able to write job outputs. This is powerful by design; it is kept server-side and is not intended to be exposed to browsers.

What we store

Today, the analysis pipeline persists both raw-ish inputs and derived outputs so we can reproduce charts and narratives for a completed job.

• Repo identifiers you connect (owner/name + GitHub IDs).
• Commit metadata used for analysis: SHA, commit message, timestamps, parent SHAs.
• Commit-level summary stats from GitHub: file count, additions, deletions.
• Derived outputs: metrics, events, and narrative/insight JSON tied to a job.

Note: when fetching commit details from GitHub, the API response can include file paths and diff snippets. Vibe Coding Profiler’s current worker extracts and stores counts/stats (like number of files and additions/deletions), not file contents.

How credentials are handled

GitHub OAuth tokens are encrypted before being stored in the database using application-layer encryption (AES-256-GCM). Decryption happens server-side when the backend needs to call GitHub on your behalf.

If you are self-hosting, treat the encryption key and Supabase service role key like production secrets. If those secrets are compromised, an attacker could potentially decrypt tokens or bypass row-level restrictions.