[Support Guide] Access control options for your Netlify sites

Last reviewed by Netlify Support: January 2022

You’ve got an awesome Netlify site. Maybe you’re pre-launch, or maybe you’re working on a new beta version in a branch. Maybe it’s a site intended only for a limited audience, such as your co-workers. Regardless, you want to limit access. This article is a guide to what facilities are available and how you might use them.

Our most flexible and performant protection is our Identity service. This is very flexible, featuring:

Simpler but still somewhat flexible is configuring HTTP Basic Authentication via our custom headers facility. Additional flexibility is that you can configure multiple username/password pairs (and change some or all of them with a new deploy), and you can scope this protection to specific paths or assets - put a password on accessing the spreadsheet but not the webpage linking to it, or serve an unauthenticated landing page on the same site where all the real content is protected. Something to keep in mind is that this method is set per deploy, and since we have atomic deploys, you cannot apply it to past deploys, or remove it from deploys that had it enabled accidentally. Assets protected in this way require authentication to be done at our CDN Origin (on the west coast US as of this writing) for each asset loaded, meaning that those assets will not perform as well as one that can be serviced directly from our CDN node cache, closer to the browser.

Simplest, and least flexible, is the “nuclear option”, Site wide password protection. This is setting a single password through our UI, which will protect every deploy for the site - past, present, and future (unless/until you disable the feature). You will need to find a way to share this password with your visitors, and if it leaks, you will need to change it and repeat the process. This option also requires authentication to be done at our Origin for each asset loaded, meaning that your entire site will not perform as well as one that can be serviced from our CDN node cache, closer to the browser. This can be turned on and off instantly through our UI or API as needed.

A related article is this guide to creating Build-context-specific settings, including HTTP Basic-Auth passwords, where we go into a lot of details about how to password protect “groups” of builds - only specific branches, only PR’s, etc.

We do know there are other types of password protection that folks want - retroactively applied to production deploys that aren’t published, for instance - and we don’t have a perfect way to handle that today. Let us know below what interesting solutions and struggles you have for protecting your content!

1 Like

This is a great explanation for site control. I have one question regrading HTTP Basic Auth. If my code is kept in a public repository, how to I keep the passwords hidden in the _headers file (or netlify_headers for branch builds). Is this only an effective method for private repos? Thank you

1 Like

Yes, since the headers file would need to exist in your repo, it’s only useful for Private repos. Could you explain why you need this for a public repo? I mean, if the repo is public, anyone can clone it and deploy it, thus defeating the purpose of authentication.

Thank you for the answer. That’s what I needed to know. This project will be open sourced so I intend on making the repo public eventually. So I will plan on implementing your identity service long term. Which I on my long term road map. Thank you

1 Like