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:
- different access levels (think: paid customer can access premium content; content editor can access CMS; admins can access all areas)
- authentication at the CDN edge - this is very performant for serving protected content to authenticated users.
- has an API to configure and manage users
- has an invitation/account creation interface that can be exposed directly to your users.
It takes more thought and a bit of effort to set up (start with this great step-by-step blog post), and depending on your use case may require an additional cost atop your Netlify plan. However, it can also be used entirely for free for a smaller user base, which neither of the below can as they both require a Pro or higher plan. This can also be integrated (with some effort) with our SSO login feature. If you’re curious about this, check out a video presenting an example of such a configuration.
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!