Netlify Now Makes New Projects Private by Default

What happened

Netlify announced that new projects on its current Free, Personal, and Pro plans are now private the moment you create them, 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.

This only applies going forward, and only on Netlify’s newer plans that charge by usage credits instead of a flat monthly tier. Enterprise, open source, and older legacy plans keep the old behavior, where a new project is public the second it deploys. Any project you already have stays exactly as public or private as it is today.

If you’re on an eligible plan and already have a team, you can still choose the old 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. A team setting change only affects new projects going forward, not the ones you built last month.

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