Just a heads up, I expanded the doc on environment variables and moved to its own page https://docs.serverless-stack.com/environment-variables

@Jay great to see

.env

files are supported now! 😄 I am curious to understand why you encourage to commit them (not the

.env.local

ones 🙂), which goes in a different direction than what others recommend; e.g. the

dotenv

package’s FAQ “strongly recommends” not to commit them. Have you found a way to work around this issue ? I’ve come across this and had to use the less secure

String

type. Thanks! 🙏

which goes in a different direction than what others recommend

Yeah it seems to be a convention that create React app and Next.js have adopted. Their interpretation is that the .local files have values that are specific to the machine they are running in.

I’ve come across this and had to use the less secure 

String

 type

Yeah CloudFormation doesn’t support it. To add some context, there are 2 ways you can reference an SSM value in CloudFormation: 1. SSM parameter: you can only reference String, not SecureString - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html#aws-ssm-parameter-types-unsupported 2. dynamic reference: you can reference a SecureString like this in your CF template

{{resolve:ssm-secure:_parameter-name_:_version_}}

, AWS Lambda currently doesn’t support this format, so you cannot set a Lambda’s environment variable to this value. Where as AWS RDS supports this format, and you can set the RDS password to this. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html#template-parameters-dynamic-patterns-resources So that leaves you two options, either fetch the SecureString using AWS SDK in your CDK code; or fetch it inside your Lambda code (the recommended way)