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?
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
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:
I hope that helps! If you still have questions, let us know and we’d be happy to try and find answers for you.
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?
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:
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:
You can see those running totals in your team dashboard.
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.
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?
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.
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.
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:
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).
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)?
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.
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?
hey dot! these are some great suggestions - and we definitely hope to include them at some point. I don’t, at present, have an ETA for this - but if we do get some work done, we’ll definitely follow up here.
I had exactly the same confusion about how to delete old deploy previews, and found this thread.
I too find it bit concerning that it’s not possible to delete old deploy previews. I can envisage a situation where there is accidentally-released sensitive information that you want to remove, or a security vulnerability that you want to take down.
Welcome to Netlify Forums Thanks for chiming in here with this point. As Perry mentioned above, we don’t have an ETA for changes to this, but if we do we will follow up on this thread!
Hey there! Just want to give a +1 for being able to delete previews. I’m currently thinking about locking a feature of my site behind a paywall which is free right now. Having old preview URLs could lead to people just using the preview URL to use the feature. I’ve given out those URLs for testing reasons…
+1 for me, I’d like to see deploys get deleted after the PR and branch has been deleted as well. Some of the users were able to just go through all the deploys, which is not desirable. I hope the ability to delete those previews will come sooner than later
, 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.
Thanks for chiming in here with this point. As Perry mentioned above, we don’t have an ETA for changes to this, but if we do we will follow up on this thread!