mirror of
https://github.com/hanzoai/next.js.git
synced 2026-09-24 17:00:51 +00:00
958dcbc7e3
This PR is a combination of many months of feedback from the community on how to self-host with Next.js. It's became clear talking to many of y'all that there is confusion about if all features are supported when self-hosting, and what implications this has when using third-party providers. The deployment docs now clarify that all features are supported when self-hosting. However, this comes with important notes. First, we're building a standard deployment output, not adapters. We want these docs to ensure that if you follow what's described on this page, you're going to have a good experience with Next.js and will be able to take advantage of all features. Previously, we had to add caveats in here about different providers and their level of support. We are not doing that anymore. Instead, we're providing further details on different features and how they can be configured when self-hosting. These docs have existed in other locations (e.g. the specific API pages in our docs), but I've combined and simplified them here so there's one page you need to read to learn about all of the options. If you self-host Next.js anywhere with a Node.js server, Docker container, or static HTML export, all of the following features will work as expected. Further, we've added other specifics around self-hosting ISR / Data Cache and configuring your caching location, which is important when self-hosting with Kubernetes. Finally, there has been a common feature request to allow runtime environment variables, rather than statically inlining the values during the build. While this was possible with `getServerSideProps` in the Pages Router, if the value needed to be used on the component body, this option didn't work, as it needed to be serialized and forwarded to the component. With the App Router, this problem is solved, since Server Components can render entirely on the server. Thus, when dynamically rendering, you can just use `process.env.MY_VALUE` and it works. I also toned down the Vercel section, because, it was a bit much TBH. Related: https://github.com/vercel/next.js/pull/57953 --------- Co-authored-by: Ahmed Abdelbaset <[email protected]> Co-authored-by: Tim Neutkens <[email protected]>
20 lines
947 B
Plaintext
20 lines
947 B
Plaintext
---
|
|
title: generateBuildId
|
|
description: Configure the build id, which is used to identify the current build in which your application is being served.
|
|
---
|
|
|
|
{/* The content of this doc is shared between the app and pages router. You can use the `<PagesOnly>Content</PagesOnly>` component to add content that is specific to the Pages Router. Any shared content should not be wrapped in a component. */}
|
|
|
|
Next.js generates an ID during `next build` to identify which version of your application is being served. The same build should be used and boot up multiple containers.
|
|
|
|
If you are rebuilding for each stage of your environment, you will need to generate a consistent build ID to use between containers. Use the `generateBuildId` command in `next.config.js`:
|
|
|
|
```jsx filename="next.config.js"
|
|
module.exports = {
|
|
generateBuildId: async () => {
|
|
// This could be anything, using the latest git hash
|
|
return process.env.GIT_HASH
|
|
},
|
|
}
|
|
```
|