Getting started with 1Password for your growing team, or refining your setup? Our Secured Success quickstart guide is for you.
Forum Discussion
Former Member
2 years agois env variable referencing supported?
Hi,
Hoping someone can help answer my question...
In my NodeJS project, I use the 1Password cli to load my secrets into my env file using the 'op run' command. e.g.
op run --env-file="./.env....
scottohara
2 years agoNew Contributor
I've stumbled on this thread because I'm having the same issue, and after trying numerous different approaches, I'm left wondering why this doesn't work.
Let's start with a simple example that uses https://developer.1password.com/docs/cli/secrets-template-syntax#enclosed-secret-references:
.env
DATABASE_URL="http://{{op://private/my_app/username}}:{{op://private/my_app/password}}@localhost:1234"
Checking this with op inject
returns the expected result, with the two secret refs replaced with the values "bob" and "secret" respectively; but running through op run
and printenv
doesn't:
```
$ op inject -i .env
DATABASE_URL="http://bob:secret@localhost:1234"
$ op run --env-file=.env --no-masking -- printenv DATABASE_URL
http://{{op://private/my_app/username}}:{{op://private/my_app/password}}@localhost:1234
```
So it seems that constructing an ENV value by embedding enclosed secret refs into a string doesn't work.
Let's try a different approach using multiple ENV vars:
.env
USERNAME="op://private/my_app/username"
PASSWORD="op://private/my_app/password"
DATABASE_URL="http://${USERNAME}:${PASSWORD}@localhost:1234"
```
$ op inject -i .env
USERNAME=bob
PASSWORD=secret
DATABASE_URL="http://${USERNAME}:${PASSWORD}@localhost:1234"
$op run --env-file=.env --no-masking -- printenv USERNAME
bob
$op run --env-file=.env --no-masking -- printenv PASSWORD
secret
$ op run --env-file=.env --no-masking -- printenv DATABASE_URL
http://op://private/my_app/username:op://private/my_app/password@localhost:1234
```
Again, we can see that op inject
seems to have correctly substituted the USERNAME
and PASSWORD
values, and left DATABASE_URL
unchanged (with the assumption that they would be correctly expanded when a process tries to read $DATABASE_URL
).
We can also see that op run
has correctly resolved the USERNAME
and PASSWORD
vars, but now DATABASE_URL
has been substituted with....the secret refs?
(I've tried this this with/without quotes, with/without curly braces etc. Nothing seems to work).
One more, just to really confuse things:
.env
USERNAME="op://private/my_app/username"
PASSWORD="op://private/my_app/password"
DATABASE_USERNAME="${USERNAME}"
DATABASE_PASSWORD="${PASSWORD}"
```
$ op inject -i .env
USERNAME="bob"
PASSWORD="secret"
DATABASE_USERNAME="${USERNAME}"
DATABASE_PASSWORD="${PASSWORD}"
$ op run --env-file=.env --no-masking -- printenv DATABASE_USERNAME
bob
$ op run --env-file=.env --no-masking -- printenv DATABASE_PASSWORD
secret
```
Wait, what? That works?
Here we have two ENV vars ($DATABASE_USERNAME
and $DATABASE_PASSWORD
) that reference to other ENV vars ($USERNAME
and $PASSWORD
) that are using secret refs....and it all works fine?
The difference here seems to be referencing a $VAR on its own ("${USERNAME}"
) is fine, but referencing it inside a string ("xx${USERNAME}"
) is not?
It seems like this should all just work.