Security and product model

Built for teams that need to find secrets without exposing them casually.

Secure Vault keeps the product scope intentionally narrow: password folders, saved credentials, ENV projects, variables, notes, import, export, and account security. That makes the app easier to reason about and easier to operate.

Trust boundaries

What is protected, and how.

Vault values

ENV values and saved passwords are encrypted with server-side AES-GCM before storage.

Hashed gates

Account passwords, vault keys, and reset tokens are hashed before storage.

Reset tokens

Generated securely, stored as hashes, and expired quickly.

Project access

Every project and variable request is scoped to the authenticated owner.

Realtime

Supabase Realtime refreshes active vault views without making the client the source of truth.

Migrations

Drizzle schema and generated SQL keep the database contract visible in code.

Practical use

A vault per project keeps context clean.

Use one vault for production, another for staging, and another for local development when the values or access patterns differ. That avoids the classic problem where a single shared file holds every secret for every environment.

Notes sit next to keys so rotation dates, service owners, deployment targets, and integration details do not disappear into old tickets or message threads.

What Secure Vault does not pretend

Hashing is used for account passwords, vault keys, and reset tokens because those values should never be recovered.

ENV values and saved passwords are encrypted instead of hashed because users need to reveal, copy, and export or use the original values later.