[RFC] .env environment support

[timneutkens]

Goals

• Add dotenv (.env) support with the same .env file loading semantics as Create React App: https://create-react-app.dev/docs/adding-custom-environment-variables/#what-other-env-files-can-be-used
• Provide a way to easily expose environment variables to the browser

Background

Over the last few months we've had a lot of feedback from companies running into confusion around how to handle environment variables.

The main feedback has been mostly:

• It's unclear how / where to load environment variables in development.
  • For this reason most tend to fall back to using dotenv (almost 50% of Next.js apps).
• It's unclear when / if a environment variable is exposed to the browser
• It's unclear how to expose environment variables to the browser

Proposal

Node.js-only environment variables

Currently you can already access process.env in the Node.js environment only. Meaning that environment variables are private by default. Next.js never inlines environment variables unless you specify to do so under the env key.

An example of this is:

// pages/index.js
import fetchData from '../lib/api'

export async function getStaticProps() {
  const data = await fetchAPI('https://example.com/api/v1/posts', {
    token: process.env.ACCESS_TOKEN
  })
  return {
    props: {
      data
    }
  }
}

export default function HomePage({ data }) {
  return <div>
    <h1>{data.title}</h1>
  </div>
}

This would also cover the Server → Browser handoff, as an environment variable could be returned in the data fetching methods to expose it:

// pages/index.js
import fetchData from '../lib/api'

export async function getStaticProps() {
  return {
    props: {
      token: process.env.ACCESS_TOKEN
    }
  }
}

export default function HomePage({ token }) {
  return <div>
    <h1>This value was exposed to the browser {token}</h1>
  </div>
}

// pages/api/api-route.js
export default function ApiRoute(req, res) {
  console.log(process.env.ACCESS_TOKEN) // Logs out the ACCESS_TOKEN variable 
  return res.json({ hello: 'world' })
}

.env loading

Environment variables will be loaded from .env files, using the same loading mechanism as Create React App: https://create-react-app.dev/docs/adding-custom-environment-variables

For example:

# .env.local
ACCES_TOKEN=abcdefgh

Will set ACCESS_TOKEN to abcdefgh

Global public environment variables

Sometimes you need to configure something globally. A good example of this is the Sentry DSN key. To allow for this you can prefix global environment variables with NEXT_PUBLIC_ in order to make it globally available in both node.js and the browser. Note that this will expose the variable to the browser when used, so it can't be used for secrets.

---

Overall these changes should simplify usage of environment variables for the majority of use cases.

[laugharn]

By default Now excludes .env files from deployments, would there be a plan to change that when/if this RFC lands?

[timneutkens]

@laugharn no, when deploying you would pre-define the environment variables in the ZEIT dashboard for the project (this is currently being added). Uploading a .env file would be less secure as these can't be encrypted whereas secrets are.

[eric-burel]

That sounds quite targeted at pages.
What about config in other parts of the client side code. Say for example that I want to set my Apollo client in a certain way or configure a domain-level lib with some settings?

That's kind of similar to an issue I have with React or Redux more broadly, when a Provider component is containing too much logic: the object it produces are only available within React components, while advanced use cases might require an usage outside React.

I lack clearer example but you get the point, you may want to clarify patterns about how to access those variables outside pages.

[timneutkens]

Those patterns are already covered by the env key still. We might extend it to take in just an array of variables that have to be global. However keep in mind that these will be inlined at build time. Which is kind of expected as they're global and exposed client-side.

[eric-burel]

You meant that this an additional feature, but the env key behaviour will still coexist?
But then I am not sure it address the issue I've opened about public config #11131.
In the end you may still leak variables from the env key if you still choose this pattern or if you are forced too because you want settings outside of pages.

[timneutkens]

In the end you may still leak variables from the env key if you still choose this pattern or if you are forced too because you want settings outside of pages.

We'll just add extra docs on the way that it should be used. Even currently it's for exposing env variables everywhere including client-side. Recommendation has always been to not expose eg, database passwords, in the Next.js app itself except for reading it in API routes through normal process.env. This RFC solves that and ensures it's secure.

[eric-burel]

Sounds good to me if patterns are well documented. Isolating client side variables in process.env.public sounds sufficient to me for example. (Edit: actually no, because nesting leads to wrong typings, process.env is a map of strings in TypeScript :/)

