Does each "Deploy Preview" stay available forever?

+1 to the request to restrict access to deploy previews from the public Internet :slightly_smiling_face:

Another idea might involve letting devs hide/unhide deploy previews automatically based on their site’s config. It’d be nice to have a preview hide after its PR merges, but then still have the option to unhide it selectively if needed (i.e. to share with a customer, etc.).

That might help uphold part of the reusable permalink philosophy that @jen and @fool mentioned last year.


If the repo branch is deleted, any deploys associated with that branch should also be deleted. It’s that simple.

1 Like

+1 for me, I’d like to see deploy previews get deleted after the PR and branch has been deleted as well.


And yet another +1. Once the PR gets merged and the branch deleted, I would expect the preview to be deleted too, or at least have the option to do this manually. I’ve shared preview urls to clients to check out beta versions, and once the feature is merged, I want to make sure the clients stop using the deploy preview URL.


hi all, thanks for sharing your opinions on this! we absolutely agree with many of the points mentioned above, and are currently considering how to address this.

One of our team will report back here as soon as there is something concrete to share.

1 Like

My preview URLs are getting crawled regularly by a client that executes JavaScript. (If it’s a bot, it’s a headless browser.) I don’t know how they are being discovered. I deploy with the CLI, not Git. It looks like at least 10 distinct preview URLs have been accessed in the past week. It’s possible that the bot is archiving those “private” versions. The IP address is an AWS EC-2.

It would be ideal to be able to disable those URLs.

Edit: it seems like it might be happening a few seconds after each deploy. Is it a Netlify bot?

1 Like

Hi, @J444. Yes, our service does run a headless browser once after each deploy. This is what generates the thumbnail screenshot of the deployed site in this view:

There is no way to disable that screenshot generation at this time. If you would like us to, we can enter a feature request for that however…

If there are other questions about, please let us know.


Thanks, the screenshots aren’t a problem. The private deploys that don’t expire are worrying though.

1 Like

totally hear you on that. we’ll be excited to report back when/if (hopefully) something happens here. :pray:

1 Like

Another vote for this feature to be implemented. Being able to delete all deploys without having to delete the entire site would be a major help in cleaning up accidental uploads and the like.

1 Like

Completely agree! A PR is supposed to be temporary, not permanent. The deploys should mirror that, or at the very least, give an option to set this as an optional behavior.

One concern is, are all PRs only reachable with the permalink (i.e. is there a robots.txt)? Wouldn’t want a PR deploy showing up in a search result for whatever reason down the road :sweat_smile:

1 Like

Please consider the urgency of this. Looking at other responses in this issue and my own concerns with this missing functionality is tipping towards desperately finding another service provider!

Don’t get me wrong, I absolutely LOVE Netlify and currently recommend it to everyone I come across that haven’t already heard of it (for example the 90 people I talked to in a fullstack developer class)… but not having control over deploys (especially PR deploys) lifecycle is a dealbreaker (in the long run).

Again, I really want to be able to stick with Netlify and move all my old and future clients there. But I can’t do that in good conscience if there might be uncontrollable versions of the site floating around.

Thanks again for one of the best online products in years! :heart:


No changes over the behaviour of PRs any time soon, I’m afraid.

It’s always an option to set up two sites, one as a staging environment and one as production where only changes which are merged to the production branch get pushed to the production site. Then, you could run a cleanup on the staging env site ad-hoc, or periodically.

One concern is, are all PRs only reachable with the permalink (i.e. is there a robots.txt)? Wouldn’t want a PR deploy showing up in a search result for whatever reason down the road :sweat_smile:

Consider features like this! Very easy to avoid duping data with canonical headers.

1 Like

We’re actively planning deploy deletion controls for our near term roadmap.

In the meantime, I’d like to clear up this point:

Wouldn’t want a PR deploy showing up in a search result for whatever reason down the road

Deploy Previews and other past deploys are not indexed by search engines. You can find a description of how they are handled in the docs:

Also, if you ever have a specific deploy that you don’t want anyone to access, @philhawksworth shared this workaround:

1 Like

Just want to chime in here to add my +1 on the importance of being able to delete deploy previews. I was shocked when I merged a branch and the deploy preview didn’t disappear, and then I was unable to find any way to delete it! It at a minimum should be very clear up front when a user turns on this feature that these things live forever.

Hi @maxhodak,

Thank you for the thoughtful feedback, we’d pass it on to the devs and should anything change in this regard, we’d update the thread.

+1 to deleting deploy previews when the branch is deleted. I’d like to also request that the URL is not trivially guessable (or, far better, add an option to restrict the previews with password protection). Have to disable this really great feature in the meantime :-/. Thank you.

Hi @timf,

Adding your voice to the existing feature request. However, this would need some considerable reworking of the platform and thus, might not happen soon enough.

If you were to use it, we’d recommend keeping a test site connected to the same repo which you can delete once the tests are done and thus, the deploys would be deleted too.

Creating an alternate test site where the entire thing is password protected could work. That would make it OK to have deploy previews with easily guessable URLs. And as previews accrue, it could be periodically deleted/rotated. Thank you for the suggestion.

looking forward to have a way to get the previews auto-delete … or at least the HTTP access removed after the PR is merged or the branch is removed