docs: Improve deployment docs on self-hosting. (#58027)

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: #57953

---------

Co-authored-by: Ahmed Abdelbaset <A7med3bdulBaset@gmail.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>

Author: 3 people

docs/02-app/01-building-your-application/07-configuring/03-environment-variables.mdx

@@ -135,6 +135,32 @@ const env = process.env
 setupAnalyticsService(env.NEXT_PUBLIC_ANALYTICS_ID)
 ```
 
+### Runtime Environment Variables
+
+Next.js can support both build time and runtime environment variables.
+
+**By default, environment variables are only available on the server**. To expose an environment variable to the browser, it must be prefixed with `NEXT_PUBLIC_`. However, these public environment variables will be inlined into the JavaScript bundle during `next build`.
+
+To read runtime environment variables, we recommend using `getServerSideProps` or [incrementally adopting the App Router](/docs/app/building-your-application/upgrading/app-router-migration). With the App Router, we can safely read environment variables on the server during dynamic rendering. This allows you to use a singular Docker image that can be promoted through multiple environments with different values.
+
+```jsx
+import { unstable_noStore as noStore } from 'next/cache'
+
+export default function Component() {
+  noStore()
+  // cookies(), headers(), and other dynamic functions
+  // will also opt into dynamic rendering, making
+  // this env variable is evaluated at runtime
+  const value = process.env.MY_VALUE
+  // ...
+}
+```
+
+**Good to know:**
+
+- You can run code on server startup using the `[register` function](/docs/app/building-your-application/optimizing/instrumentation).
+- We do not recommend using the [runtimeConfig](/docs/pages/api-reference/next-config-js/runtime-configuration) option, as this does not work with the standalone output mode. Instead, we recommend [incrementally adopting](/docs/app/building-your-application/upgrading/app-router-migration) the App Router.
+
 ## Default Environment Variables
 
 In general only one `.env.local` file is needed. However, sometimes you might want to add some defaults for the `development` (`next dev`) or `production` (`next start`) environment.