reading it in API routes through normal process.env

Normal process.env is very limited though, no nesting, no arrays, no defaults. I'd rather have everything clearly defined in next.config.js, even when the env key then calls process.env. Same applies to dotenv btw (I can be wrong though I did not use it a lot).

Not directly related but I've noticed that the env variables defined in the config are not available when starting a custom server.
That probably makes total sense since it's a custom server, but do you have an idea how we could "force access" to the next.config env variables at this point? Or should I fallback to calling process.env?

To sum it up, I would expect a chain like this:

.dotenv > process.env (of your machine) > next.config.js > process.env (in the next app) or system you proposed in this RFC > custom server, api routes, and client code that consume the setting.

The next.config.js env key being the single source of truth for config, being env based or not, except only for runtime config.

[eric-burel]

Use cases for runtime config are still unclear to me btw. I feel like a confusion between the concept of "app settings" and "environment variables". In Meteor app we are used to abstract away everything and just have settings, but they are runtime only.

[borekb]

Just going to post a piece from our internal docs – not yet sure how relevant it is to this RFC and also, we have room for improvement, but anyway:

---

---

[eric-burel]

Last comment for me: TS typings are wrong for process.env when using nested objects. Env variables are supposed to be string, but next.config.js env key will allow nested object and arrays (which is nice).

const whitelist =  process.env.apolloServer.cors.whitelist 
// error because apolloServer is supposed to be a string

@borekb Totally related to #11131

I think in the meantime I'll fallback to runtime config, as my app is not really static.

[eric-burel]

To sum it up: I would expect the build time config of env to behave exactly like the runtime config, syntax-wise. I understand the technical difference of both but not the syntactical difference.

Using dotenv could be included as a default in Next but only affects the content of process.env.

