No. Don’t touch the .next folder, it can have unexpected consequences

OK, do you have any other suggestions? Do I need to simply restart the machine then?

Why do you need to delete files in the first place?

@joulev we need to manage the size of the cache.

If we use a cache handler using Redis, will we be able to remove entries there on an interval?

Why do you need to manage size of the cache?

Also there is already a cache limit in place for the nextjs cache

Well we're on a k8 cluster and counting the amount of pre-generated HTML files that would be saved to the .next/server/pages folder it would be like 765gb (millions of pages).

We generate these pages with a fallback blocking strategy.

The memory is not relevant in this case, we just want to make sure that the disk usage doesn't grow too high. I think this has come up before in github issues, that people see that redeploying the nextjs server is the only way to manage the growing disk size. That is what we've done for now too, a simple cron job that redeploys the pods.

But it would be nice if we could manage this using the new cache-handler.js file, and remove cache that has been too long.

We don't have the space for that amount of files / disk usage

Does Vercel document anywhere about how they manage disk usage? I'm told here and there that they remove files on disk eventually, but when is that and can it be controlled at all?

765gb of pages? what kind of website is this

It's a website that lists a lot of hotels, across many markets.

Roughly 650k hotel pages for one market (locale), and we currently serve 5 locales/markets. Each page generates about 250kb worth of HTML. That ends up being about ~750gb theoretically, but I want to know if Nextjs does any sort of pruning of HTML. In any case, it would be nice to configure Nextjs for an arbitrary disk usage limit and recycle older ISR pages when needed.

I have no experience with such large sites, and probably I don't fully understand the issue you encounter. But anyhow.

You have these rendering strategies (see https://nextjs.org/docs/app/building-your-application/rendering/server-components#server-rendering-strategies)

Static Rendering: Is this what you do? If yes, and if you generate too many pages, consider dynamic rendering.

With dynamic rendering, you should be able to decide, which data you want to cache. The docs say "...that's revalidated at an interval...". This does not mean that outdated cache data is removed. If this is the issue, I guess you have to opt out from all caching, which possibly slows down your site. 

Does this describe the issue you encounter?

We're still using the pages router; but yeah right now we're using getStaticProps but with fallback: 'blocking'

And getStaticPaths returns an empty array of pages. We just do ISR on the fly

You were mentioning "dynamic rendering". What is that?

The option we've considered is switching to getServersideProps, and opting out of ISR. But it seems a bit like a shame.

serversideprops will just create & render the html on the go instead of generating the html and caching it

Yeah I know, hence the shame. 🙂

But it would be nice to know if nextjs has any limits on how much disk usage it should take