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.

[donavon]

IMO, when a PR is approved and merged then if the branch is deleted then the PR deploy preview should also be deleted (i.e. the build life should match the branch life).

If I’m not keeping the branch, then why should I be forced to keep the build?

[luke]

Hi, @donavon, we do have an open feature request to be able to delete deploys and I’ve added this topic to the feature request.

If/when this becomes possible, we’ll post an update here. In the meantime, the only method to delete a deploy is to delete the site which deletes all deploys associated with the site. There is no other workaround at this time.

Again, we added topic to the feature request. If there are other comments or questions, please let us know.

[hozzamedia]

I definitely think deploys should be deletable for loads of practical reasons - for example last-resort style emergencies where something semi-sensitive gets deployed (even after all sensible precautions are taken) it would still exist on your system even if it’s not easily findable. We should be able to delete our own data if we want to without destroying the whole site.

[luke]

Hi, @hozzamedia. I did add this +1 vote to the open feature request and if/when this becomes possible we’ll post an update here.

[4degrees]

Just discovered the persistence of deploys and was a little surprised. Like others, it makes me a little concerned about lack of control over removing access to previews/branch deploys for a few use cases:

1. If I share a ‘beta’ with a customer then at some point I want to ensure they move back to the main app rather than live on the beta branch forever - currently I’d have to push commits to the beta branches to force redirect them on the client side or show a notice. That’s hassle and I’d prefer to just have the deploy deleted (ideally when I delete the branch).
2. My app will evolve over time. I don’t want the mental overhead of trying to consider how all possible historical versions of my app on previously shared ‘previews’ might break or affect the current version. I’d rather clean up as I go and move on.

I understand the lack of delete is due to the deduplicated storage mechanism employed by Netlify. However, would it be possible to support removing access to a deploy via the shared URL (even if the underlying assets remain)?

[luke]

Hi, @4degrees. I’ve added another +1 to feature request and also added a note stating that making the deploy no longer accessible via HTTP while it still persists in databases would meet the requirements that many (likely most) people have regarding removing previous deploys.

[dot]

Hi @luke, I was also surprised by this behavior with regards to deploys from PR branches.

I also would have expected deploys from PRs to be deleted when the branch gets deleted for reasons others have mentioned (sensitive information committed by mistake, PRs might be just crazy ideas people have that are ultimately rejected and never merged and we don’t want someone to find them by guessing the app name and trying sequential ids).

It feels like something there might want to be a very explicit warning about… if I missed any warnings maybe they aren’t loud enough

Or maybe Netlify could switch to not using sequential IDs in the preview url to at least make it harder to guess urls?