Instead of using CRA prefixing for env variable that should also be available client-side, (honestly I hate it, it's not intuitive) we could just expect the user to call process.env when defining its client side settings, and then access this settings through Next methods or getSetting method or whatever.

Basically a Meteor-like pattern but that works at build time and with an even less confusing syntax (clearer separation of client-side and server-side settings).

[timneutkens]

Last comment for me: TS typings are wrong for process.env when using nested objects. Env variables are supposed to be string, but next.config.js env key will allow nested object and arrays (which is nice).

const whitelist =  process.env.apolloServer.cors.whitelist 
// error because apolloServer is supposed to be a string

@borekb Totally related to #11131

I think in the meantime I'll fallback to runtime config, as my app is not really static.

The types are not wrong though, you shouldn't nest objects in env, it's a coincidence that it works and it's not tested in our test suite.

[jesstelford]

I use dotenv-safe heavily over dotenv as it provides useful errors when expected environment variables are missing (particularly useful when deploying to a new environment when you might have forgotten to add an env var).

It also enforces The use of a .env.example which means onboarding a new developer (or nuking your code directory and setting up again) is as easy as cp .env.example .env then replace the examples with real values, no more reading seperate docs or guessing what env vars the codebase requires.

Do you plan to support such a feature, or at least allow opting in to it?,

[timneutkens]

The case of .env.example is covered by .env in the CRA handling (which is what rails also uses).

[iaincollins]

I'd chime in with some challenges around this that might be worth thinking about for you to ignore if you feel they are not helpful. :-)

1. It would be helpful on a projects to be able to know what env vars can / need to be configured.

I run into this pain point a fair bit, including on old projects I haven't looked at in a while and have refactored without updating all the documentation.

It would be great to design a mechanism that could display this using reflection (for example at start up, maybe with displaying default values where possible, like APP_URL=http://localhost:3000?) or perhaps if people were required to list them somewhere (as with now.json on now.sh) that could be really helpful when on-boarding folks on new projects.

2. It would be helpful to be able to clearly define which env vars are protected and which should be exported client side.

I feel like this is a fairly common pitfall. Having a mechanism whereby it's easy to categorically say "this env var is not safe to export to the client" (or better yet, explicitly having to say "this is safe to export to the client") and have that enforced when bundling, even if someone then tries to access it client side flow, would be valuable.

I get that the new data fetching methods help avoid this, but also appreciate there is a lot to take in for new developers and the nature of Next.js (making it easier to do more complex things) means people can run into complexity sooner and get overwhelmed by everything they are trying to take on board at once and so miss things like this.

If not feasible, perhaps using reflection to at least warn people what env vars are being exported to the client at dev run time / build time is possible?

Update: Just seen the post above by @jesstelford (which I think was added while I was typing) RE: dotenv-safe and want to add a +1 to that.

[timneutkens]

It would be helpful on a projects to be able to know what env vars can / need to be configured.

This is already covered by the export const config bit of the RFC:

// pages/index.js
import fetchData from '../lib/api'

export const config = {
  env: ['ACCESS_TOKEN']
}

export async function getStaticProps({ env }) {
  const data = await fetchAPI('https://example.com/api/v1/posts', {
    token: env.ACCESS_TOKEN
  })
  return {
    props: {
      data
    }
  }
}

export default function HomePage({ data }) {
  return <div>
    <h1>{data.title}</h1>
  </div>
}

It marks ACCESS_TOKEN as needed for that page, and Next.js can detect which variables are needed for all pages / api routes

[timneutkens]

It would be helpful to be able to clearly define which env vars are protected and which should be exported client side.

All environment variables will be secret and will not be sent to the browser unless you explicitly return them from getStaticProps or getServerSideProps

[dwest-teo]

This seems like it could be very helpful for cleaning up build processes as well as providing more granular control of what gets sent down to the client. Presently, we have to build a Docker image for each environment we deploy to in order to ensure env vars are included at build time. It seems to me that the feature described here would enable one to build a single Docker image for all environments and then consume the appropriate env vars at runtime.

With that said, can we provide a way to have more granular control over which .env file is loaded? Could we specify an environment when starting the app as a CLI parameter perhaps? If so, how could this work with a custom server?

[timneutkens]

With that said, can we provide a way to have more granular control over which .env file is loaded? Could we specify an environment when starting the app as a CLI parameter perhaps? If so, how could this work with a custom server?

This loading mechanism will be used: https://create-react-app.dev/docs/adding-custom-environment-variables/#what-other-env-files-can-be-used

It covers different environments.

[iaincollins]

@dwest-teo wrote:

With that said, can we provide a way to have more granular control over which .env file is loaded? Could we specify an environment when starting the app as a CLI parameter perhaps? If so, how could this work with a custom server?

While I get this us easy to put under a nice-to-have, it would be really nice and would second this.

In practice, I've found being able to easily load configs for different environments super handy.

[timneutkens]

#11106 (reply in thread)

[derekr]

I may have missed it, but it feels like we might want access to these env values when setting up App wide components (providers like Apollo)? I'm still getting to know the newer APIs, but looking at https://nextjs.org/docs/advanced-features/custom-app I see getInitialProps and assume I can use something like getStaticProps and access env values per this RFC and pass those in as app props for use in setting up providers?

[timneutkens]

I see getInitialProps and assume I can use something like getStaticProps and access env values per this RFC and pass those in as app props for use in setting up providers?

Correct, you can pass through env vars.

[timneutkens]

Added a section on global environment variables through the NEXT_APP_ prefix.
This will make having to add env: to next.config.js no longer needed in most cases.

[flybayer]

While this proposal is innovative and a step forward for security, I think it's a major step backward for DX. Imo, it's a departure from the simplicity of the rest of the framework.

As a developer, I fully expect environment variables to be available globally. Every other framework that I'm aware of uses global environment variables. Changing this will almost certainly cause extra confusion and extra boilerplate code.

1. Client-side environment variables

a. Developer should explicitly allow specific variables to be available globally in the static build

2. Server-side environment variables

a. All host environment variables should be available globally at runtime

Here's an alternate proposal that has a better DX, is easier to reason about, leaves env variables global, and still solves the security issue.

# .env
SENTRY_DSN=xxxxx
DB_URL=xxxxx

// next.config.js

module.exports = {
  // Value picked up from host env at build time
  publicEnv: ['SENTRY_DSN']
}

// pages/index.js

// This only used from getStaticProps, so it won't be in the client build
const db = () => new DbClient({url: process.env.DB_URL})

export async function getStaticProps() {
  const data = await db().fetchData()
  return { props: {data} }
}

export default function HomePage() {
  return <div>
    <h1>Sentry DSN: {process.publicEnv.SENTRY_DSN}</h1>
    {/* throws TypeError: Cannot read property 'DB_URL' of undefined */}
    <div>{process.env.DB_URL}</div>
  </div>
}

// pages/api/getItem.js

export default async function ApiRoute(req, res) {
  const data = await new DbClient({url: process.env.DB_URL}).fetchData()  
  return res.json({ data })
}

1. process.publicEnv is always inlined in the static build
2. process.env is never inlined in the static build, it's always read directly at runtime.
3. Trying to access process.env on the client will throw a TypeError.

Unless I'm missing something, I don't think there are any technical blockers for this approach.

[timneutkens]

Chrome crashed while I was writing a more detailed reply 🤦‍♂

TLDR:

• process.env is available in the component and getServerSideProps in the node.js environment when using next start for backwards compatibility reasons. However using the serverless target we can ensure only the defined env vars are available at runtime
• Using export const config = { env: [] } makes sure the defined env variables are in process.env and Next.js will error if they're not there
• NEXT_APP_ variables are exposed as-is, so NEXT_APP_VAR3 instead of VAR3

[flybayer]

@timneutkens are you confirming @Janpot's example with the exception of the NEXT_APP_ prefix?

A full example like this, including for api routes would be insanely helpful to understand all this.

[jkjustjoshing]

Currently Next.js never inlines unless you explicitly add env in next.config.js.

@timneutkens this is only true in the javascript context, right? I can still leak my private environment variables by accidentally rendering them to server-generated HTML, correct? My understanding is that is one thing this RFC is hoping to fix?

[timneutkens]

I can still leak my private environment variables by accidentally rendering them to server-generated HTML, correct?

We couldn't make this work without breaking applications unfortunately. The inlining I was referring to meant replacing process.env.SOMETHING inside of the JS bundle.

[jkjustjoshing]

Ah darn. Maybe for v10 🤷‍♂️

I've been using serverRuntimeConfig assuming it didn't suffer from this issue, but I just realized that it actually also allows you to accidentally leak to the static HTML with SSR. So this RFC isn't any less safe than serverRuntimeConfig.

Additionally, if an env var is leaked using this method, the client should display the error:

Warning: Text content did not match. Server: "process.env.SECRET=my_secret_value" Client: "process.env.SECRET=undefined"

so there is some protection in development. It just won't prevent a deploy of the leak.

[Janpot]

I might have missed this, but will the env parameter in getServerSideprops also contain NEXT_APP_ variables? And if so, do they also need to be specified in const config = { env: [...] }? Or do NEXT_APP_ variables always have to be accessed through process.env?

[timneutkens]

Or do NEXT_APP_ variables always have to be accessed through process.env?

Only this as they're inlined at build time (same as the current env: options

[Janpot]

Regading

It's unclear when / if a environment variable is exposed to the browser

Perhaps stubbing process.env as follows in the browser could also help with the confusion?

process.env = process.env.NODE_ENV === 'development'
  ? (
    new Proxy({}, { 
      get (target, property) {
        throw new Error(`Looks like you're trying to use "process.env.${property}", read article http://xyz on how to pass configuration to the browser`)
      }
    })
  )
  : {};

It would make trying to use any process.env.VARIABLE that is not inlined throw an exception in development with a documentation link.

edit:

🤔 although technically, people may rely on those values being undefined, which would be a legitimate way of using it I guess. That would make this change breaking.

[timneutkens]

We're going to add a warning in a similar way indeed.

[timneutkens]

I've updated the RFC based on the feedback and confusion, leaving out the export const config part, we might introduce it at a later point in time.

For now keeping it simple:

• NEXT_PUBLIC_ prefixed environment variables will be inlined into the JS bundle similar to how env in next.config.js works currently
• .env is loaded as described

Thanks for the feedback @Janpot @flybayer

[Janpot]

@timneutkens Thank you, this is awesome. Together with my previous comment that would make up exactly the counter-proposal I was busy writing.

btw, in the RFC body you still have

For API routes the environment variables will be exposed on req.env:

I think that's a leftover from the previous proposal.

[timneutkens]

I think that's a leftover from the previous proposal.

Yep! Removed!

[pom421]

I am not 100% sure I completely understand.

• there will be a mechanism to load .env file (and the like), so no need anymore to requiredotenv
• the env entry in next.config.js will not be useful anymore since the env var will be inlined with the new system
• the publicRuntimeConfig entry in next.config.js will not be useful anymore since we will be able to have NEXT_PUBLIC_X vars for exactly the same purpose

Is this correct ?

[eric-burel]

Env variables are string only so you probably still need a publicRuntimeConfig for complex objects.
env entry would probably be replaced by the .env file? Because you still need a pattern to define default values when variables are not defined.

[eric-burel]

The RFC sounds great regarding env variables, but it is still unclear to me how it interacts with serverRuntimeConfig and publicRuntimeConfig.
People might ask for .env support, as it's a common pattern, but env variables are nonetheless limited compared to JSON configuration, as they are string only and can't be nested.

@kxmatejka saying "There is really no need for something like this." is maybe too simplified, as we indeed need a good pattern to load env variables, and the current proposal seems very good.

However it shows that env variables are not sufficient in themselves to configure a complex application.

This is the most basic configuration of a Vulcan app (Meteor) for instance:

{
  "public": {
    "title": "Your site title",
    "tagline":"Your site tagline",
    "logoUrl": "http://placekitten.com/250/80",
    "logoHeight": "80",
    "logoWidth": "250",
    "faviconUrl": "/favicon.ico",
    "language": "en",
    "locale": "en",
    "twitterAccount": "foo",
    "facebookPage": "http://facebook.com/foo",
    "googleAnalytics": {
      "apiKey": "foo123"
    },
    "backoffice": {
      "enabled": true
    },
    "apolloSsr": {
      "disable": false
    }
  },
  "defaultEmail": "hello@world.com",
  "mailUrl": "smtp://username%40yourdomain.mailgun.org:yourpassword123@smtp.mailgun.org:587/",
  "oAuth": {
    "twitter": {
      "consumerKey": "foo",
      "secret": "bar"
    },
    "facebook": {
      "appId": "foo",
      "secret": "bar"
    }
  },
}

and this is only a simple setting, a real life app has twice as many settings.

In the current proposal, how do you expect such configs to be handled? Using runtime configs or transferring everything to a .env?
If it should go to the runtime configs, could there be an additional RFC to discuss support for external config files?

[kxmatejka]

Application of our homepage (react app) have a json config of 634 lines but nightly and production needs to overwrite only several lines. I don't want to duplicate my config for every environment, I want to merge them. Plus there are secrets that are in local environment handled by local gitignored config but in stage are passed by env variables.

And this whole circus is orchestrate by this genius library https://www.npmjs.com/package/config

[armandabric]

Lot's of discussions on this RFC seems to suppose that environment variables are a configuration layer for an application. This could be true for small application. But when the application grew, having a configuration layer that can handle the logic of different environment, or source of configurations (environment variables, files, remote sources...), is mandatory. Especially in our transpiled world where we have two environments: build time, and run time.

This somethings that is not really address in the JavaScript community, especially in the react world: the main tools does not have it. Only some frameworks have it: angular, ember (and I hope some more). In other language that a basic framework feature.

I do not know the plan for next.js but as it's made with the aim to scale for big application it could be an interesting lead to explore. That could be a differentiation with other frameworks. Maybe not to propose a configuration layer in the framework but at least make more explicit this step by offering some way to explicitly inject configurations at run and build time. With a minimal implementation that could be like the config key proposed initially.

For now this RFC improve the flux of the environment variables is SSG. It does not solve all problem but it's a nice first step 👍

[tronjsdev]

Application of our homepage (react app) have a json config of 634 lines but nightly and production needs to overwrite only several lines. I don't want to duplicate my config for every environment, I want to merge them. Plus there are secrets that are in local environment handled by local gitignored config but in stage are passed by env variables.

And this whole circus is orchestrate by this genius library https://www.npmjs.com/package/config

Though nextjs .env environment support is great but I think it's not a well suitable choice for sharing config between apps
I didn't known node-config before until I saw your comment, I moved all my config from .env* to use node-config instead and it's awesome. Thanks.

[hershmire]

@timneutkens I'd also like to better understand what the proposed solution is for managing more complex configuration for multiple environments. I agree with @eric-burel, using environment variables for just this purpose doesn't seem feasible for larger enterprise applications. Node-config is very powerful within the NodeJS landscape for handling this but it's unclear if that's a viable option to use in combination with serverRuntimeConfig and publicRuntimeConfig.

It's also a bit unclear how this RFC is to handle other environments outside of just the ones that CRA is supporting (development, test, production). This also seems quite limited and not all companies follow a Develop, Preview, Ship (DPS) CI workflow. It's quite common for larger companies to have many more environments (i.e. staging, hotfix) that would require configuration support.

[eric-burel]

Hi, small self-advertisement but I've synthetized what is currently possible in Next.js to setup a configuration variables in a detailed article, depending on the situation: https://blog.vulcanjs.org/how-to-set-configuration-variables-in-next-js-a81505e43dad
I've pushed those patterns to their limit in a real-life project, with env variables presence validation etc.
To sum it up, if existing features are not sufficient in Next, you could indeed use something linke node-config. Also, Next.js runtime config seems to be legacy features that should be ignored, as far as I could dig the subject.

[eric-burel]

Something that do not seem to be specified : the .env file loading mechanism might need to be exposed to developer to handle the special case of custom server. You would expect it to access the same env variable as pages for example but it uses a custom build (or no build), so devs have to mimic Next.js feature somehow.

[rafinskipg]

Hello fellas, first of all thanks for your great work and continuous development and detailed work on the issues and RFCs. I would like to give my support to this feature and RFC because a standardized way of dealing with environment variables is needed (both for client and server sides), without having to add extra packages like dotenv.

A couple of comments.
a) is the prefix NEXT_PUBLIC_ going to be deleted while accessing the variable in the frontend?
b) I am glad you introduced NEXT_PUBLIC_ , relying on getStaticProps to pass variables means having to deploy more serverless functions for not needed cases
c) Do you have any idea when this RFC will be implemented, or if you need help, how can we contribute to make it happen?

