1.3.0 (2016-12-02)

Features

• Metrics support (#1650)
• AWS credential setup command (#2623)
• Lambda versioning on each deploy (#2676)

Improvements

• Documentation improvements with serverless.yml file reference (#2703)
• Display info how to use SLS_DEBUG (#2690)
• Drop event.json file on service creation (#2786)
• Refactored test structure (#2464)
• Automatic test detection (#1337)

Bug Fixes

• Add DependsOn for Lamda functions and IamPolicyLambdaExecution (#2743)
• Add JSON data parsing for invoke command (#2685)
• Internal refactoring

Meta

• Github Milestone
• Comparison since last release

1.2.0 (2016-11-22)

Features

• Lambda environment variables support (#2748)
• Load Serverless variables from javascript files (#2495)
• Add support for setting custom IAM roles for functions (#1807)
• Lambda environment variables support in Invoke Local (#2757)
• Tighter and secure permissions for event sources (#2023)

Bug Fixes

• Fix --noDeploy flag to generate deployment files offline without needing internet connection (#2648)
• Bring back the include packaging feature with the help of globs (#2460)
• Internal refactoring

Meta

• Github Milestone
• Comparison since last release

1.1.0 (2016-11-02)

Future breaking changes

We will include the LogGroup for your Lambda function in the CloudFormation template in the future. This will break deployments to existing applications because the log group was already created. You will get a warning about this if you deploy currently. We will force this behaviour in a future release, for now you can set it through the cfLogs: true parameter in your provider config. This change will also limit the logging rights to only this LogGroup, which should have no impact on your environment. You can read more in our docs.

Features

• Rollback Support (#2495)
• Log Groups in Cloudformation (#2520)
• Allow Services without functions (#2499)
• Clean up S3 Deployment bucket only after successful deployment (#2564)
• Allow Inclusion after Exclusion using ! Globs (#2266)
• Version Pinning for Serverless Services to only deploy with specified versions (#2505)
• Invoke local plugin (#2533)
• Plugin template (#2581)
• Simple Plugins are now installable in subfolder of the service (#2581)

Bugs

• Fix variable syntax fallback if the file doesn't exist (#2565)
• Fix overwriting undefined variables (#2541)
• Fix CF deployment issue (#2576)
• Correctly package symlinks (#2266)

Other

• Large documentation refactoring (#2527)

Meta

• Github Milestone
• Comparison since last release

1.0.3 (2016-10-21)

Following is a selection of features, bug fixes and other changes we did since 1.0.2.
You can also check out all changes in the Github Compare View

Features

• Stack Tags and Policy (#2158)
• CF Stack Output Variables in Verbose deploy output (#2253)
• Custom Status code for non-proxy APIG integration (#2014)
• Function Runtime can now be configured per function (#2425)
• Allow absolute path for invoke command event file (#2443)
• Add list deployments command to show last deployments stored in S3 bucket (#2439)

Bugs

• Fix not thrown error after failed ResourceStatus bug (#2367)
• Fix overwrite resources and custom resource merge bug (#2385)
• Clean up after deployment works correctly now (#2436)

Other

• Migrate Integration tests into main repository (#2438)

1.0.2 (2016-10-13)

• Clean up NPM package (#2352)
• Clean up Stats functionality (#2345)

1.0.1 (2016-10-12)

Accidentally released 1.0.1 to NPM, so we have to skip this version (added here to remove confusion)

1.0.0 (2016-10-12)

Breaking Changes

• The HTTP Event now uses the recently released Lambda Proxy by default. This requires you to change your handler result to fit the new proxy integration. You can also switch back to the old integration type.
• The Cloudformation Name of APIG paths that have a variable have changed, so if you have a variable in a path and redeploy CF will throw an error. To fix this remove the path and readd it a second deployment.

Release Highlights

Following is a selection of the most important Features of the 1.0.0 since 1.0.0-rc.1.

You can see all features of 1.0.0-rc.1 in the release blogpost

Documentation

• New documentation website https://serverless.com/framework/docs

Events

• API Gateway Improvements
  • Supporting API Gateway Lambda Proxy (#2185)
  • Support HTTP request parameters (#2056)
• S3 Event Rules (#2068)
• Built-in Stream Event support (Dynamo & Kinesis) (#2250)

Other

• Configurable deployment bucket outside of CF stack (#2189)
• Install command to get services from Github (#2161)
• Extended AWS credentials support (#2229)
• Extended the Serverless integration test suite

v0.5.5

We made an error when publishing v0.5.4. After unpublishing v0.5.4, npm did not allow us to republish that version. So we skipped v0.5.4 and went straight to v0.5.5.

v0.5.4

We made an error when publishing this module. After unpublishing it, npm did not allow us to republish this version. So we've skipped this and moved on to v0.5.5.

V0.5.0

This version contains breaking changes. We apologize for this. AWS and the serverless landscape in general is changing. We are trying our best to keep up and offer a better user experience on top of everything without introducing breaking changes. But this release contains a few.

Breaking - Unique Function Names Required

All of your functions must have unique names project-wide. For example, users/show should become users/usersShow. Serverless will throw an error on initialization if your function names are not unique.

How to upgrade: Change your function names to be unique.

Breaking - Removed Components While Keeping and Improving Its Functionality

We've removed the concept of Components and instead improved our nested folders functionality to give you complete control over how you want to structure your project. As a result there's no s-component.json anymore, and the runtime is managed at the function level. So your s-function.json should now have a runtime property with the value nodejs or python2.7. That also means that you can create a function in the root of your project directly with sls function create myFunc or you can nested as much as you want with sls function create functions/subfolder/myFunc. If you have settings on s-component.json they will no longer be applicable. We recommend using Project Templates to store any s-component.json settings instead.

This change affects the default function name we give to your functions when they are deployed. This will cause issues when you upgrade from V0.4 to V0.5 as your functions will be renamed when deployed on AWS.

How to upgrade: Redeploy your functions. We also recommend taking advantage of the customName property in s-function.json if you aren't already. The new default function name when deployed is simply project-function.

Flexible Dependency Management via Magic Handlers

Now that you have complete control over how you organize your functions, we've come up with the concept of "magic handlers" to give you more control on what you want to be deployed along with your function and how you want to handle function dependencies. We're referring to the handler property of the s-function.json file. Depending on which parent folder this handler path is relative to, your lambda function will be zipped up from that parent folder and deployed to AWS.

By default the handler is set to handler.handler. That means it's only relative to the function folder, so only the function folder will be deployed to Lambda. If however you want to include the parent subfolder of a function, you should change the handler to be like this: myFunc/handler.handler. As you can see, the path to the handler now includes the function folder, which means that the path is now relative to the parent subfolder, so in that case the parent subfolder will be deployed along with your function. So if you have a lib folder in that parent subfolder that is required by your function, it'll be deployed with your function. This also gives you the ability to handle npm dependencies however you like. If you have a package.json and node_modules in that parent subfolder, it'll be included in the deployed lambda. So the more parent folders you include in the handler path, the upper you go in the file tree.

Breaking - Multiple s-resources-cf.json files

We are removing the ability to have resources nested in your function subfolders. The reason for this is we have received a lot of feedback that resources should be broken up into separate, smaller resource stacks, instead of one resource stack defined by separate resource files. This follows microservice patterns more closely, with resource separation per microservice. We are considering implementing this in the near future.

How to upgrade: Merge your s-resources-cf.json files into a single file that is kept at the root of your project.

Breaking - Removal Of Project Buckets, Changing Environment Variable Handling

Project buckets were more useful when we started Serverless/JAWS several months ago. However, AWS continues to improve Lambda, making Project Buckets less relevant. As a result, we've decided to remove them, to reduce complexity. This will break how your project handles Environment Variables, since they used to be stored in Project Buckets.

How to upgrade: You will need to transfer your environment variables from S3 to your s-function.json files. Environment variables are now stored in an environment object, in your s-function.json file, like this:

"environment": {
    "MY_ENV_VAR": "VALUE"
}

However, we recommend not putting Environment Variable values in the environment object, and only putting in Serverless Project Variables as values instead. This allows your Env Variables to be different per stage and stage+region within your project. It also isolates all sensitive data to your _meta folder, which you should now always .gitignore.

"environment": {
    "MY_ENV_VAR": "${env_myenvvar}" // Kept in _meta/variables and changes depending on stage/region
}

Over the next few days, we will introduce a plugin that will help developers working on the same project sync their _meta folder across teams, securely via S3. Until then, make sure you .gitignore your _meta folder in your existing project.

Serverless-Helpers-JS No Longer Needed

The serverless-helpers-js module is no longer needed. Environment variables are automatically inlined into your function when they are run locally AND deployed. This is done by switching your handler with another one on FunctionRun and FunctionDeploy. The handler is titled _serverless_handler and it contains your Environment Variables.

Added Support for Multiple AWS Accounts for Your Stages

You can now have a new aws account/profile for each of your stages, making it more efficient to work with big teams. When you create a new stage, you will be prompted for which profile to use with that stage. You can create a new profile at this time as well.

Added API Gateway Custom Authorizers Support

API Gateway custom authorizers now allow you to call a Lambda function containing authorization logic, before calling the lambda function containing your application logic. This is called a custom authorizer.

We've added support for this new API Gateway feature into the Framework and improved the user experience. Here is how it works:

The Function that you want to be an authorizer (runs the authorization logic) must have a authorizer property in its s-function.json wth these properties:

"name": "auth",
"authorizer": {
    "type": "TOKEN",
    "identitySource": "method.request.header.Authorization"
},

Endpoints that require that custom authorizer must contain these properties:

"authorizationType": "CUSTOM",
"authorizerFunction": "auth", // Name of the function in your project that does authorization 

Function Deploy Is Now 2x Faster

Previously, we used to backup your lambda functions on the project S3 bucket whenever you deploy a function, which slowed down the deployment. We did this to get extra space in case you reached the 1.5GB lambda limit, which is easily reachable with versioning. But since AWS announced it's increasing the quote to be 75GB instead of 1.5GB, we decided it's time to ditch this functionality and keep FunctionDeploy fast.

Added 5 New Actions

Function Remove sls function remove: This action removes a function from your AWS account along with any Endpoints and Events tied to your function. For more info about this new action checkout the v0.5 docs.

Endpoint Remove sls endpoint remove: This action removes an endpoint from your AWS account. For more info about this new action checkout the v0.5 docs.

Event Remove sls event remove: This action removes an event from your AWS account. For more info about this new action checkout the v0.5 docs.

Function Rollback sls function rollback: This action rolls your function back to a previously deployed version. For more info about this new action checkout the v0.5 docs.

Resources Diff sls resources diff: This action outputs the differences between your deployed resources and the resources currently defined in your project locally. For more info about this new action checkout the v0.5 docs.

Introducing Runtimes. Plus, You Can Add your Own Runtimes

All Runtime logic is now isolated to Runtime-specific classes. They are available on the serverless instance in the classes property. You can add your own Runtime through a plugin by simply adding a new Runtime class to the main Serverless instance. We've already created a custom babe runtime, which you can reference here: https://github.com/serverless/serverless-runtime-babel When you install this plugin, you will have a babel runtime option. It supports scaffolding babel functions, running them locally, and deploying them with optional optimizations.

Removed Function/Endpoint/Event Paths Concept

To make our CLI easier to use, we've removed the concept of Function/Endpoint/Event paths. Instead, the names of these assets should be unique project wide. This way, you can simply run sls function deploy myFunc instead of sls function deploy path/to/myFunc. Names are what we use to identify Functions/Endpoints/Events.

Although Endpoints don't have a name property, the endpoint name is simply the combination of the endpoint path with the endpoint method separated by ~ symbol, which is always unique project wide. (ie. `user/...