Project visibility settings decide who can find, open and act on a project. For an audio studio, the safe default is simple: keep every project private, invite people by name or by a protected link, and give each person the smallest role that lets them do their job. A client who only needs to hear a mix and leave notes should never be able to download stems, see other clients, or delete a file.
This guide explains the standard visibility levels, how they map to mix, mastering, podcast and post work, and how to set them without slowing clients down.
TL;DR
- Most platforms use three visibility levels: private, internal and public. For client work, private is almost always the right choice.
- Visibility (who can see a project) is different from permissions (what a person can do inside it). Set both.
- Give clients a viewer or commenter role by default. Editor access is rarely needed.
- Add layers: a password, download controls, and payment or approval before final files unlock.
- Review settings at the start of every project and again at delivery.
Table of Contents
- What project visibility settings actually control
- The three standard visibility levels
- Visibility is not the same as permissions
- Settings to check on every project
- Match visibility to the type of project
- Add layers beyond the visibility toggle
- Control the end of the project, not just the start
- Common mistakes
- Our perspective
- Setting this up in Audome
- A simple visibility policy you can copy
- FAQ
- Sources
What project visibility settings actually control
Visibility answers one question: who is allowed to see that this project exists and open it. It sits above everything else. If a project is public, role settings inside it matter far less, because anyone can reach it.
It helps to separate three ideas that tools often blur together:
- Visibility: who can discover or open the project at all.
- Roles and permissions: what each invited person can do once inside (stream, comment, download, upload, delete).
- Link and delivery controls: passwords, download blocking, expiration, and payment gates on a specific shared link or file.
Most confusion comes from mixing these up. A project can be private, yet a client with an editor role can still wipe a folder. A project can have a perfect role setup, yet a public link forwarded to a label’s whole A&R team makes the roles irrelevant.
The three standard visibility levels
Many collaborative platforms use the same three tiers. GitLab’s documentation describes projects and groups as private, internal or public. In that model:
| Level | Who can access | Typical use in audio work |
|---|---|---|
| Private | Only people explicitly invited | Unreleased mixes, masters, client stems, session files |
| Internal | Any signed-in user of the same platform or instance | A studio’s own team space, shared reference libraries |
| Public | Anyone, often with no sign-in | Portfolio pieces, released work, sample packs you want found |
GitHub’s project documentation is simpler: it offers public or private only. So the exact wording varies by tool. Check what each label means in the product you use before you trust it.
Private is the most restrictive level and the right default for sensitive production work. Public is for work you are happy to see passed around.
Why “internal” is a trap for studios
Internal sounds safe, since it is not fully open. But it means anyone with an account on that platform or instance can reach the project. On a large shared platform, that could be a huge number of strangers. It suits a company’s own tools. It rarely suits client audio, where the point is to keep unreleased work away from everyone but a short list of people.
Visibility is not the same as permissions
Once a project is private, the next decision is what each invited person can do. Role-based access control handles this. Wubble’s collaboration documentation shows a typical structure: an owner with full control, including permanent deletion and management of all collaborators, and lower roles with narrower rights. Across music platforms, the common set is owner or admin, editor, commenter and viewer.
Here is how we would map those roles to a real studio:
| Role | Can do | Give it to |
|---|---|---|
| Owner / admin | Everything: delete, invite, change settings | You, and a business partner if you have one |
| Editor | Upload, replace and edit files | Other engineers, assistants, a co-producer |
| Commenter | Stream and leave feedback | Clients, artists, A&R, show hosts |
| Viewer | Stream or preview only | Managers, lawyers, people who only need to listen |
The idea behind this is least privilege: grant only the access a person needs. NIST’s security guidance (SP 800-171r3) is written for protecting sensitive government information, but the principle carries over to a studio. Less access means fewer accidental deletions, fewer overwritten files and fewer leaks of unfinished work.
Clients almost never need editor access. Wubble’s guidance reflects the same view: keep clients to viewer or commenter, since broader permissions cause accidental edits and deletions of work in progress.
Settings to check on every project
Before you send a link, run through this list. It takes about a minute.
- Is the project private? If you did not choose, confirm what the default is.
- Who is invited, and with what role? Remove anyone who has finished their part.
- Does the link need a password? Yes for anything unreleased. Send the password through a different channel than the link.
- Can people download? For review rounds, streaming and commenting is usually enough. Lock downloads until the work is approved.
- Do clients need an account? Every extra step costs you feedback. If a tool can avoid logins, that helps response times.
- Is there a gate on final files? Payment or approval before download protects you from handing over masters early.
- Is the audio quality adequate for review? If you share lossy previews, say so, and keep full-resolution files for delivery.
Match visibility to the type of project
Different audio work needs different settings. These are starting points, not rules.
Mixing and mastering for artists
Keep everything private. Invite the artist and, if needed, their manager as commenters. Streaming only during review, with downloads off. Unlock the final master after payment or sign-off. If the artist’s label wants to hear it, add them as a viewer instead of forwarding a link.
Podcast production
A podcast often has several parties: hosts, a producer, sponsors who want to hear their reads, and sometimes legal. Give hosts commenter access, sponsors viewer access, and keep raw recordings in a private area only your team can reach. Public visibility only comes after the episode is released, if at all.
Audio post-production
Post work often carries the highest confidentiality, since picture, dialogue and music may be under contract with the production. Keep projects private, use passwords, restrict downloads, and keep a clear list of who has access. Check your contract: it may set requirements you must meet regardless of your tool.
Recording studios with multiple engineers
Use roles to separate duties. The studio owner is admin. Engineers get editor access on their own projects only. Interns can be viewers. This keeps a mistake in one session from reaching another client’s files.
Portfolio and demo work
This is where public makes sense. Use a separate, clearly labeled space for released tracks or approved work, and never put a client’s unreleased project there. Get the client’s agreement before publishing anything, even finished work.
Add layers beyond the visibility toggle
A visibility setting is one lock on one door. Treat link and delivery controls as extra locks. Passwords, download blocking and link expiration are secondary layers. They reduce risk but do not replace a sound setup underneath.
NIST’s bulletin on exchanging files over the internet points the same way for sensitive exchanges: favor tools with integrity checking, audit logging of access and encrypted storage over loose email attachments and unmanaged cloud folders. You do not need a government-grade setup to apply the idea. Ask whether you can see who opened a file, and whether files travel and sit encrypted.
We have written more on each layer if you want to go deeper:
- Secure file sharing for engineers covers what works and what does not.
- Password-protected downloads compares five methods, from ZIPs to signed URLs.
- The role of privacy in studio collaboration explains why clients care about it.
- File sharing methods for studios lays out the wider options.
Control the end of the project, not just the start
Visibility settings often get set once and forgotten. The riskiest moment is delivery, when final files are ready and the invoice may not be paid. Two settings help here.
Hold final downloads until payment clears. This is a business setting as much as a security one. We cover the reasoning in locking masters until payment clears.
Require approval before download. If your contracts call for sign-off first, see approval before download.
After delivery, tidy up. Remove collaborators who are done, archive the project, and decide whether the link should still work. A link that stays live for years is a leak waiting to happen.
Common mistakes
- Using a public link because it is quick. It is quick for everyone, including people you did not intend.
- Giving clients editor access “just in case.” Start low and raise access only when there is a reason.
- Sending the password in the same message as the link. If one is intercepted, so is the other.
- Never removing old collaborators. Former assistants and past clients should not see new projects.
- Assuming the label means the same thing everywhere. “Internal,” “unlisted” and “shared” differ from tool to tool. Test with a second account or a private browser window.
- Skipping the test. Open your own link while logged out. If you see more than a client should, change it.
Our perspective
We built Audome for people who run audio businesses, so we look at visibility as part of how a studio works, not as an IT chore. Most of the trouble we hear about does not come from hackers. It comes from scattered files: a mix in one drive, notes in a text thread, a master sent early over email, a link that never expired.
Our view is that a studio should keep each project private by default and make access easy for the client, not hard. That is why clients can collaborate without creating an account, and why projects can sit behind password-protected pages and private client portals. Download controls let you decide when files leave the page. For studios that want to get paid on time, final downloads can be held until payment clears through Stripe Connect.
We also think visibility and revision boundaries belong together. When a client can only hear and comment, and each round of feedback is tied to a version, it is easier to see what changed and when. Studios can set a number of included revisions and charge for extras, which gives everyone a clear frame. Clear access leads to clearer feedback.
One last point: you should not pay more as your circle of people grows. Collaborators and projects are unlimited, so you can invite the whole team without counting seats. See why we skip seat math.
— Kreg
Setting this up in Audome
If you want these controls in one place, Audome gives you private client portals, password-protected project pages, download controls and no-login client access, along with timestamped feedback on the waveform and version tracking. Files upload at up to 96kHz/24-bit. Pricing is published on the Audome pricing page: Studio is $12.50 per month or $150 per year, and Pro is $48 per month or $576 per year. You can also look at the Audome homepage for an overview.
For how this fits into a full job, from kickoff to delivery, read our project collaboration workflow guide.
A simple visibility policy you can copy
Write this down once and reuse it for every job. It takes five lines.
- All client projects are private.
- Clients get commenter access. Their managers and labels get viewer access.
- Every unreleased project link is password-protected, and the password goes by separate message.
- Downloads stay off until final approval or payment.
- At delivery, remove finished collaborators and archive.
A written policy also helps when a client asks how you protect their work. You can answer in one breath, and it shows you take their music seriously.
FAQ
What is the difference between private and public project visibility?
Private means only people you explicitly invite can open the project. Public means anyone can reach it, often without signing in. For unreleased client work, choose private. Reserve public for released or approved work you want people to find.
Should clients be able to download files during review?
Usually not. Streaming and timestamped comments are enough to approve a mix, and keeping downloads off means unfinished versions do not circulate. Turn downloads on for the final files once the client has approved or paid, depending on your terms.
What role should I give a client on a shared audio project?
Commenter or viewer. Clients rarely need to upload or edit, and a lower role prevents accidental deletions. If a client needs to send you files, such as stems or reference tracks, use an upload tool built for that rather than full editor rights.
Is a password on a link enough to keep a project secure?
It helps, but it is a secondary layer. Pair it with a private project, a limited role and download controls. Send the password separately from the link, and remove access when the project ends.
How do I check who can see my project?
Open the project link in a private browser window without signing in, and review the list of invited people and their roles. If you can see or do more than a client should, tighten the settings. Repeat the check at delivery.
Sources
- Project and group visibility, GitLab Docs
- Managing visibility of your projects, GitHub Docs
- Team Collaboration – Projects, Wubble Documentation
- NIST SP 800-171r3, Protecting Controlled Unclassified Information
- NIST ITL Bulletin, Security Considerations for Exchanging Files Over the Internet