How to Keep Unreleased Music Private

Almost no unreleased track leaks because somebody broke encryption. It leaks because a link was forwarded, a shared folder had one more person in it than anyone remembered, or a file sat in a chat thread long after the conversation ended. The threat is not a hacker. It is ordinary sharing, working exactly as designed.

The real risk is the link, not the server

A general-purpose cloud drive gives you one blunt instrument: a link that works for whoever holds it, forever, with no way to tell who opened it. Send that to an A&R and you have also sent it to everyone they forward it to. You will not know, because the link cannot tell you.

Anything you share should answer three questions: who can open this, for how long, and what happens if it gets passed on. If your current setup cannot answer them, that is the gap.

Start private, publish on purpose

The single most effective habit is defaulting to closed. In vvault everything you upload is private until you decide otherwise — nothing is reachable, listed or indexed by accident. When you do share, you pick how far it goes: invite only, anyone with the link, or for sale.

A track’s own link and the pack it sits in are governed separately, which matters more than it sounds. Publishing a pack never quietly publishes the individual track links inside it. You can put a private track in a pack you send out and its own link stays closed.

Audio should not live at a guessable URL

Plenty of platforms serve audio from a public address. Anyone who finds that address has the file — permanently, whatever the page around it says. vvault keeps audio in a private bucket and serves every play and download through a signed link that expires, so a URL copied out of a browser’s network tab is not a permanent key to your master.

Access rules belong in the database, not the interface

Hiding a button is not access control. vvault’s rules are enforced by row-level security policies in Postgres, underneath the app: a request for something you may not have returns nothing, whoever is asking and whatever the interface did. That is the difference between a control and a suggestion.

Lock the app, not just the laptop

Most leaks from a studio are not remote. They are an unlocked laptop in a room with other people. You can set a PIN that locks vvault itself, so an open browser is not an open vault. The PIN is hashed with scrypt and checked on the server; it is never stored anywhere it could be read back.

Sign-in has no password to steal — a one-time code, Google, or Apple — and you can add a second factor from Settings.

What no platform can do for you

Being straight about the limits: once someone can hear a track, they can record it. No platform prevents that, and any platform claiming otherwise is selling you something. What good tooling does is narrow who ever gets that far, and tell you who did.

Two more limits worth knowing about vvault specifically: messages sent from the web app are encrypted in transit and at rest but are not end-to-end encrypted — that is iOS only — and we have not yet had an external firm penetration-test the platform. Both are on our Trust & Security page, which lists what we do not have alongside what we do.

A short checklist

Default everything to private. Share to named people when you can, and by link only when you must. Prefer links that expire over links that live forever. Turn on a second factor and a PIN. And before you send anything, ask what happens when it gets forwarded — because it will.