Environment variables

  • Hi folks, I have a question that’s bugging me.
    Since the 0.15 release everything revolves around the cli.
    For example the template files in the cli’s templates folder and namely the entry.js.
    But I noticed that in the lib folder and quasar-config.js file the process.env gets overwritten as such:

        cfg.build.env = {
          'process.env': cfg.build.env

    webpack-config.js reads:

          new webpack.DefinePlugin(cfg.build.env),

    The result is very quasar-tailored env.


    I tried fiddling with it, but I messed it up. 🙂 I’m missing some knowledge on the subject, I know.
    Is there any way to access the real node environment variables since webpack config is now out of the question?
    Thanks in advance!

  • You define your env in quasar.conf.js like this:
    BASE_URL: JSON.stringify(process.env.BASE_URL')
    in your code you access them like this:

    Then for example your run BASE_URL=api.example.com quasar build to build your app with the desired value

  • I just couldn’t figure out why my cli environment variables where being ignored. I see now some info in the guide http://quasar-framework.org/guide/app-quasar.conf.js.html#Example-setting-env-for-dev-build.

    I’m still confused about the ctx.dev ? part. Don’t I just need props as a hash of env:?
    Can you show the above in dev and build sections of quasar.config.js?
    env: ctx.dev ? { API: JSON.stringify('https://dev.'+ process.env.MY_API) } ???

    is this ok?

    env: {
    ENV1: JSON.stringify(process.env.ENV1),
    ENV2: JSON.stringify(process.env.ENV2),
    ENV3: JSON.stringify(process.env.ENV3)

    Do you have to do this in both the dev and build sections if you want access to the same env variable doing either?

  • ok I think I get it. ctx.dev is true for quasar dev so this was my build:env

          env: ctx.dev
            ? { // so on dev we'll have
              WSS: JSON.stringify(process.env.WSS)
            : { // and on build (production):
              WSS: JSON.stringify(process.env.WSS)

  • So guys, how good do you think is the env object in quasar.conf.js for storing secrets for example?
    For Node I’m using dotenv, but it’s no use here because of webpack, plus the dotenv-webpack plugin is also useless in such setup because of the define plugin.

    Should I resort to environment variables from the machine and pass them in env?
    Or use extendWebpack option in quasar.conf.js maybe?

  • Whatever you do, don’t store secrets in quasar.conf.js!

    Does this help? https://medium.com/carbono/using-env-file-in-quasar-apps-72b56909302f


  • Hi Scott,

    I won’t store them there of course, I was using .env for other projects and I just wanted to have some consistency. ☺

    Thanks for the article, that really helps with the extendWebpack approach!

  • Currently there is an official extension for using environement variables.

    quasar ext add @quasar/dotenv

  • There are two @DarkLite1 ! 😄

    This one too:

    $ quasar ext add @quasar/qenv

    It is a bit more flexible than dotenv.


  • Is that one rendered faster so it can be used in the quasar.conf.js file to set for example a port number as mentioned here?

  • No, unfortunately it doesn’t.

    If you need get env vars in the config, you’ll need to install dotenv and use it as you normally would with a Node app. But, what port are you trying to set?


  • I found the answer here. For anyone interested you should install the app-extension-qenv and then to access the environment variables you can use this advice:

    So, no. You cannot access process.env from within quasar.conf.js. However, you can access everything that will be going into process.env – use build.env from within quasar.conf.js. Everything in build.env will be converted to process.env (build-time, vs run-time).

  • @s-molinari I’m just trying to have Quasar use the ports defined in the environment. So when I use a Docker container later on with its own environment in it, say port number and some API keys, I would like Quasar to respect that.

  • What are the API keys for? Ports don’t need to be hidden, so no real need for .env there.


  • The API keys are for Azure authentication and contain the Application Client ID. This is indeed not sensitive information but still, I would like to configure things in one place.

    The .env file also allows fine grained control by not having to set these things in the app. So after all I think it’s best to create a simple .env file and use it with the standard dotenv library.

    They suggest to preload it like this:

    node -r dotenv/config your_script.js

    Is there a way to do this with Quasar? And where is the production port defined in Quasar? I only see this for the devServer:

        devServer: {
          https: false,
          port: 8080,
          open: true // opens browser window automatically

  • @DarkLite1 did you managed?

Log in to reply