Set Amplify project ENV variables/secrets with CLI or BASH (not using the Console)?

[armenr]

Which Category is your question related to?

General - project-level

Amplify CLI Version

v9.1.0

What AWS Services are you utilizing?

Nothing right now.

Provide additional details e.g. code snippets. Be sure to remove any sensitive data.

I want to be able to set environment variables or secrets for my Amplify environment, directly from my terminal (either through the amplify-cli, or through bash/a script).

Any way to achieve this?

[josefaidt]

Hey @armenr :wave: thanks for raising this! Are you looking to add these secrets to functions or some other resource in your Amplify project? We can leverage CLI command hooks to read secrets from the environment or a dotenv file and upload to SSM. Or are you looking to add environment variables to your Amplify Hosting deployment?

[GeorgeBellTMH]

I would say that for me the goal would be on a newly created environment that the cli should prompt for env values...so something like:

Amplify env variable add|list|set|remove

The walkthrough would look like:

Enter the name of the secret: {env}/keyToSomeRemoteService

Is this a file or text field:

Enter the value|filename for this secret: xhejehelspa

Which functions need access to this secret:

Setting secret

Then on an amplify env add it would run through the list again:

Please enter the value|filename for keyToRemoteService: xxx

Potentially this whole set of information could be provided via a json file for automation.

Alternately when pushing without secrets set it would give a warning: the following secrets are not set: xxxx

[armenr]

@josefaidt - Frankly, I'm thinking about ways to establish some baseline/easy/safe and production-secure way to set/inject/fetch secrets, tightly coupled (or at least tightly integrated) with Amplify.

I guess the idea with hooks isn't a bad starting point.

If this were a customer discovery type thing, I'd say:

As a builder, I'd like to be able to quickly and safely get + set secrets from the amplify-cli, per environment/application/backend.

amplify add secret --env=my-env --backend=my-backend

Would want to use KMS + envelope encryption scheme to ensure it's locked up nicely.

[josefaidt]

Hey @armenr :wave: thanks for the clarification! I've gone ahead and marked this as a feature request for the team to evaluate further, however in the meantime can you also clarify the use case outside of applying these secrets/env vars to Lambda functions?

[armenr]

A typical workflow example:

Say you've got an app you're building, and you want to instrument it with some DataDog or NewRelic magic. You'll need some API credentials that you're going to inject into your client-side (or back-end) code at build time.

You're going to most typically have a .env in your local repo that you're using for that, and in your CI/CD, you usually set the environment variables for build-time (NEWRELIC_API_KEY=mySuperSecureKey).

Ideally, as a user, I would like to: amplify init (go through flow) amplify env set NEWRELIC_API_KEY=$SOME_VALUE_FROM_ENV

OR

amplify env set NEWRELIC_API_KEY=SOME_STRING_I_PUT_HERE

OR EVEN

amplify env set --loadFrom=.env

In my experience with Amplify (and I've been Amplify-obsessed before I worked at AWS, DURING the time I worked at AWS, and AFTER my time at AWS), this would be a hugely productive capability to add. What's really important about this is the DX/UX of not having to leave my terminal or my workspace, not having to navigate to the Amplify Dashboard, and not having to do it "manually" from the Amplify App's console.

Stated in the most straightforward way: Adding even the most primitive Environment Variable/Secrets Management kind of workflow to the CLI would be a huge win, IMHO. We're constantly finding ourselves saying "You know, I really wish the framework also provided THIS one thing...otherwise, it's nearly "complete" for all of our needs."

Right now, I have my own personal scripts that I load into /amplify/hooks and /amplify/scripts that allow me to kinda-sorta achieve the same goal, but without the CLI interactivity, or the tight integration of those env vars and secrets into the rest of the framework workflow."

Additionally, if the CLI could provide this functionality and SOMEHOW also use KMS + envelope encryption for sealing & un-sealing those Env Vars or Secrets...that would be 🔥 and would totally obviate the need for relying on some other "easy" tool like Doppler.

One other primitive approach for addressing some of this pain is what @heitorlessa does in this repo: https://github.com/aws-samples/aws-serverless-airline-booking/blob/develop/amplify.yml#L32

[farzadpanahi]

any movement on this ticket? my use case is to be able to have these env vars in a source control like my github repo rather than set and managed via AWS console.

[amir-zahedi]

For those still looking. Turns out just like about anything else outside the very basics, you'll have to use AWS cli and not amplify cli for this. For the reference here's the AWS cli docs for amplify command. In this case your command will look something like this. aws amplify update-app --app-id <AMPLIFY_APP_ID> --environment-variables AMPLIFY_DIFF_DEPLOY=false --region <REGION> And in case you wonder, you can find your AmplifyAppId in /amplify/backend/amplify-meta.json file

[mmarcoux09]

The "bad" thing about the update-app command it's that if you don't put ALL the environment variables in it, it wipes them all and not just update the one you requested. This is very annoying,

[Bandisa]

as @amir-zahedi mentioned, I think using the was cli helps with this, I just finished using the method.

Taking into account @mmarcoux09's warning, I made sure to add all environment variables to one file, and run the command to avoid losing the ones already set by amplify:

aws lambda update-function-configuration --cli-input-yaml file://amplify/backend/function/<function-name>/.config.yml

Seem to work fine, it is unfortunate that the amplify cli does not have a simple way to configure env vars through a text file, but this seems to do the trick for now.