> For the complete documentation index, see [llms.txt](https://devworkshops.gitbook.io/masteringvuejs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://devworkshops.gitbook.io/masteringvuejs/packaging-and-deploying/environment-variables.md).

# Environment variables

In this section we're going to cover two options to have environment variables and how each option will impact when it comes to building and deploying our application

## Using variables replaced at build time

The first option is by using **.env** files and modes. By default, Vue.js has 3 modes: development, test, production. And this 3 modes are associated by default to some tasks:

| Mode | Task |
| ---- | ---- |

| development | npm run serve |
| ----------- | ------------- |

| test | npm run test:unit |
| ---- | ----------------- |

| production | <p>npm run test:e2e</p><p>npm run build</p> |
| ---------- | ------------------------------------------- |

All the **.local** files will be ignored by git.

As an example of a **.env** file, we'll add a title.

{% code title=".env" %}

```
VUE_APP_TITLE="Northwind Traders"
```

{% endcode %}

For the dev environment, let's append a text so it's clear we're using the dev environment

{% code title=".env.development" %}

```
VUE_APP_TITLE="Northwind Traders (dev)"
```

{% endcode %}

Now whenever we run `npm run serve` the value coming from this variable is the development one.

Now, as an example, we're going to add a new computed property in the **NavBar.vue** component to bring the **App Title**

{% code title="NavBar.vue" %}

```javascript
...
appTitle() {
  return process.env.VUE_APP_TITLE
}
...
```

{% endcode %}

And update the nav brand to replace the title by the computed property

{% code title="NavBar.vue" %}

```markup
...
<a class="navbar-brand" href="#">{{appTitle}}</a>
...
```

{% endcode %}

The disadvantage of this approach for me is that your build pipeline will need to run for each environment. Personally I prefer to build once and deploy multiple times and replace variable at deployment time.

## Using variables replaced at deployment time

The idea behind this approach is to have a configuration file, ideally JSON, that is not modified at build time or `npm run build`. The challenge of this approach is in order to get hold of this configuration file, we'll need to use **axios** which we would normally use to talk to an API.

We'll create our configuration file in the public folder

{% code title="static/config.json" %}

```javascript
{
    "baseUrl": "//localhost:3000"
}
```

{% endcode %}

In our **main.js**, we'll read this file and update some defaults.

{% code title="main.js" %}

```javascript
import axios from 'axios'
...
axios.get('/static/config.json').then(response => {
    axios.defaults.baseURL = response.data.baseUrl
})
...
```

{% endcode %}

Now when it's time for you to deploy this application to another environment, you can use the deployment to replace variables inside the file.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://devworkshops.gitbook.io/masteringvuejs/packaging-and-deploying/environment-variables.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.