# Bedrock .env file versus Trellis group_vars/**/vault.yml

**URL:** https://discourse.roots.io/t/bedrock-env-file-versus-trellis-group-vars-vault-yml/28819
**Category:** bedrock
**Tags:** trellis
**Created:** 2024-10-18T16:31:49Z
**Posts:** 3

## Post 1 by @visualasparagus — 2024-10-18T16:31:49Z

I hope this is a simple question, but I am a little confused on whether I need to put enviroment variables in the `.env` file of Bedrock or in the `group_vars` files under

```
vault_wordpress_sites:
   environment:
      env:
        variable_name: variable_value
```

Is the .env file only if you are not using Trellis? As I am using Trellis, can I leave the .env file empty and locate everything in one of the `vault.yml` files?

Also, if a variable is present in both, which one takes precedence?

Thank you in advance.

---

## Post 2 by @andronocean — 2024-10-22T14:02:48Z

Trellis uses `group_vars` files to generate the `.env` during `trellis deploy`. [Bedrock reads `.env` and loads its contents as environment variables](https://roots.io/bedrock/docs/environment-variables/), so if `.env` is empty your site will not work ([here’s where config/application.php loads it](https://github.com/roots/bedrock/blob/6acbb2420eacf893294d9aec2e357d720b576861/config/application.php#L35-L42)). Bedrock itself doesn’t know anything about what’s in Trellis.

Therefore, since you are using Trellis you should define all your `.env` variables in `group_vars`. The spots to do this are:

- `group_vars/all/helpers.yml`: the `wordpress_env_defaults` dictionary is applied to every site in every environment.
- `group_vars/all/vault.yml`: has a `vault_wordpress_env_defaults`, which like the previous is applied to all sites and environments, but meant for sensitive items like API or license keys since vault files can (and should!) be encrypted.
- `group_vars/{{environment}}/wordpress_sites.yml`: every item under `wordpress_sites` can have its own `env` dictionary, which takes precedence over the defaults. Remember, this file’s not encrypted so it should not be used for sensitive values like passwords and keys.
- `group_vars/{{environment}}/vault.yml`: the encrypted version for sensitive data. Each item in `vault_wordpress_sites` can have a `env` dictionary that is merged with the matching site’s `env` in `wordpress_sites.yml`. Again, this takes precedence over defaults.

Refer to [WordPress Sites | Trellis Docs | Roots](https://roots.io/trellis/docs/wordpress-sites/) for more about the Trellis variables.

Only other thing to note is that Bedrock also reads a `.env.local` file _if it exists_, and variables defined there take precedence over `.env`. Trellis won’t create or modify that. Personally, if I need to edit env stuff _manually_, I like to do so in the `.env.local` file and leave `.env` the way Trellis made it. Just remember to move those edits into one of the Trellis `group_vars` locations above if you want them deployed automatically!

---

## Post 3 by @andronocean — 2025-12-04T20:04:02Z

An update for anyone reading this later: I got one thing wrong in my answer about the construction chain for `.env` during deployments.

The `wordpress_env_defaults` dictionary in `group_vars/all/helpers.yml` **has no effect in deployment**. The `deploy` role redefines `wordpress_env_defaults` with a new structure (in [deploy/vars/main.yml](https://github.com/roots/trellis/blob/835a98301d0566f1ca0c1df297bcb551704399e7/roles/deploy/vars/main.yml#L1), which comes later in [Ansible’s variable precedence order](https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_variables.html#understanding-variable-precedence)).

This is why the deployed .env file includes nice things like `GIT_SHA` and `RELEASE_VERSION`.

Unfortunately it also means there is no place out of the box to define _unencrypted_ env variables that will be applied to every single environment. You have to put it all under each `wordpress_sites.{site}.env` in the `group_vars/{env}/wordpress_sites.yml` files.

The `wordpress_env_defaults` from `group_vars/all/helpers.yml` file is _only_ used in server provisioning. So, it takes effect when creating a development VM (because the dev.yml playbook does not use the deploy.yml playbook).

There was a previous thread about this: [Wordpress\_env\_defaults in helpers.yml not working?](https://discourse.roots.io/t/wordpress-env-defaults-in-helpers-yml-not-working/22529)

(`vault_wordpress_env_defaults` does get applied to every environment, but it’s a pain to encrypt non-sensitive stuff there. Probably better to define a custom var and merge it into `wordpress_sites`.)