Thanks!

[timneutkens]

a -> it won't be stripped, they'll be inlined as-is, so you use process.env.NEXT_PUBLIC_MY_VARIABLE
b -> getStaticProps creates static files
c -> It's already implemented, currently available under and experimental flag but it's going to land on stable very soon: #12283

[hkhanna]

This is looking great. Excited for the RFC to land on stable.

Would it be accurate to say that the new approach to .env in Next.js collapses the distinction between runtime env and build-time env in the now.json file as it relates to local build and development?

In other words, the variables in .env will be available as process.env to both serverless functions and to the builder and, if a variable starts with NEXT_PUBLIC_, it will also end up in the client bundle. All on your local machine.

But when you deploy it to now.sh, .env is irrelevant, and if you wanted those same variables to be available to both serverless functions and the build process, you would need to include it in both env: and build.env: in the now.json file, right?

To really hammer this point home, if you put a NEXT_PUBLIC_ environment variable in the env: section but not the build.env section of the now.json file, that variable would not be bundled in the final production bundle. Is that right?

[williamboman-pp]

It's a bit unclear to me how I can control these environments. What does the following mean:

The supported environments are development, production and test. The environment is selected in the following way:

• next dev uses development
• next build and next start use production

How do I override this as needed, for example setting the environment to test?

