How to setup custom environment variables other than development and production #12077
-
|
Hi, I am doing Any suggestions would be much appreciated. |
Beta Was this translation helpful? Give feedback.
Replies: 22 comments 58 replies
-
|
Have you taken a look at the
// next.config.js
require('dotenv').config({ path: `./.env.${process.env.ENVIRONMENT` });
module.exports = {
env: {
// Reference a variable that was defined in the .env.* file and make it available at Build Time
TEST_VAR: process.env.TEST_VAR,
},
}and then when you run your build you could do |
Beta Was this translation helpful? Give feedback.
-
|
@jamesmosier Thanks a lot. You are a lifesaver. I was bashing my head for this for 2 days and for even once I didn't bother to look in the Thanks a ton @jamesmosier |
Beta Was this translation helpful? Give feedback.
-
|
@jamesmosier sorry to trouble you again but for some reason, the test environment is not reflecting in the code by running the script Any reason as to why this happened? |
Beta Was this translation helpful? Give feedback.
-
|
I fixed this issue by changing the code in require("dotenv").config({ path: `./.env.${process.env.NODE_ENV}` });
const withMDX = require("@next/mdx")({
extension: /\.(md|mdx)$/,
});
const withImages = require("next-images");
module.exports = withImages(
withMDX({
env: {
ENVIRONMENT: process.env.ENVIRONMENT,
},
webpack(config, options) {
return config;
},
})
);```
Also, I changed the constant from `.env.` files form `NODE_ENV` to `ENVIRONMENT` and I amusing `process.env.ENVIRONMENT` in my code. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the discussion on this! |
Beta Was this translation helpful? Give feedback.
-
|
For newcomers, the https://nextjs.org/docs/app/api-reference/config/next-config-js/env |
Beta Was this translation helpful? Give feedback.
-
|
@jamesmosier From Next.js v9.4 providing inbuilt env ,without dotenv package. At build time how to point staging env file using next.js at yarn build? |
Beta Was this translation helpful? Give feedback.
-
Hey, @vrajpal-jhala I am also setting env variables using env-cmd like this
|
Beta Was this translation helpful? Give feedback.
-
|
Hi @moondustkj, can you share that variable from .env.staging file, also where and how you are accessing it? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for replying @vrajpal-jhala file- .env.staging file- next.config.js file- package.json file |
Beta Was this translation helpful? Give feedback.
-
|
@moondustkj seems to be working with nextjs 10. This discussion might help you. If you are using |
Beta Was this translation helpful? Give feedback.
-
|
Hey, @vrajpal-jhala thanks for sharing the discussion, I went through it but The scenario is- |
Beta Was this translation helpful? Give feedback.
-
|
@vrajpal-jhala nailed it
Here's my approach which works nicely:
Works like a charm |
Beta Was this translation helpful? Give feedback.
-
|
This looks pretty elegant. Are there any downsides to this? Also, can you set the entire |
Beta Was this translation helpful? Give feedback.
-
|
Here's what I did in const APP_ENV = process.env.NEXT_PUBLIC_BACKEND_ENV || 'live'
require('dotenv').config({
path: `../../.env.${APP_ENV}`, // I'm in a monorepo, so I go back in the directory
})
const env = {}
Object.keys(process.env).forEach((key) => {
if (key.startsWith('NEXT_PUBLIC_')) {
env[key] = process.env[key]
}
})
module.exports = {
env
} |
Beta Was this translation helpful? Give feedback.
-
"scripts": {
"dev": "next dev $ENV",
},// cmd
yarn dev test
yarn dev pre
yarn dev prdThis is clean & simple and i can decide with env to start my app. Currently, i can only use it like this: "scripts": {
"dev:test": "ENV=test next dev",
"dev:pre": "ENV=pre next dev",
"dev:prd": "ENV=prd next dev",
},// cmd
yarn dev:test
yarn dev:pre
yarn dev:prdThis is not cool. |
Beta Was this translation helpful? Give feedback.
-
|
holy hell, one adjacent key is the different between |
Beta Was this translation helpful? Give feedback.
-
|
This library next-branch-env is my attempt at solving this problem for branch-based environments. It lets you define branch-specific environment variables in the Vercel backend and rewrites them at build time for branch deployments. For example, if you set up a staging environment and define You can configure this to work for local development too, which may be helpful if you like to sync your local |
Beta Was this translation helpful? Give feedback.
-
|
this exactly what I'm after, the automatic handling of env files is great, but we really don't want staging deployments to connect to our production backend and data. |
Beta Was this translation helpful? Give feedback.
-
|
Simply put, if what you're looking for is essentially a unique NODE_ENV name without messing with NODE_ENV, you can use APP_ENV in your startup script in package.json. For example, |
Beta Was this translation helpful? Give feedback.
-
|
The issue with most of these answers is they go against the principal of "build once run everywhere", in reality most of us are using this technique build and run with Docker containers. It's not possible to have multiple build commands like this, and it would be bad practice. Better have your environment available at runtime. We created a package that allows next static optimisation and still have runtime env vars via https://github.com/andrewmclagan/react-env This works by generating an environment config object at runtime from whitelisted env vars: |
Beta Was this translation helpful? Give feedback.
-
While an approach to injecting runtime variables can be helpful, it's off topic in this instance.
These types of claims are considerably more helpful with supporting data / references. |
Beta Was this translation helpful? Give feedback.
-
|
It is dead on topic:
This is the exact use-case of the library I mention above. Config that can change on a per environment basis. |
Beta Was this translation helpful? Give feedback.
-
@githubjosh Pretty sure this is not a giant leap in thinking, and very relevant to the topic... I would hesitate to say your comment was far more unneeded and less relevant. @andrewmclagan that package nailed the issue for us. Thank you! Trying to think of a way we can use it for a static CDN deployment...! |
Beta Was this translation helpful? Give feedback.
-
|
@andrewmclagan Does this let you use |
Beta Was this translation helpful? Give feedback.
-
|
Copying the e.g inside of npm scripts: |
Beta Was this translation helpful? Give feedback.
-
|
Shit, this is clever. |
Beta Was this translation helpful? Give feedback.
-
|
Did you have .env.staging and .env.production in the root with .env.local? EDIT: I just tested this. 100% works.
.env.staging Package.json
|
Beta Was this translation helpful? Give feedback.
-
|
Also, you can use env variable with defaults: |
Beta Was this translation helpful? Give feedback.
-
Next v10 loaded both staging & production? |
Beta Was this translation helpful? Give feedback.
-
|
The above didn't work for me but helped me come up with the scripts below. Without the "|| :" they fail in my vercel deployment pipeline. Might be useful to someone, idk |
Beta Was this translation helpful? Give feedback.
-
|
After a lot of googling. Finally, I managed to solve my envs problem in my project. Maybe it might useful to your project too. In my project, I had setup in the following.
For local development, I had added the '.env.development.local' env file in the project root folder which will be loaded during local development when we run npm run dev. After the setup, you can run in the following order |
Beta Was this translation helpful? Give feedback.
-
|
I've posted a new RFC to fix issues with loading Please review and give any feedback you may have |
Beta Was this translation helpful? Give feedback.
-
|
if you use Docker, i think you can use ARGS I solved the problem using arguments |
Beta Was this translation helpful? Give feedback.
-
|
Now you can do it like this Available as process.env.NEXT_PUBLIC_STAGE in browser side. If you use prefix NEXT_PUBLIC_ it gets added during build time. |
Beta Was this translation helpful? Give feedback.
-
|
For those who might be still in trouble, that's how I fixed it based on @bezreyhan answer:
"build:test": "mv .env.test .env.production && next build",
ARG BUILD_ENV
RUN yarn ${BUILD_ENV} && yarn install --production --ignore-scripts --prefer-offline
docker build --build-arg BUILD_ENV=build:test -t <image-tag-name> . |
Beta Was this translation helpful? Give feedback.
-
|
First part seems OK but building images targeting one environment is not. The image should be unaltered. Else what you are testing in staging is not the same image that you are promoting to production |
Beta Was this translation helpful? Give feedback.
-
|
In general what I do is simply keeping a environments wise .env files and during my CI/CD I just rename the target env to .env.production which is accurate and for the code itself this is production |
Beta Was this translation helpful? Give feedback.
-
|
And how do you do it using containers? Because the image should be unmodified |
Beta Was this translation helpful? Give feedback.
-
|
Depends on how you do it, if you're building a container per environment it should be fine with that approach. One way that comes to my mind is to simply have a map to load the configurations based on URL or other mechanism to load the proper configs before using it. |
Beta Was this translation helpful? Give feedback.
-
|
if you are loading based on URLs, all of the fetching components will need to be 'use client' (if I am accessing the backed url based on env)? |
Beta Was this translation helpful? Give feedback.
-
|
Why build per environment? It should be build once, run everywhere. |
Beta Was this translation helpful? Give feedback.
-
|
@hubenschmidt indeed it should, with the rise of RSC, that can be closer to a reality, but when it comes to client side only, that's not possible because usually in the build step, your website runs on client and .env is not available there as it should reside only on server, in that case when you build the env variables are getting replaced to the values available in build time. If you have multiple backends that should be based on separate environments you must build your app again to account that |
Beta Was this translation helpful? Give feedback.
-
|
I'm just combing through this and feels like answers are all over the place. Has there ever been an official Vercel's guide to having other environments, such as staging? |
Beta Was this translation helpful? Give feedback.
-
|
Honestly with how widely requested this feature is and how many seemingly viable solutions have been proposed - I don't understand why this hasn't been addressed in NextJS yet. If I want And yes, maybe I, and I'm sure many other developers in professional environments with deadlines, don't have the luxury of just refactoring thousands of lines of code because someone decided that it's not "correct" to use a custom NODE_ENV for whatever situation we need it for. All that decision is going to do is force me to do something even more hacky to make everything stick together - which would probably be considered much worse than the "incorrectness" of just having |
Beta Was this translation helpful? Give feedback.
-
|
This should be solved 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. So you could use whatever environment you want. Build once, run anywhere. import { unstable_noStore as noStore } from 'next/cache';
export default function Component() {
noStore(); // Opt-into dynamic rendering
// This value will be evaluated at runtime
const value = process.env.MY_VALUE
...
}You can also opt into dynamic rendering in other ways, like using |
Beta Was this translation helpful? Give feedback.
-
|
@bezreyhan Hey, well, what setup do you have? Where do you deploy your app? Staying in the build+start context, my understanding is that you can load vars into node process env however you want, and most modern node.js hostings provide a way to set env vars/secrets, so after opting into dynamic rendering you should find those in process.env out-of-the-box. Other options would be:
As I say, I understand you could treat it as you would any other node process you want to provide env vars to. |
Beta Was this translation helpful? Give feedback.
-
|
@leerob where does that MY_VALUE get set? I'm struggling getting env variables that I'm trying to set when building the docker image in the docker-compose translate over to the image when it's deployed. Just getting udefined for any combination of process.env.NEXT_PUBLIC_APP_ENV or APP_ENV or similar. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
BTW, quick local testing. Using next v14.0.1. console.log("MY_VAR:", process.env.MY_VAR)
console.log("NEXT_PUBLIC_MY_VAR:", process.env.NEXT_PUBLIC_MY_VAR)
// to be sure rerender doesn't change anything
useEffect(() => {
console.log("effect MY_VAR:", process.env.MY_VAR)
console.log("effect NEXT_PUBLIC_MY_VAR:", process.env.NEXT_PUBLIC_MY_VAR)
}, [])
@leerob I don't think |
Beta Was this translation helpful? Give feedback.
-
|
One more test - I tried removing import type { FC } from "react"
const Page: FC = () => {
console.log("MY_VAR:", process.env.MY_VAR)
console.log("NEXT_PUBLIC_MY_VAR:", process.env.NEXT_PUBLIC_MY_VAR)
return <div>hey</div>
}
// make it dynamic
export const getServerSideProps = () => ({})
export default PageBuild without |
Beta Was this translation helpful? Give feedback.
-
|
@rtrembecky you are correct that it does not work in client components in the App Router, only server components. |
Beta Was this translation helpful? Give feedback.
-
|
Hey everyone – we have just published new documentation on self-hosting, including how to configure a custom cache handler for use with ISR / Data Cache in both the Pages and App Router. These docs go in depth about how other features like Image Optimization, Middleware, Environment Variables, Build Caching, and more work when self-hosted. There's also updated Docker based examples. Specific to this discussion, we have provided guidance on how to use runtime environment variables. https://nextjs.org/docs/app/building-your-application/deploying |
Beta Was this translation helpful? Give feedback.
-
|
OK, so as I understand, next.js now build-inlines variables only for static pages, not dynamic (server-rendered), regardless or using app/pages router, which makes sense. So I guess the actual solution to get 1. runtime client variables, 2. for a staging environment, 3. possibly for a docker image, now looks somehow like this: DISCLAIMER: I'm following this thread just out of interest, it would be nice if someone could actually verify this, I didn't. Building and running
App codePages router:
App router:
Of course a context provider or gradual passing down the tree would work as well. |
Beta Was this translation helpful? Give feedback.
-
|
That’s super funny because it threw off my echo network completely, but I’m definitely glad it brought you to a conclusion on your own. I can’t wait to try it myself and thank you for the feedback Sent from my iPhoneOn Dec 23, 2023, at 11:33, Darnell Noel ***@***.***> wrote:
The above didn't work for me but helped me come up with the scripts below. Without the "|| :" they fail in my vercel deployment pipeline. Might be useful to someone, idk
"dev": "npm run generate:env && (source .env.development && echo APP ENVIRONMENT: ${APP_ENV:-unset} && cp .env.${APP_ENV:-development} .env.local) || : && next dev",
"build": "(source .env.production && echo APP ENVIRONMENT: ${APP_ENV:-unset} && cp .env.${APP_ENV:-staging} .env.local) || : && next build",
"generate:env": "cp .env.local .env || :",
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I solved it by loading the configuration using dotenv package: const dotenv = require('dotenv');
const fs = require('fs');
const env = fs.readFileSync(`config/.env.${process.env.STAGE.toLowerCase()}`);
const config = dotenv.parse(env);
module.exports = {
env: {
...config,
},
};From there all you need to do is setting an environment variable All credit goes to this stackoverflow answer. The downside of this solution is that all the variables will be exposed also on the client side. |
Beta Was this translation helpful? Give feedback.
-
|
This one worked for me. Then created three environment files: .env.local, .env.production, and .env.staging. Then, I managed my scripts in package.json accordingly: |
Beta Was this translation helpful? Give feedback.
and others
This should be solved 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. So you could use whatever environment you want. Build once, run anywhere.
You can also opt into dynamic rendering in other ways, like using
cookiesorheaders, but this is an example.