Does each "Deploy Preview" stay available forever?

[benwinding]

What happens to old Deploy Preview’s?

We’re a little unsure about what happens after the Pull Request is merged into master. All our previous Deploy Preview’s seem to still be available, even though the branch is merged and they’re no longer relevant… so:

• Do they get deleted after a certain amount of time?
• Is there something we need to configure?
• Are these going to build up and cost more money?

What we’ve tried

• Looked for documentation https://docs.netlify.com/site-deploys/overview/#branch-deploy-controls (not very helpful in determining what actually happens after the merge)
• Deleted the PR branches, so far that hasn’t done anything
• Researched the question (but I was a little confused):
  • How to delete branch deploy?
  • https://stackoverflow.com/questions/49843265/how-to-delete-netlify-deployed-branch

I thought this question deserves it’s own (discoverable) thread, as “Deploy Preview’s” could be viewed as an different feature to your customers (even though they might be implemented the same as regular deploys)

Anyway thanks for an awesome platform, any information is helpful

Cheers,
Ben

[jen]

Hey @benwinding,
Yes, Deploy Previews live forever! Here’s a blog post by our own Phil Hawksworth that says a bit more about the feature and how we think about it:

I mentioned earlier that all deployments are immutable and live forever. That means that each one can have it’s own URL which you can access to see that deployment.

Having permalinks for every deployment is huge. It immediately unlocks the ability to share the state of any version of your build with the testing team, the client, anyone. “What did the site look like at v3.2.14? Ah here it is.”

Deploy Previews don’t get deleted when you merge a branch and they don’t contribute to your bill. They do, however, go away when you delete your site.

It looks like you’ve already done a bunch of research on this, but sharing this post about controlling when deploy previews are generated, just in case:

How to delete branch deploy?

Since we can’t delete a deploy, here is a way to alleviate the case you don’t want to have the branch deploys. Branch for preview (temporarily) Set your production site with no previews and branch deploys under Continuous Deployment [image] Set up a [new site] to the same repo and build the branch Delete the [new site] when no longer needed Rinse and repeat

I hope that helps! If you still have questions, let us know and we’d be happy to try and find answers for you.

[benwinding]

Hi @jen,

Thanks for your detailed response. That clears things up a bit for me, but I’m still a little confused as to the function and pricing of this feature.

It’s a little strange that Phil Hawksworth says that deployments are immutable, as I’ve noticed that “Deploy Preview’s” continually rebuild on every commit added to the Pull Request. So the site that the URL is pointing to is changing based on the branch… so I could push a flag to make an empty build on the last commit of the PR right?

It’s interesting feature that deploy’s live forever, I like that you have the ability to simply try and older version of the site. I’m just worried about having 1000 deploy preview’s available and not being able to do anything about it.

Just a couple more questions I have still relevant to the initial question:

• Does the “Deploy Preview” bandwidth and build minutes contribute to the bill?
• Where can I view my current usage: in terms of “Build minutes”, “Bandwidth” etc.?
• Can I view a list of deployed domains (including Deploy Previews) somewhere?

Thanks for your patience,
Ben

[fool]

deployments are immutable; each deployment has a permalink that will always work for it, until you delete the site. This screenshot shows how to get there from your deploys listing:

These URL’s look like https://DEPLOYID--sitename.netlify.com, and deploy ID’s are unique and specific to that very commit or deploy.

The “deploy preview” URL however, - something like https://deploy-preview-1234--sitename.netlify.com reflects the last successful deploy built off the PR, but the first one you made will be there forever, or until you delete the site. That’s the one you can “zero out” with an empty deploy. But the previous deploys live on at their unique URL’s.

Deploy previews automatically get marked as non-crawlable so there is no problem with having thousands around. Some customers have built over 20k times on the same site; things work well for them.

All bandwidth that we send to web browsers for your website counts towards your bandwidth bill. Nobody will “find” those old deploys unless you share the URL. Nobody has ever been “attacked” on a deploy preview URL to cause bandwidth overage before, so no need to be worried

All builds count towards your build minutes bill. Don’t make needless builds; read this article for details on how to configure things:

[Common Issue] How can I optimize my Netlify build time?

If you are interested in learning more about how our bots approach building sites, these three articles are a great place to start: How our Build Bots build sites The last major upgrade to our build environment and perhaps least-loved but most useful, how to debug your builds So you might think, it’s great that Netlify builds every commit from my repos…but isn’t that a bit wasteful? The answer is, it depends, but we can at least give you some best practices for limiting waste. Maybe …

You can see those running totals in your team dashboard.

• Bandwidth here: https://app.netlify.com/teams/benwinding/billing/general
• build minutes here: https://app.netlify.com/teams/benwinding/builds/

There is no “master list” of all deploy preview URL’s. You can see all your sites in the site listing page:

https://app.netlify.com/teams/benwinding/sites

Those update about once a day; not yet in real time though we are working to bridge the gap.

[benwinding]

Wow thanks, I appreciate the detailed reply Chris!

It’s great to hear more details about the immortal life-cycle of deployments , I still think it’s a bit of a security risk, as the even though the URL’s aren’t indexed by search-engines, they can be trivially guessed from the PR number. But I’m not as worried as I was originally.

All builds count towards your build minutes bill. Don’t make needless builds; read this article for details on how to configure things…

This will help us out a lot, originally I was pushing to Github on every commit, which was needlessly building the app like 100 times

Anyway thanks so much, all my questions are answered.