Serverless now has built-in support for environment variables. As such, this plugin is deprecated and no longer maintained.

This is a plugin for the Serverless framework (1.x branch, prior to 1.0.0 final) that writes environment variables out to a file that is compatible with dotenv.

Likely once Serverless #1455 is finished, we will no longer need this plugin.

Easy! In your serverless.yml file you add a custom variable that is a list of variables you want written to an environment file. That file will be written and bundled into the root of your code bundle. Then you can rely on the dotenv library to load the file and make those variables accessible to your running Lambda functions.

This makes it simple to take advantage of the powerful variables capabilities that are built into Serverless.

For example:

service: petstore-api
custom:
   projectName: petstore
   defaultRegion: us-east-1
   region: ${opt:region, self:custom.defaultRegion}
   stage: ${opt:stage, env:USER}
   writeEnvVars:
      SERVERLESS_STAGE: ${self:custom.stage}
      SERVERLESS_PROJECT: ${self:custom.projectName}
      SERVERLESS_SERVICE_NAME: ${self:service}
plugins:
   - serverless-plugin-write-env-vars

That's all! Fill those variables up with any keys and values you want!

NOTE: at this time the plugin does absolutely no sanitization of keys or values, so you should make sure they are simple strings that do not have line breaks or other characters that would need to be escaped.

Easy! Pull requests are welcome! Just do the following:

• Clone the code
• Install the dependencies with npm install
• Create a feature branch (e.g. git checkout -b my_new_feature)
• Make your changes and commit them with a reasonable commit message
• Make sure the code passes our standards with grunt standards
• Make sure all unit tests pass with npm test

Our goal is 100% unit test coverage, with good and effective tests (it's easy to hit 100% coverage with junk tests, so we differentiate). We will not accept pull requests for new features that do not include unit tests. If you are submitting a pull request to fix a bug, we may accept it without unit tests (we will certainly write our own for that bug), but we strongly encourage you to write a unit test exhibiting the bug, commit that, and then commit a fix in a separate commit. This greatly increases the likelihood that we will accept your pull request and the speed with which we can process it.

This software is released under the MIT license. See the license file for more details.