Next.js: Deployment strategy best practices

[devcorpio]

Hi,

Could you recommend us the best practices to deploy applications in production with nextjs?

We are thinking in strategies like: canary deployment, blue/green deployment... We have several doubts to handle BUILD_ID.

Right now, with this kind of strategies we are facing with this error: INVALID_BUILD_ID, because in some moment of the deployment we have at least two different versions of the application.

for example:

On a Canary deployment, at one point we have 2 differents versions, The balancer send a client to
version A, but then when the client need other resources, the balancer could send this request to a
server with version B. At this point the client receive an 500 error when the app fetch resources like serp.js, _error.js, _document.js, and the webpage is not loaded correctly.

_next/f6bff019-9550-4029-99fa-2b33a50045f6/page/index.js ---> old (previous deployment)

_next/005b2202-c5b2-4de6-afd8-1c8451d16ab3/page/index.js ---> new (current deployment)

Until now, we have tested:

1. Rename the BUILD_ID to have the same hash in both versions, but we think is a bad practice, because we think that the client's cache will not be refreshed how is expected.
2. Sticky sessions is the most reliable, but we are handle a stateless app as an app with state, and really is not true.
3. We could put on front a CDN that caches the BUILD_ID, but we are not sure that the time we should assign for the cache of the js files.

Kind regards,

[timneutkens]

On a Canary deployment, at one point we have 2 differents versions

Could you outline your current deployment workflow? Since it sounds like you're running builds on the production server/directory 🤔

[devcorpio]

Our deploy is with Kubernetes, and during a short period of time we have two differents deployments actives, because kubernetes(with our strategy) bit a bit replace the old containers with the new containers.

However, although we try to change old the containers with the new containers at once, the users receives error 500(with the nextjs 6.0, 404) while try to fetch resources as main.js, and other of our pages js. (these errors appears in the console of google chrome)

[devcorpio]

Hi,

Anyone could help us?

Kind regards

[devcorpio]

ping @timneutkens

[HeroProtagonist]

@devcorpio
I am struggling with this exact same thing. There is this post but it doesn't really address the problem you describe. I feel like the solution would involve next having a graceful way of sending down the new requested resource and forcing flushing the old cached pages on the client.

[psyduk]

@devcorpio could you go with option 3(put the builds behind a CDN) and just cache them forever? That's what we currently do

[devcorpio]

Thank you @HeroProtagonist, the post information doesn't address our problem :(

@psyduk, thanks, we are going to test your approach :)

[giovannigiordano]

I have used the command next export with an empty exportPathMap.
next export exports the dist files to the out folder, then you simply need to upload this folder to wherever you want and keep old versions.

[timneutkens]

This is solved on latest canary. We now export pages into .next/static/<buildid>/pages/<page> so buildId is part of the directory structure 🕵️

[timneutkens]

Going to close this as it's addressed in the new docs. The best deployment strategy is hybrid static/dynamic, where the dynamic parts (SSR'ed pages / API routes) are serverless functions. ZEIT Now handles this out of the box without having to add any configuration to your application. Relevant links:
https://nextjs.org/docs/deployment
https://zeit.co/solutions/nextjs