Support Forums

[Support Guide] Access control options for your Netlify sites

Last reviewed by Netlify Support: July 2021

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!