[timneutkens]

NODE_ENV=test next build / NODE_ENV=test next start

[Manikanta-20]

@timneutkens the below commands will work for custom server
NODE_ENV=staging next build / NODE_ENV=staging node server.js

[hect1c]

NODE_ENV=test next build / NODE_ENV=test next start

Wasn't sure if I should create a new issue for this but this override doesn't seem to work for me.

NODE_ENV=development next build / NODE_ENV=development next start will still load the .env.production file and not the .env.development file I have created.

Using Next 9.4.4

[Timer]

This feature was released in Next.js 9.4!

[eric-burel]

Hi, I am trying to setup Jest to work as closely as Next as possible. What would be the shortest path in your opinion to have the same behaviour regarding .env? Of course I could use dotenv in Jest, but that defeats the purpose of having this feature already working with Next.

Edit: ok reading previous message I've already asked smth similar ^^ the questions comes back to my mind every time I need to setup a new 3rd party tool, eg Storybook, Jest, Cypress etc. I strive to have a really unified build time behaviour, based on Next's one

[iamchathu]

Can we use env variable inside manifest.json inside public folder?

[eric-burel]

This comment gives a solution, using @next/env: #17903 (comment)

[eric-burel]

And the official doc: https://nextjs.org/docs/basic-features/environment-variables#test-environment-variables

[ziimakc]

Can we add path to env folder in config? It's common to have private data in private folder, not in root.