What happened
Netlify announced that new teams on its credit-based Free, Personal, and Pro plans start with private projects by default, no matter how you deploy: connecting a GitHub repo, dragging files into Netlify’s dashboard, using its command-line tool, or through an AI agent. Nobody can open the live URL unless they sign in as a team member or an invited collaborator.
The automatic default applies to new teams on Netlify’s credit-based plans. Existing teams can opt in. Enterprise, open source, and older legacy plans use their existing access controls instead of these project-visibility settings. Existing projects keep their visibility under the default for new projects; the separate all-projects policy can restrict them too.
If you’re on an eligible plan and already have a team, you can choose private defaults or keep public-by-default behavior. Go to Team settings > General > Visitor access > Default project visibility and pick “Public,” “Private for new projects,” or “Private for all projects.”
What “private” actually means here
A private project sits behind a Netlify login. Team members and anyone you’ve invited can sign in and view it normally. Everyone else lands on a Netlify page telling them they don’t have access, with an option to request it from you. There’s no separate password to create, share, or accidentally leak.
Netlify built this because so much of what gets deployed today isn’t a finished product. It’s a prototype, an internal tool, or an early client build, often assembled quickly with an AI coding agent. Those are exactly the kind of projects that used to sit on a public URL by accident, reachable by anyone who guessed or found the link, until someone remembered to lock it down.
The gotcha: making a project public doesn’t expose everything
If you do flip a project to public, only the live production version becomes visible. Netlify’s deploy previews, the temporary preview links it generates automatically for each change before you make it live, stay private unless you open them up separately. That’s a safer default, but it also means “public” and “fully visible” aren’t the same setting anymore. Don’t assume that sharing your production URL also shares every preview link tied to that project.
On Free and Personal plans, a private project is visible only to you, since those plans don’t support inviting collaborators. Pro plans allow unlimited collaborator invites, so a private project there can still be a real team workspace.
Who should care
This matters most if you regularly ship early-stage work: internal tools, client prototypes, or anything built fast with an agent that you didn’t intend for the public internet yet. It matters less if everything you deploy is meant to be public from the start, or if you’re on an Enterprise or legacy plan where nothing has changed.
What builders should do next
If you’re starting a new project today on an eligible plan, don’t assume it inherited your team’s usual behavior. Open Team settings > General > Visitor access > Default project visibility and confirm it’s set the way you expect, especially if you’re used to Netlify projects being public by default.
Before you share any project URL, whether it’s brand new or one you’ve had for a while, check that specific project’s visibility rather than trusting the team-wide default. Netlify’s current visibility documentation distinguishes two private policies. “Private for new projects” leaves existing projects unchanged; “Private for all projects” locks existing projects to team login too.
The real habit worth building is checking visibility before you send a link, not after. A private-by-default project protects you from forgetting to lock something down. It doesn’t protect you from assuming a project is private when it was actually made public earlier, by you or a teammate, for a reason nobody wrote down.
End of article