Revalidation doesn't work (unstable_revalidate) after next-export

[remkst777]

Hi, I need some help, maybe I am not really aware, I have Next SSG project, do next build - revalidation happens periodically, do next-export - nothing happens. As I understand I have to get static update for this case too, haven't I?

[leerob]

next export also causes features like Incremental Static Generation and Regeneration to be disabled, as they require next start or a serverless deployment to function.

https://nextjs.org/docs/advanced-features/static-html-export

[remkst777]

I wanna to deploy app on Azure, earlier I used SSR and it worked good. But when I turned to SSG (and using unstable_revalidate) - I deploy it on Azure and it doesn't work. And my express located in server.js doesn't work too. I don't really understand how It has to work (at the same time It has to be updated owing to unstable_revalidate)

[jeantil]

All these features (incremental SSG, custom express server, etc) require a deployment which is running next start. You say that you deploy using next export . That generates pure static files which are then served by a generic http server there is no way this will understand and apply the custom nextjs features.

You can still deploy to Azure but you will have to deploy your app to a server instance and run next start there to get the benefit of the features you mention.

[remkst777]

thank you. I start via node server.js ... (not next-start). By the way I used SSR for next 9.1.7 and It worked on Azure, but when I updated next to 9.2.0 - It stopped (any version after 9.2++ doesn't work for me on Azure for the same configuration that for 9.1.7)

[jeantil]

via node server.js ... (not next-start).
In your initial question you wrote that you use next export. Are you starting a custom express server to serve the exported html ?

By the way I used SSR for next 9.1.7 and It worked on Azure, but when I updated next to 9.2.0
Its hard to tell but I think it's safe to say that it's not linked to azure :) There are quite a few changes in each minor version of next most of them are not backward compatible. I can only suggest looking at the corresponding documentation and making sure that the server.js is compliant. In any case there is 0 chance for SSG to work with such a setup. With the introduction of api routes the use cases for server.js have reduced a lot. maybe you can drop you custom server and migrate to use api-routes. this way you will be able to start with next start.

alternatively you can split your codebase and have the custom server proxy the content paths to a next start instance which will let you combine both custom server and SSG.