[Support Guide] Tips & Tricks for browsing different deploys of the same site

Last checked by Netlify Support: May 2024

Did you know that as of this writing Netlify keeps a copy of every deploy you’ve ever made of your site for 90 days by default. This guide will explain the various types of deploys and how to access them.

The main deployment that most customers use is their current, published, production deploy. This is what loads by default when you go to https://yoursitename.netlify.app or any of your custom domains or domain aliases - DNS names that you configure and we serve your content for. If you want to consider instead what is published and how, here are the docs you should read:

  • locking deploys allows you to configure a specific deploy to stay published, despite other, newer, production deploys.
  • deploy contexts describe the type of deploy - is it a production build (from your main/default branch, as shown in the deploy settings)? Or perhaps a deploy preview, which is a build from a Pull or Merge request. There are also contexts for “all branch deploys” or “deploys from specific non-production branch X” - which can all be configured differently per context - from different variables and versions used during build, to different build commands and API endpoints.

For this guide, I want to focus on what we see on the Deploy Listing page for a site. Here’s a screenshot of one of mine:

While you can click on any of those “rows” to see the deploy logs, let’s talk through the wording and other links available!

  1. This shows a non-git-triggered deploy. This could come from a webhook, an API call directly to our deploy endpoint from you or some integrated software other than your git provider, or from someone hitting the “Trigger deploy” button in our UI for the site. It uses the production context and was built from source code cloned from git - the “master@HEAD” is a designation of the branch built. This is for the production context, and was a more recent build than #2, but is NOT live at the production URL.
  2. This is the currently published build. Note that there is a newer build that would be published by default but is not in this case, since I have “locked” this published deploy. You can publish and then lock any deploy - including a Deploy Preview, Branch Deploy, etc - and it will be live at your production URL, until/unless you unlock.
  3. This shows a build of a Pull Request or Merge Request from GitHub or GitLab. These are built separately as you may want to use a more rigorous testing process or apply other non-production config like a staging API endpoint. They can also be configured differently for open repos in case you need to put extra controls on what external contributors are allowed to do by default
  4. A branch deploy is a build on a non-production branch that is NOT a PR or MR. If you click on the “Branch Deploy” label, you will be shown the latest successful deploy on that branch - which may not be the deploy you clicked on if there are newer builds - but will be the latest successful build on its branch. If you look at the URL, it will look like either: https://branchname--yoursitename.netlify.app or https://branchname.yourcustom.domain - so those are handy shorthand for accessing such builds! (if branchname.yourcustom.domain doesn’t work, check out this article about this feature for guidance).
  5. this is a link to the commit (and its branchname + commit ref) at your git provider. Handy for going straight to the code that was built! Note that for builds not triggered from git, which are indicated as in #1, this reference goes to the latest commit in the repository, rather than the specific commit that was latest at the time of the build.
  6. this is a permanent link to that individual deploy. It will be valid until the deploy isn’t deleted, and will be an exact snapshot at that point in time apart from the CDN-level changes that we might make. Great for comparing changes over time or pointing out a regression: “you can see here that this layout changed between last tuesday’s build and today, by browsing both in parallel”.

Please follow up below with any questions you have about how to access previous deploys or your specific situation. Thanks!