Amplify-cli: Feature request: Custom env variables in lambdas

[thedgbrt]

The update mentioned in 684 allows lambdas to access env vars generated by other amplify resources. However we still need a way to add custom environment variables to a project. I have a lambda that interacts with an external service via an API Key, I need a simple way to declare it through the amplify-cli.

I tried setting it manually from the lambda page on the AWS Console. However if I later update the function permissions to access different resources via amplify (and therefore have amplify attach new environment variables), it erases it on the next push.

Possible api for it

amplify add variable
? variablename **MyCustomEnvVariable**
? value **TheValue**

and then optin from the lambda:

amplify function update
? Please select the lambda function you would want to update **mylambda**
? Do you want to update permissions granted to this Lambda function to perform on other resources in your project?  **Yes**
? Select the category **variables**
? Select the variable name **MyCustomEnvVariable**

It would then become available in the lambda as process.env.MyCustomEnvVariable.

Secrets would need to be defined per amplify env environments. When switching environments, there could be a warning to mention that there are missing variables set up:

amplify env checkout staging
**warning: you haven't defined a value for MyCustomEnvVariable in this environment yet, make sure to call 'amplify variable update'***
Successfully initiated staging environment.

Alternative considered

I considered AWS Secret manager as an alternative but:

1. it is not integrated into amplify, unnecessarily complexifying my workflow
2. it is overkill / expensive for simple API Keys that don't require advanced security

Please let me know if something like this is doable or not. If it can be considered by the amplify team, I can take responsibility for setting up an RFC and then speccing out the whole thing.

[diego-palmeira]

+1
I need a way to add env variables to my lambdas using amplify and per environment (dev, pre, pro)
Thank you

[jonoirwinrsa]

Not a built in solution but you can inject some values using Bash + JQ in the CI

Add the ENV var to the Amplify console and run the following before building the backend:

jq '.Resources.LambdaFunction.Properties.Environment.Variables = .Resources.LambdaFunction.Properties.Environment.Variables + {"Your lambda env var key": $YOUR_ENV_KEY}' your-func-cloudformation-template.json > "$tmp" && mv "$tmp" your-func-cloudformation-template.json

[dtelaroli]

+1

[dansmith65]

+1

[StefanV85]

+1

[Lasim]

+1

[amuresia]

+1

[bastianbb]

+1

[chantlong]

+1

[Bulletninja]

+1

[mrgrue]

+1

[cjsedwards]

Is there an ETA on this? This feels like critical functionality to be able to inject secrets into the lambdas rather than put them in source code.

[hisham]

fyi I've been using SecretsManager and it has worked out ok. We suffix secret key with env name and have a class that gets the right secret for the right env. I agree the pricing is too high. What we do is put all our secrets in a JSON under one secret in SecretsManager so it boils down to 40 cents a month. SecretsManager should have a free tier and then perhaps it would then be a no brainer to add it to amplify cli.

Some secrets are shared between Lambdas, so specifying secrets per lambda could be annoying if it's the same key and value across a few lambdas. Also we don't usually have one secret per env, usually services have a dev secret and a prod secret, so we fall back to dev if there is no secret specifically for the env. This saves developer time and communication.

[sw-yx]

there is a chance that @eliecer2000 might have worked on this functionality in https://github.com/aws-amplify/amplify-cli/issues/3961 - just cross tagging

EDIT: eliecer2000 has the bulk of the code here: https://github.com/eliecer2000/amplify-cli/commit/74f3ffcf64d17264fe08e4ada1f20374d39d912e#diff-9de053806298419e361f5464e503a1a0 great work!

[eliecer2000]

If I have it, but only to add variables in AWS, not to test the lambda function locally, I can share the repository to try to do a merge. regards

[eliecer2000]

https://github.com/eliecer2000/amplify-cli

[r0zar]

Where would the variables be stored? locally? will there be an option to pass them in at build time?

[flogy]

Would love to have this feature too. I think it is very important to be able to set environment variables for Lambda functions, e.g. when accessing a third-party API.

[marianolc]

+1 Would be this the place to store third party api credentials?

[freeform-ryan]

Not a built in solution but you can inject some values using Bash + JQ in the CI

Add the ENV var to the Amplify console and run the following before building the backend:

jq '.Resources.LambdaFunction.Properties.Environment.Variables = .Resources.LambdaFunction.Properties.Environment.Variables + {"Your lambda env var key": $YOUR_ENV_KEY}' your-func-cloudformation-template.json > "$tmp" && mv "$tmp" your-func-cloudformation-template.json

How do you determine the path and name of your-func-cloudformation-template.json?

[jonoirwinrsa]

@freeform-ryan it's been a while since I've looked at this but I think its:

amplify/backend/function/<function-name>/<function-name>-cloudformation-template.json

So you will need to know which lambda's you want to add the ENV vars to. Alternatively you could find all files that end with -cloudformation-template.json but that doesn't really sound like a nice solution - neither of these do really..

---

Linked above looks like a similar but cleaner solution - there you should be able to find the file path to modify https://github.com/eliecer2000/amplify-cli/commit/74f3ffcf64d17264fe08e4ada1f20374d39d912e#diff-9de053806298419e361f5464e503a1a0

[freeform-ryan]

@jonoirwinrsa Thanks!

[mansdahlstrom1]

Dropped a solution for now here https://github.com/aws-amplify/amplify-cli/issues/684#issuecomment-738702705, maybe it could be helpful to find a solution as it would be great to have a more official solution

[raffibag]

I'd settle for a feature (or anti-feature?) that just doesn't overwrite the custom env values set from within the AWS console.