How vvault protects your unreleased music
Unreleased beats are the most sensitive thing a producer owns. Here, plainly, is how vvault protects them, including what we haven't done yet.
Nothing is out there until you decide
Everything you upload starts private. It isn't reachable, listed or indexed anywhere until you share it.
When you do, you choose how far it goes. Inside a pack, the pack decides: anyone who can open it can play every beat in it. A track's own link keeps its own setting, so sharing a pack never opens up each beat's own link.
- Every upload starts private
- Four levels: private, invite only, anyone with the link, for sale
- A link you haven't created doesn't exist
Sign in without a password
vvault doesn't ask for a password: you sign up and sign in without one, so there's nothing to reuse across sites or to leak in someone else's breach.
A code instead of a password
Sign in with a one-time code sent to your email, or with Google or Apple. Accounts opened back when vvault had passwords can still use theirs.
Codes that can't be guessed
Codes expire, stop working after a few wrong tries, and are rate limited per IP address, so nobody can try them all.
A second step if you want one
In Settings, Security & privacy, add your phone number. From then on, signing in also asks for a code sent by text, on the web and in the iPhone app.
A PIN in your browser
Lock vvault in your browser with a PIN, so an open laptop isn't an open vault. The PIN is hashed with scrypt and its own salt, and checked on our server, never in your browser.
Your audio never sits at a public address
Your files live in private storage. No beat of yours has a public address that could be guessed, scraped or passed around by accident.
Every play and every download goes through a signed link that expires. Once it expires it stops working, so an address copied out of a browser is not a key to your master.
The database says no, not just the screen
Hiding a button is not security. vvault's access rules are enforced by the database itself (row level security in Postgres), underneath the app. A request for something you may not open comes back empty, whoever asks and whatever the screen did.
That's why a private track's own link stays closed, even when the track sits in a pack you've shared: inside the pack, the pack's setting decides.
Where your music is stored
Everything travels encrypted (TLS), and files and the database are encrypted where they are stored (AES-256): that's how Supabase, which hosts them, encrypts all its customers' data.
| What | Run by | Where |
|---|---|---|
| Your beats, covers and account | Supabase, on Amazon Web Services | European Union |
| The website and the app | Vercel | European Union for your requests, a company in the United States |
| Emails vvault sends for you | Resend | United States |
| Payments and payouts | Stripe | Ireland and the United States |
The full list, with the legal basis for every transfer outside the EU, is on the sub-processors page.
What vvault doesn't have yet
Security pages usually list only wins. Here is what vvault doesn't have, so you can judge the rest of this page knowing the gaps.
No outside penetration test
No outside firm has attacked the platform yet. When one does, this page will say who and when.
No SOC 2 or ISO 27001
vvault hasn't been through either audit yet.
No bug bounty
And no automated threat monitoring service. Every report goes straight to the vvault team.
No end-to-end encryption of your files
Your files are encrypted where they are stored, but vvault's systems can open them: that's how a beat plays for the people you send it to.
Found a vulnerability?
Email contact@vvault.app with enough detail to reproduce it. It goes straight to the vvault team.
We won't pursue anyone who reports a real issue in good faith. Give us a fair chance to fix it before you publish, don't open or change anyone else's data while testing, and don't run tests that slow vvault down for others.
Sources
Where the facts on this page come from.
- Supabase, Security: data encryption (AES-256 at rest, TLS in transit)
- Supabase documentation, serving private files through signed URLs that expire
- PostgreSQL documentation, row security policies
- RFC 7914, the scrypt password-based key derivation function (IETF)
- vvault sub-processors: who runs what, and where
Read next
Your data and the GDPR
What vvault collects and why, where it's stored, and how to get a copy or have it deleted.
Read
How to keep unreleased music private
Send links instead of files, choose who can open each beat, and close access when you're done.
Read
How vvault protects your account
What already protects your account, and a five-minute checklist to lock it down.
ReadNever wonder who listened again.
Pro or Ultra, monthly or yearly. Cancel anytime.
Photos: Nathan Thomas, cottonbro studio, Brett Sayles, Raul Ling and George Becker on Pexels