{"_id":"56bacbea4aa5930d00da77fd","sync_unique":"","type":"basic","body":"In 2014, Amazon Web Services released a groundbreaking service called [AWS Lambda](https://aws.amazon.com/lambda/) that offers a new way to deploy your *web*, *mobile* or *IoT* application's code to the cloud.  Instead of deploying the entire codebase of your app all at once, with Lambda you deploy each of your application's functions individually, to their own containers.  Overall, Lambda is groundbreaking for three reasons:\n\n* ##### **Pay-Per-Use Pricing**\nAWS Lambda charges you only when your functions are run.  No more monthly-based billing for servers, no more wasted dollars spent on under-utilized servers.  There is no such thing as under-utilization with AWS Lambda. \n\n* ##### **Unprecedented Agility**\nLambda offers ready to go containers and orchestration out-of-the-box, leaving you free to decide how you would like to containerize your logic.  You can choose a monolithic, microservices, or nanoservices approach with Lambda.  Read more about that in our [Overview](http://docs.serverless.com/docs/introducing-serverless).\n\n* ##### **No Servers**\nEvery Lambda function container auto-scales automatically when called concurrently.  Since your functions can scale massively out-of-the-box, you no longer have to think about scaling/managing servers, Amazon deals with that.  You focus only on building your product, wit.\n\nHowever... while AWS Lambda offers a powerful new way of developing/running applications, when we began building our first project based entirely on AWS Lambda, we realized structure was badly needed.  Managing all of the containers that Lambda introduces is a difficult task.  Add to that multi-developer teams, multi-stage and multi-region support and you will quickly get into a messy situation.\n\nThus, the [Serverless Framework](https://github.com/serverless/serverless) was born.  The first and most powerful framework for building applications exclusively on AWS Lambda.","category":"56bacbe74aa5930d00da77d9","createdAt":"2015-12-21T07:29:38.121Z","order":0,"project":"5611c207f2aeda0d002b3734","updates":["56bc374fb228ec0d00cb3fc8"],"user":"5611c1e58c76a61900fd0739","version":"56bacbe64aa5930d00da77d8","githubsync":"","hidden":false,"link_url":"","__v":3,"excerpt":"How the Serverless Framework Was Born","link_external":false,"title":"Backstory","api":{"auth":"required","params":[],"results":{"codes":[{"language":"json","code":"{}","name":"","status":200},{"code":"{}","name":"","status":400,"language":"json"}]},"settings":"","url":""},"slug":"backstory","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Backstory

How the Serverless Framework Was Born

In 2014, Amazon Web Services released a groundbreaking service called [AWS Lambda](https://aws.amazon.com/lambda/) that offers a new way to deploy your *web*, *mobile* or *IoT* application's code to the cloud. Instead of deploying the entire codebase of your app all at once, with Lambda you deploy each of your application's functions individually, to their own containers. Overall, Lambda is groundbreaking for three reasons: * ##### **Pay-Per-Use Pricing** AWS Lambda charges you only when your functions are run. No more monthly-based billing for servers, no more wasted dollars spent on under-utilized servers. There is no such thing as under-utilization with AWS Lambda. * ##### **Unprecedented Agility** Lambda offers ready to go containers and orchestration out-of-the-box, leaving you free to decide how you would like to containerize your logic. You can choose a monolithic, microservices, or nanoservices approach with Lambda. Read more about that in our [Overview](http://docs.serverless.com/docs/introducing-serverless). * ##### **No Servers** Every Lambda function container auto-scales automatically when called concurrently. Since your functions can scale massively out-of-the-box, you no longer have to think about scaling/managing servers, Amazon deals with that. You focus only on building your product, wit. However... while AWS Lambda offers a powerful new way of developing/running applications, when we began building our first project based entirely on AWS Lambda, we realized structure was badly needed. Managing all of the containers that Lambda introduces is a difficult task. Add to that multi-developer teams, multi-stage and multi-region support and you will quickly get into a messy situation. Thus, the [Serverless Framework](https://github.com/serverless/serverless) was born. The first and most powerful framework for building applications exclusively on AWS Lambda.
In 2014, Amazon Web Services released a groundbreaking service called [AWS Lambda](https://aws.amazon.com/lambda/) that offers a new way to deploy your *web*, *mobile* or *IoT* application's code to the cloud. Instead of deploying the entire codebase of your app all at once, with Lambda you deploy each of your application's functions individually, to their own containers. Overall, Lambda is groundbreaking for three reasons: * ##### **Pay-Per-Use Pricing** AWS Lambda charges you only when your functions are run. No more monthly-based billing for servers, no more wasted dollars spent on under-utilized servers. There is no such thing as under-utilization with AWS Lambda. * ##### **Unprecedented Agility** Lambda offers ready to go containers and orchestration out-of-the-box, leaving you free to decide how you would like to containerize your logic. You can choose a monolithic, microservices, or nanoservices approach with Lambda. Read more about that in our [Overview](http://docs.serverless.com/docs/introducing-serverless). * ##### **No Servers** Every Lambda function container auto-scales automatically when called concurrently. Since your functions can scale massively out-of-the-box, you no longer have to think about scaling/managing servers, Amazon deals with that. You focus only on building your product, wit. However... while AWS Lambda offers a powerful new way of developing/running applications, when we began building our first project based entirely on AWS Lambda, we realized structure was badly needed. Managing all of the containers that Lambda introduces is a difficult task. Add to that multi-developer teams, multi-stage and multi-region support and you will quickly get into a messy situation. Thus, the [Serverless Framework](https://github.com/serverless/serverless) was born. The first and most powerful framework for building applications exclusively on AWS Lambda.
{"_id":"56bacbea4aa5930d00da77fe","body":"Serverless is an application framework for building serverless web, mobile and IoT applications exclusively on [AWS Lambda](https://aws.amazon.com/lambda/).  A Serverless app can simply be a couple of lambda functions to accomplish some tasks, or an entire back-end comprised of hundreds of lambda functions. Serverless currently supports `nodejs` and `python2.7` runtimes. Support for `Java` and other future runtimes that AWS Lambda will support will be coming soon.\n\nServerless comes in the form of a Node.js command line interface that provides structure, automation and optimization to help you build and maintain Serverless apps.  The CLI allows you to control your Lambdas, API Gateway Endpoints as well as your AWS resources via AWS CloudFormation.  Overall, we've made a strong effort to make not just a groundbreaking Serverless framework, but the best framework for building applications with AWS in general (that is also Serverless!). As a result, Serverless incorporates years of AWS expertise into its tooling, giving you best practices out-of-the-box.  Serverless does not seek to conceal AWS in abstraction, but to put structure around the AWS SDK and CloudFormation, and approach Amazon Web Services and all that it offers from the focal point of Lambda.  In the future, we believe that Lambda will be the focal point of AWS.\n\nLastly, we work full time on this and are funded by a top tier VC firm in Silicon Valley.  We are here for the long-term to support developers building Serverless applications.  Don't hesitate to [email us](mailto:[email protected]) and ask us for help.  Also, we're growing our team.  If the Serverless architecture appeals to you or you just want to make awesome tools for other developers, please [let us know](mailto:[email protected]).","githubsync":"","hidden":false,"link_external":false,"slug":"introducing-serverless","sync_unique":"","__v":1,"title":"Overview","type":"basic","project":"5611c207f2aeda0d002b3734","api":{"auth":"required","params":[],"results":{"codes":[{"code":"{}","name":"","status":200,"language":"json"},{"name":"","status":400,"language":"json","code":"{}"}]},"settings":"","url":""},"category":"56bacbe74aa5930d00da77d9","link_url":"","updates":["56a0f884e7056c170060b914"],"user":"562120887c515c0d008eee9b","version":"56bacbe64aa5930d00da77d8","excerpt":"What the Framework Does","order":1,"createdAt":"2015-10-16T17:26:09.813Z","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Overview

What the Framework Does

Serverless is an application framework for building serverless web, mobile and IoT applications exclusively on [AWS Lambda](https://aws.amazon.com/lambda/). A Serverless app can simply be a couple of lambda functions to accomplish some tasks, or an entire back-end comprised of hundreds of lambda functions. Serverless currently supports `nodejs` and `python2.7` runtimes. Support for `Java` and other future runtimes that AWS Lambda will support will be coming soon. Serverless comes in the form of a Node.js command line interface that provides structure, automation and optimization to help you build and maintain Serverless apps. The CLI allows you to control your Lambdas, API Gateway Endpoints as well as your AWS resources via AWS CloudFormation. Overall, we've made a strong effort to make not just a groundbreaking Serverless framework, but the best framework for building applications with AWS in general (that is also Serverless!). As a result, Serverless incorporates years of AWS expertise into its tooling, giving you best practices out-of-the-box. Serverless does not seek to conceal AWS in abstraction, but to put structure around the AWS SDK and CloudFormation, and approach Amazon Web Services and all that it offers from the focal point of Lambda. In the future, we believe that Lambda will be the focal point of AWS. Lastly, we work full time on this and are funded by a top tier VC firm in Silicon Valley. We are here for the long-term to support developers building Serverless applications. Don't hesitate to [email us](mailto:[email protected]) and ask us for help. Also, we're growing our team. If the Serverless architecture appeals to you or you just want to make awesome tools for other developers, please [let us know](mailto:[email protected]).
Serverless is an application framework for building serverless web, mobile and IoT applications exclusively on [AWS Lambda](https://aws.amazon.com/lambda/). A Serverless app can simply be a couple of lambda functions to accomplish some tasks, or an entire back-end comprised of hundreds of lambda functions. Serverless currently supports `nodejs` and `python2.7` runtimes. Support for `Java` and other future runtimes that AWS Lambda will support will be coming soon. Serverless comes in the form of a Node.js command line interface that provides structure, automation and optimization to help you build and maintain Serverless apps. The CLI allows you to control your Lambdas, API Gateway Endpoints as well as your AWS resources via AWS CloudFormation. Overall, we've made a strong effort to make not just a groundbreaking Serverless framework, but the best framework for building applications with AWS in general (that is also Serverless!). As a result, Serverless incorporates years of AWS expertise into its tooling, giving you best practices out-of-the-box. Serverless does not seek to conceal AWS in abstraction, but to put structure around the AWS SDK and CloudFormation, and approach Amazon Web Services and all that it offers from the focal point of Lambda. In the future, we believe that Lambda will be the focal point of AWS. Lastly, we work full time on this and are funded by a top tier VC firm in Silicon Valley. We are here for the long-term to support developers building Serverless applications. Don't hesitate to [email us](mailto:[email protected]) and ask us for help. Also, we're growing our team. If the Serverless architecture appeals to you or you just want to make awesome tools for other developers, please [let us know](mailto:[email protected]).
{"_id":"56bacbea4aa5930d00da77ff","body":"AWS gives you a ton of free resources whenever you create a new AWS account. This is called the free tier. It includes a massive allowance of free Lambda Requests, DynamoDB tables, S3 storage, and more. Before building Serverless apps, we strongly recommend starting with a fresh AWS account for maximum cost savings.\n\n# Creating an Administrative IAM User\nThe Serverless Framework is one of the first application frameworks to manage both your code and infrastructure.  To manage your infrastructure on AWS, we're going to create an Admin user which can access and configure the services in your AWS account.  To get you up and running quickly, we're going to create a AWS IAM User with Administrative Access to your AWS account.\n[block:callout]\n{\n  \"type\": \"danger\",\n  \"body\": \"In a production environment we recommend reducing the permissions to the IAM User which the Framework uses.  Unfortunately, the Framework's functionality is growing so fast, we can't yet offer you a finite set of permissions it needs.  In the interim, ensure that your AWS API Keys are kept in a safe, private location.\",\n  \"title\": \"Admin Access to Your AWS Account\"\n}\n[/block]\nNow let's create an Admin IAM user:\n\n* Create or login to your Amazon Web Services Account and go the the Identity & Access Management (IAM) Page.\n* Click on **Users** and then Create New Users. Enter *serverless-admin* in the first field and click **Create**.\n* View and copy the security credentials/API Keys in a safe place.\n* In the User record in the AWS IAM Dashboard, look for **Managed Policies** on the **Permissions** tab and click **Attach Policy**. In the next screen, search for and select **AdministratorAccess** then click **Attach**.\n\nWhen you go to create or install a Serverless Project, you will be prompted to enter your AWS Access Keys.  Once you enter them, they will be persisted to your Project's folder in the `admin.env` file.\n\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"AWS Profiles\",\n  \"body\": \"The Serverless Framework can also work with AWS Profiles already set on your computer.  In the Project Create or Project Install screens, it will detect your AWS Profiles and display them.  Select the one you want, and the AWS Access Keys for that profile will be persisted to your project.\"\n}\n[/block]","category":"56bacbe74aa5930d00da77d9","hidden":false,"api":{"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":"","auth":"required","params":[]},"link_external":false,"type":"basic","updates":["5629dbcb8437010d00c43bc5","567733077c62750d00dac222","56ca4df760118f0d00338226","56d23a0793f76e0b00bbc60f"],"user":"562120887c515c0d008eee9b","version":"56bacbe64aa5930d00da77d8","__v":8,"excerpt":"Configuring AWS and Giving Serverless Access to Your Account","githubsync":"","link_url":"","sync_unique":"","title":"Configuring AWS","createdAt":"2015-10-16T19:57:25.686Z","order":2,"project":"5611c207f2aeda0d002b3734","slug":"configuring-aws","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Configuring AWS

Configuring AWS and Giving Serverless Access to Your Account

AWS gives you a ton of free resources whenever you create a new AWS account. This is called the free tier. It includes a massive allowance of free Lambda Requests, DynamoDB tables, S3 storage, and more. Before building Serverless apps, we strongly recommend starting with a fresh AWS account for maximum cost savings. # Creating an Administrative IAM User The Serverless Framework is one of the first application frameworks to manage both your code and infrastructure. To manage your infrastructure on AWS, we're going to create an Admin user which can access and configure the services in your AWS account. To get you up and running quickly, we're going to create a AWS IAM User with Administrative Access to your AWS account. [block:callout] { "type": "danger", "body": "In a production environment we recommend reducing the permissions to the IAM User which the Framework uses. Unfortunately, the Framework's functionality is growing so fast, we can't yet offer you a finite set of permissions it needs. In the interim, ensure that your AWS API Keys are kept in a safe, private location.", "title": "Admin Access to Your AWS Account" } [/block] Now let's create an Admin IAM user: * Create or login to your Amazon Web Services Account and go the the Identity & Access Management (IAM) Page. * Click on **Users** and then Create New Users. Enter *serverless-admin* in the first field and click **Create**. * View and copy the security credentials/API Keys in a safe place. * In the User record in the AWS IAM Dashboard, look for **Managed Policies** on the **Permissions** tab and click **Attach Policy**. In the next screen, search for and select **AdministratorAccess** then click **Attach**. When you go to create or install a Serverless Project, you will be prompted to enter your AWS Access Keys. Once you enter them, they will be persisted to your Project's folder in the `admin.env` file. [block:callout] { "type": "info", "title": "AWS Profiles", "body": "The Serverless Framework can also work with AWS Profiles already set on your computer. In the Project Create or Project Install screens, it will detect your AWS Profiles and display them. Select the one you want, and the AWS Access Keys for that profile will be persisted to your project." } [/block]
AWS gives you a ton of free resources whenever you create a new AWS account. This is called the free tier. It includes a massive allowance of free Lambda Requests, DynamoDB tables, S3 storage, and more. Before building Serverless apps, we strongly recommend starting with a fresh AWS account for maximum cost savings. # Creating an Administrative IAM User The Serverless Framework is one of the first application frameworks to manage both your code and infrastructure. To manage your infrastructure on AWS, we're going to create an Admin user which can access and configure the services in your AWS account. To get you up and running quickly, we're going to create a AWS IAM User with Administrative Access to your AWS account. [block:callout] { "type": "danger", "body": "In a production environment we recommend reducing the permissions to the IAM User which the Framework uses. Unfortunately, the Framework's functionality is growing so fast, we can't yet offer you a finite set of permissions it needs. In the interim, ensure that your AWS API Keys are kept in a safe, private location.", "title": "Admin Access to Your AWS Account" } [/block] Now let's create an Admin IAM user: * Create or login to your Amazon Web Services Account and go the the Identity & Access Management (IAM) Page. * Click on **Users** and then Create New Users. Enter *serverless-admin* in the first field and click **Create**. * View and copy the security credentials/API Keys in a safe place. * In the User record in the AWS IAM Dashboard, look for **Managed Policies** on the **Permissions** tab and click **Attach Policy**. In the next screen, search for and select **AdministratorAccess** then click **Attach**. When you go to create or install a Serverless Project, you will be prompted to enter your AWS Access Keys. Once you enter them, they will be persisted to your Project's folder in the `admin.env` file. [block:callout] { "type": "info", "title": "AWS Profiles", "body": "The Serverless Framework can also work with AWS Profiles already set on your computer. In the Project Create or Project Install screens, it will detect your AWS Profiles and display them. Select the one you want, and the AWS Access Keys for that profile will be persisted to your project." } [/block]
{"_id":"56bacbea4aa5930d00da7800","title":"Installing Serverless","updates":["56706db2e10ecb0d0004ef52","567074d93d29830d00376234","56a6dd887ef6620d00e2f26a","56a8decec0e02f0d007fa91e","56c14432f203270d00d6c544","56ce7d719636b713006b0c78","56ce851a9636b713006b0c7c"],"__v":6,"api":{"auth":"required","params":[],"results":{"codes":[{"name":"","status":200,"language":"json","code":"{}"},{"language":"json","code":"{}","name":"","status":400}]},"settings":"","url":""},"category":"56bacbe74aa5930d00da77d9","createdAt":"2015-10-16T19:57:59.559Z","version":"56bacbe64aa5930d00da77d8","order":3,"slug":"installing-serverless","sync_unique":"","hidden":false,"link_url":"","project":"5611c207f2aeda0d002b3734","type":"basic","user":"562120887c515c0d008eee9b","body":"Now that you've configured AWS, you're ready to start using the Serverless framework. To install, simply run the following command:\n\n```\nnpm install serverless -g\n```\n\nAfter it installs, you can create a new project:\n\n```\nserverless project create\n```\nThe Serverless CLI will ask for a few pieces of information about your project (name, domain, email...etc). Serverless uses this information to build up your stack with [CloudFormation](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html). This process takes around 3 mins.\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Provisioning CloudFormation\",\n  \"body\": \"If you would like to create the project structure without AWS resources being provisioned, use `serverless project create -c true`.  You can inspect the generated CloudFormation and execute when ready.  For more info, [read the Project Create docs below](/project-create).\"\n}\n[/block]\nNow you have a barebones project that is pretty much useless. To make it a more useful, let's create a component, and a function. Make sure you're in the root directory of your newly created project, and then run:\n\n```\nserverless component create component1\nserverless function create component1/function1\n```\n\nThis will create a component named `component1` and a function inside that component named `function1`. Keep reading to learn more about components and functions.\n\nRun `serverless dash deploy` to open up the interactive deployment dashboard. Use the down arrow key to select the function and press enter.  Down arrow once more to select the endpoint and press the enter button again (so that both text items switch from grey to yellow). \nFinally, move to \"Deploy\" and hit enter.\n\nAfter deployment is complete, you will be given a URL. Visit this URL in your browser to see your new project deployed. Deployment couldn't get any simpler!\n\nYou now have a basic Serverless project, and you're ready to take a deep dive and explore the project structure.","excerpt":"Installing the Serverless Framework and Creating Your First Serverless Project","githubsync":"","link_external":false,"metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Installing Serverless

Installing the Serverless Framework and Creating Your First Serverless Project

Now that you've configured AWS, you're ready to start using the Serverless framework. To install, simply run the following command: ``` npm install serverless -g ``` After it installs, you can create a new project: ``` serverless project create ``` The Serverless CLI will ask for a few pieces of information about your project (name, domain, email...etc). Serverless uses this information to build up your stack with [CloudFormation](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html). This process takes around 3 mins. [block:callout] { "type": "info", "title": "Provisioning CloudFormation", "body": "If you would like to create the project structure without AWS resources being provisioned, use `serverless project create -c true`. You can inspect the generated CloudFormation and execute when ready. For more info, [read the Project Create docs below](/project-create)." } [/block] Now you have a barebones project that is pretty much useless. To make it a more useful, let's create a component, and a function. Make sure you're in the root directory of your newly created project, and then run: ``` serverless component create component1 serverless function create component1/function1 ``` This will create a component named `component1` and a function inside that component named `function1`. Keep reading to learn more about components and functions. Run `serverless dash deploy` to open up the interactive deployment dashboard. Use the down arrow key to select the function and press enter. Down arrow once more to select the endpoint and press the enter button again (so that both text items switch from grey to yellow). Finally, move to "Deploy" and hit enter. After deployment is complete, you will be given a URL. Visit this URL in your browser to see your new project deployed. Deployment couldn't get any simpler! You now have a basic Serverless project, and you're ready to take a deep dive and explore the project structure.
Now that you've configured AWS, you're ready to start using the Serverless framework. To install, simply run the following command: ``` npm install serverless -g ``` After it installs, you can create a new project: ``` serverless project create ``` The Serverless CLI will ask for a few pieces of information about your project (name, domain, email...etc). Serverless uses this information to build up your stack with [CloudFormation](http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html). This process takes around 3 mins. [block:callout] { "type": "info", "title": "Provisioning CloudFormation", "body": "If you would like to create the project structure without AWS resources being provisioned, use `serverless project create -c true`. You can inspect the generated CloudFormation and execute when ready. For more info, [read the Project Create docs below](/project-create)." } [/block] Now you have a barebones project that is pretty much useless. To make it a more useful, let's create a component, and a function. Make sure you're in the root directory of your newly created project, and then run: ``` serverless component create component1 serverless function create component1/function1 ``` This will create a component named `component1` and a function inside that component named `function1`. Keep reading to learn more about components and functions. Run `serverless dash deploy` to open up the interactive deployment dashboard. Use the down arrow key to select the function and press enter. Down arrow once more to select the endpoint and press the enter button again (so that both text items switch from grey to yellow). Finally, move to "Deploy" and hit enter. After deployment is complete, you will be given a URL. Visit this URL in your browser to see your new project deployed. Deployment couldn't get any simpler! You now have a basic Serverless project, and you're ready to take a deep dive and explore the project structure.
{"_id":"56bacbea4aa5930d00da7801","api":{"url":"","auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":""},"link_url":"","title":"Project Structure","link_external":false,"project":"5611c207f2aeda0d002b3734","sync_unique":"","__v":17,"createdAt":"2015-10-22T20:13:08.090Z","githubsync":"","hidden":false,"version":"56bacbe64aa5930d00da77d8","excerpt":"How Serverless Projects Look Like","order":0,"slug":"project-structure","type":"basic","body":"Serverless projects contain three tiers of organization with respective JSON files:\n\n```\ns-project.json  (Serverless project)\n     |__s-component.json  (Component with a specific runtime)\n             |__s-function.json  (Function with its Endpoints and Event Sources)\n```\n\nA basic Serverless project contains the following directory structure:\n```\ns-project.json\ns-resources-cf.json\nadmin.env\n.env\n_meta\n    |__resources\n         |__s-resources-cf-dev-useast1.json\n    |__variables\n         |__s-variables-common.json\n         |__s-variables-dev.json\n         |__s-variables-dev-useast1.json\ncomponent1\n    |__s-component.json\n    |__s-templates.json\n    |__package.json\n    |__lib\n        |__index.js\n    |__function1\n         |__event.json\n         |__handler.js\n         |__s-function.json\n```\nHere's the same directory structure with some explanation:\n```\ns-project.json (project and author data)\ns-resources-cf.json (CloudFormation template for all stages/regions)\nadmin.env (AWS API keys - gitignored)\n.env (local env vars - gitignored)\n_meta (meta data that holds stage/regions config and variables - gitignored)\n    |__resources (final CF templates for each stage/region)\n         |__s-resources-cf-dev-useast1.json\n    |__variables (variables specific to stages and regions)\n         |__s-variables-common.json\n         |__s-variables-dev.json\n         |__s-variables-dev-useast1.json\ncomponent1 (your first nodejs component)\n    |__s-component.json (data for your component - ie. runtime)\n    |__s-templates.json (reusable templates for your s-.json files)\n    |__package.json\n    |__lib\n        |__index.js\n    |__function1 (your first function)\n         |__event.json (sample event for testing function locally)\n         |__handler.js (your function handler)\n         |__s-function.json (data for your lambda function, endpoints and event sources)\n```\nNow let's dive deeper into the most critical pieces of a Serverless project:\n\n# Project\nWhen you create a new Serverless project, an S3 Bucket is created by the framework to hold all stages, regions, environment variables and CloudFormation template files (we call it a \"Project Bucket\"). Each Serverless Project contains an `s-project.json` file that holds project configuration and authorship details:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"{\\n  \\\"name\\\": \\\"projectName\\\",\\n  \\\"version\\\": \\\"0.0.1\\\",\\n  \\\"profile\\\": \\\"serverless-v0.1.0\\\",\\n  \\\"location\\\": \\\"https://github.com/...\\\",\\n  \\\"author\\\": \\\"authorName\\\",\\n  \\\"description\\\": \\\"A Slick New Serverless Project\\\",\\n  \\\"custom\\\": {}, // For plugin authors to add any properties that they need\\n  \\\"plugins\\\": []\\n}\",\n      \"language\": \"json\",\n      \"name\": \"s-project.json\"\n    }\n  ]\n}\n[/block]\n# Meta Data\nEach Serverless project contains a `_meta` folder in its root directory. This folder holds user specific project data, like stages, regions, CloudFormation template files and variables (more on variables later). Since this folder contains sensitive information, it's gitignored by default, allowing you to share your Serverless projects with others, where they can add their own meta data.\n\n# Components\nComponents hold all the functions of a specific runtime (ie. nodejs) together, allowing you to share code across functions. Most Serverless projects will only need one component (if you'll only work with a single runtime), or it can contain multiple components for several runtimes. You can also create separate components for the same runtime if you feel it'll make your project more organized. You can configure your component in the `s-component.json` file:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"{\\n  \\\"name\\\": \\\"myComponent\\\",\\n  \\\"runtime\\\": \\\"nodejs\\\",\\n  \\\"custom\\\": {} // For plugin authors to add any properties that they need\\n}\",\n      \"language\": \"json\",\n      \"name\": \"s-component.json\"\n    }\n  ]\n}\n[/block]\n## Functions\nThis is the final piece of a Serverless project. Each component contains several functions that accomplish specific tasks. These are the functions that get deployed to AWS Lambda. All functions within a component can use the `lib` folder of that component, allowing you to reuse code and keep your project organized.\n\nEach function can have several endpoints, and each endpoint can have several methods (ie. GET, POST...etc). These are the endpoints that get deployed to AWS API Gateway and they all point to the Function that they're defined within. Functions can also have several event sources (i.e. DynamoDB, S3..etc). You can configure your Lambda Function, its Endpoints and Events in the `s-function.json` file:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"{\\n  \\\"name\\\": \\\"functionName\\\",\\n  \\\"customName\\\": false,  // Custom name for your deployed Lambda function\\n  \\\"customRole\\\": false,  // Custom IAM Role for your deployed Lambda function\\n  \\\"handler\\\": \\\"function1/handler.handler\\\", // path of the handler relative to the function root\\n  \\\"runtime\\\": \\\"nodejs\\\",\\n  \\\"timeout\\\": 6,\\n  \\\"memorySize\\\": 1024,\\n  \\\"custom\\\": {\\n    \\\"excludePatterns\\\": [], // an array of whatever you don't want to deploy with the function\\n    \\\"envVars\\\": [] // env vars needed by this function\\n  },\\n  \\\"events\\\": [ // event sources for this lambda\\n    {\\n      \\\"name\\\" : \\\"myEventSource\\\", // unique name for this event source\\n      \\\"type\\\": \\\"schedule\\\", // type of event source\\n      \\\"config\\\": {\\n         \\\"schedule\\\": \\\"rate(5 minutes)\\\"\\n      }\\n    }\\n], \\n  \\\"endpoints\\\": [ // an array of endpoints that will invoke this lambda function\\n    {\\n      \\\"path\\\": \\\"function1\\\",\\n      \\\"method\\\": \\\"GET\\\",\\n      \\\"authorizationType\\\": \\\"none\\\",\\n      \\\"apiKeyRequired\\\": false,\\n      \\\"requestParameters\\\": {},\\n      \\\"requestTemplates\\\": {\\n        \\\"application/json\\\": \\\"\\\"\\n      },\\n      \\\"responses\\\": {\\n        \\\"400\\\": {\\n          \\\"selectionPattern\\\": \\\"^\\\\\\\\[BadRequest\\\\\\\\].*\\\", // selectionPattern is mapped to the Lambda Error Regex\\n          \\\"statusCode\\\": \\\"400\\\" // HTTP Status that is returned as part of the regex matching\\n        },\\n        \\\"403\\\": {\\n          \\\"selectionPattern\\\": \\\"^\\\\\\\\[Forbidden\\\\\\\\].*\\\",\\n          \\\"statusCode\\\": \\\"403\\\"\\n        },\\n        \\\"404\\\": {\\n          \\\"selectionPattern\\\": \\\"^\\\\\\\\[NotFound\\\\\\\\].*\\\",\\n          \\\"statusCode\\\": \\\"404\\\"\\n        },\\n        \\\"default\\\": {\\n          \\\"statusCode\\\": \\\"200\\\",\\n          \\\"responseParameters\\\": {},\\n          \\\"responseModels\\\": {},\\n          \\\"responseTemplates\\\": {\\n            \\\"application/json\\\": \\\"\\\"\\n          }\\n        }\\n      }\\n    }\\n  ]\\n}\",\n      \"language\": \"json\",\n      \"name\": \"s-function.json\"\n    }\n  ]\n}\n[/block]\nFor more information about the `s-function.json` file, check out the [Function Configuration section](/docs/function-configuration).","category":"56bc3b9430784e0d001b4a5e","updates":["567345d48565060d009a863f","56a6dcb448120d21000e52d6","56a9bb24f834950d0037b396","56b8d89143bbd10d0081d1c5"],"user":"562120887c515c0d008eee9b","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Project Structure

How Serverless Projects Look Like

Serverless projects contain three tiers of organization with respective JSON files: ``` s-project.json (Serverless project) |__s-component.json (Component with a specific runtime) |__s-function.json (Function with its Endpoints and Event Sources) ``` A basic Serverless project contains the following directory structure: ``` s-project.json s-resources-cf.json admin.env .env _meta |__resources |__s-resources-cf-dev-useast1.json |__variables |__s-variables-common.json |__s-variables-dev.json |__s-variables-dev-useast1.json component1 |__s-component.json |__s-templates.json |__package.json |__lib |__index.js |__function1 |__event.json |__handler.js |__s-function.json ``` Here's the same directory structure with some explanation: ``` s-project.json (project and author data) s-resources-cf.json (CloudFormation template for all stages/regions) admin.env (AWS API keys - gitignored) .env (local env vars - gitignored) _meta (meta data that holds stage/regions config and variables - gitignored) |__resources (final CF templates for each stage/region) |__s-resources-cf-dev-useast1.json |__variables (variables specific to stages and regions) |__s-variables-common.json |__s-variables-dev.json |__s-variables-dev-useast1.json component1 (your first nodejs component) |__s-component.json (data for your component - ie. runtime) |__s-templates.json (reusable templates for your s-.json files) |__package.json |__lib |__index.js |__function1 (your first function) |__event.json (sample event for testing function locally) |__handler.js (your function handler) |__s-function.json (data for your lambda function, endpoints and event sources) ``` Now let's dive deeper into the most critical pieces of a Serverless project: # Project When you create a new Serverless project, an S3 Bucket is created by the framework to hold all stages, regions, environment variables and CloudFormation template files (we call it a "Project Bucket"). Each Serverless Project contains an `s-project.json` file that holds project configuration and authorship details: [block:code] { "codes": [ { "code": "{\n \"name\": \"projectName\",\n \"version\": \"0.0.1\",\n \"profile\": \"serverless-v0.1.0\",\n \"location\": \"https://github.com/...\",\n \"author\": \"authorName\",\n \"description\": \"A Slick New Serverless Project\",\n \"custom\": {}, // For plugin authors to add any properties that they need\n \"plugins\": []\n}", "language": "json", "name": "s-project.json" } ] } [/block] # Meta Data Each Serverless project contains a `_meta` folder in its root directory. This folder holds user specific project data, like stages, regions, CloudFormation template files and variables (more on variables later). Since this folder contains sensitive information, it's gitignored by default, allowing you to share your Serverless projects with others, where they can add their own meta data. # Components Components hold all the functions of a specific runtime (ie. nodejs) together, allowing you to share code across functions. Most Serverless projects will only need one component (if you'll only work with a single runtime), or it can contain multiple components for several runtimes. You can also create separate components for the same runtime if you feel it'll make your project more organized. You can configure your component in the `s-component.json` file: [block:code] { "codes": [ { "code": "{\n \"name\": \"myComponent\",\n \"runtime\": \"nodejs\",\n \"custom\": {} // For plugin authors to add any properties that they need\n}", "language": "json", "name": "s-component.json" } ] } [/block] ## Functions This is the final piece of a Serverless project. Each component contains several functions that accomplish specific tasks. These are the functions that get deployed to AWS Lambda. All functions within a component can use the `lib` folder of that component, allowing you to reuse code and keep your project organized. Each function can have several endpoints, and each endpoint can have several methods (ie. GET, POST...etc). These are the endpoints that get deployed to AWS API Gateway and they all point to the Function that they're defined within. Functions can also have several event sources (i.e. DynamoDB, S3..etc). You can configure your Lambda Function, its Endpoints and Events in the `s-function.json` file: [block:code] { "codes": [ { "code": "{\n \"name\": \"functionName\",\n \"customName\": false, // Custom name for your deployed Lambda function\n \"customRole\": false, // Custom IAM Role for your deployed Lambda function\n \"handler\": \"function1/handler.handler\", // path of the handler relative to the function root\n \"runtime\": \"nodejs\",\n \"timeout\": 6,\n \"memorySize\": 1024,\n \"custom\": {\n \"excludePatterns\": [], // an array of whatever you don't want to deploy with the function\n \"envVars\": [] // env vars needed by this function\n },\n \"events\": [ // event sources for this lambda\n {\n \"name\" : \"myEventSource\", // unique name for this event source\n \"type\": \"schedule\", // type of event source\n \"config\": {\n \"schedule\": \"rate(5 minutes)\"\n }\n }\n], \n \"endpoints\": [ // an array of endpoints that will invoke this lambda function\n {\n \"path\": \"function1\",\n \"method\": \"GET\",\n \"authorizationType\": \"none\",\n \"apiKeyRequired\": false,\n \"requestParameters\": {},\n \"requestTemplates\": {\n \"application/json\": \"\"\n },\n \"responses\": {\n \"400\": {\n \"selectionPattern\": \"^\\\\[BadRequest\\\\].*\", // selectionPattern is mapped to the Lambda Error Regex\n \"statusCode\": \"400\" // HTTP Status that is returned as part of the regex matching\n },\n \"403\": {\n \"selectionPattern\": \"^\\\\[Forbidden\\\\].*\",\n \"statusCode\": \"403\"\n },\n \"404\": {\n \"selectionPattern\": \"^\\\\[NotFound\\\\].*\",\n \"statusCode\": \"404\"\n },\n \"default\": {\n \"statusCode\": \"200\",\n \"responseParameters\": {},\n \"responseModels\": {},\n \"responseTemplates\": {\n \"application/json\": \"\"\n }\n }\n }\n }\n ]\n}", "language": "json", "name": "s-function.json" } ] } [/block] For more information about the `s-function.json` file, check out the [Function Configuration section](/docs/function-configuration).
Serverless projects contain three tiers of organization with respective JSON files: ``` s-project.json (Serverless project) |__s-component.json (Component with a specific runtime) |__s-function.json (Function with its Endpoints and Event Sources) ``` A basic Serverless project contains the following directory structure: ``` s-project.json s-resources-cf.json admin.env .env _meta |__resources |__s-resources-cf-dev-useast1.json |__variables |__s-variables-common.json |__s-variables-dev.json |__s-variables-dev-useast1.json component1 |__s-component.json |__s-templates.json |__package.json |__lib |__index.js |__function1 |__event.json |__handler.js |__s-function.json ``` Here's the same directory structure with some explanation: ``` s-project.json (project and author data) s-resources-cf.json (CloudFormation template for all stages/regions) admin.env (AWS API keys - gitignored) .env (local env vars - gitignored) _meta (meta data that holds stage/regions config and variables - gitignored) |__resources (final CF templates for each stage/region) |__s-resources-cf-dev-useast1.json |__variables (variables specific to stages and regions) |__s-variables-common.json |__s-variables-dev.json |__s-variables-dev-useast1.json component1 (your first nodejs component) |__s-component.json (data for your component - ie. runtime) |__s-templates.json (reusable templates for your s-.json files) |__package.json |__lib |__index.js |__function1 (your first function) |__event.json (sample event for testing function locally) |__handler.js (your function handler) |__s-function.json (data for your lambda function, endpoints and event sources) ``` Now let's dive deeper into the most critical pieces of a Serverless project: # Project When you create a new Serverless project, an S3 Bucket is created by the framework to hold all stages, regions, environment variables and CloudFormation template files (we call it a "Project Bucket"). Each Serverless Project contains an `s-project.json` file that holds project configuration and authorship details: [block:code] { "codes": [ { "code": "{\n \"name\": \"projectName\",\n \"version\": \"0.0.1\",\n \"profile\": \"serverless-v0.1.0\",\n \"location\": \"https://github.com/...\",\n \"author\": \"authorName\",\n \"description\": \"A Slick New Serverless Project\",\n \"custom\": {}, // For plugin authors to add any properties that they need\n \"plugins\": []\n}", "language": "json", "name": "s-project.json" } ] } [/block] # Meta Data Each Serverless project contains a `_meta` folder in its root directory. This folder holds user specific project data, like stages, regions, CloudFormation template files and variables (more on variables later). Since this folder contains sensitive information, it's gitignored by default, allowing you to share your Serverless projects with others, where they can add their own meta data. # Components Components hold all the functions of a specific runtime (ie. nodejs) together, allowing you to share code across functions. Most Serverless projects will only need one component (if you'll only work with a single runtime), or it can contain multiple components for several runtimes. You can also create separate components for the same runtime if you feel it'll make your project more organized. You can configure your component in the `s-component.json` file: [block:code] { "codes": [ { "code": "{\n \"name\": \"myComponent\",\n \"runtime\": \"nodejs\",\n \"custom\": {} // For plugin authors to add any properties that they need\n}", "language": "json", "name": "s-component.json" } ] } [/block] ## Functions This is the final piece of a Serverless project. Each component contains several functions that accomplish specific tasks. These are the functions that get deployed to AWS Lambda. All functions within a component can use the `lib` folder of that component, allowing you to reuse code and keep your project organized. Each function can have several endpoints, and each endpoint can have several methods (ie. GET, POST...etc). These are the endpoints that get deployed to AWS API Gateway and they all point to the Function that they're defined within. Functions can also have several event sources (i.e. DynamoDB, S3..etc). You can configure your Lambda Function, its Endpoints and Events in the `s-function.json` file: [block:code] { "codes": [ { "code": "{\n \"name\": \"functionName\",\n \"customName\": false, // Custom name for your deployed Lambda function\n \"customRole\": false, // Custom IAM Role for your deployed Lambda function\n \"handler\": \"function1/handler.handler\", // path of the handler relative to the function root\n \"runtime\": \"nodejs\",\n \"timeout\": 6,\n \"memorySize\": 1024,\n \"custom\": {\n \"excludePatterns\": [], // an array of whatever you don't want to deploy with the function\n \"envVars\": [] // env vars needed by this function\n },\n \"events\": [ // event sources for this lambda\n {\n \"name\" : \"myEventSource\", // unique name for this event source\n \"type\": \"schedule\", // type of event source\n \"config\": {\n \"schedule\": \"rate(5 minutes)\"\n }\n }\n], \n \"endpoints\": [ // an array of endpoints that will invoke this lambda function\n {\n \"path\": \"function1\",\n \"method\": \"GET\",\n \"authorizationType\": \"none\",\n \"apiKeyRequired\": false,\n \"requestParameters\": {},\n \"requestTemplates\": {\n \"application/json\": \"\"\n },\n \"responses\": {\n \"400\": {\n \"selectionPattern\": \"^\\\\[BadRequest\\\\].*\", // selectionPattern is mapped to the Lambda Error Regex\n \"statusCode\": \"400\" // HTTP Status that is returned as part of the regex matching\n },\n \"403\": {\n \"selectionPattern\": \"^\\\\[Forbidden\\\\].*\",\n \"statusCode\": \"403\"\n },\n \"404\": {\n \"selectionPattern\": \"^\\\\[NotFound\\\\].*\",\n \"statusCode\": \"404\"\n },\n \"default\": {\n \"statusCode\": \"200\",\n \"responseParameters\": {},\n \"responseModels\": {},\n \"responseTemplates\": {\n \"application/json\": \"\"\n }\n }\n }\n }\n ]\n}", "language": "json", "name": "s-function.json" } ] } [/block] For more information about the `s-function.json` file, check out the [Function Configuration section](/docs/function-configuration).
{"_id":"56bc0e16f7951a19007abbac","githubsync":"","slug":"resources","type":"basic","user":"5611c1e58c76a61900fd0739","api":{"auth":"required","params":[],"results":{"codes":[{"language":"json","code":"{}","name":"","status":200},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"category":"56bc3b9430784e0d001b4a5e","order":1,"title":"Project Resources","excerpt":"Using CloudFormation Resources in Your Serverless Project","createdAt":"2016-02-11T04:29:10.807Z","hidden":false,"link_external":false,"__v":8,"body":"The Serverless framework keeps one CloudFormation template in the root of your project by default, labeled `s-resources-cf.json`. To better organize your resources alongside your business logic, you can include more `s-resources-cf.json` files in the root of your project, component, and in the root of a component subfolder. This allows you to specify resources specifically for all of the functions in that subfolder (e.g., custom lambda policies, DynamoDB tables your functions use, etc.).  Please note, when a `s-resources-cf.json` file is in a component or subfolder within a component, it can only have the following root properties, which we use to easily merge this file's assets into the `s-resources-cf.json` in your project root: `Resources` and `LambdaIamPolicyStatements`.\n\nThe Framework comes with commands you can use to automatically deploy your resources, or remove them.  When you run `serverless resources deploy`, the following happens:\n\n* We dynamically create a new CloudFormation template, starting by copying the `s-resources-cf.json` in the root of your Project.\n* The `s-resources-cf.json` files in your Components and their subfolders are merged into the dynamic CloudFormation template. \n* Any Project Templates or Variables in the dynamic CloudFormation template are populated.\n* The dynamic CloudFormation file is then saved to your Project's `_meta/resources` folder, in the stage and region your are deploying to.  If you specified the `noExeCf` option, this command will stop here and not upload the file to CloudFormation.\n* The staged and region'ed CloudFormation file is then uploaded to CloudFormation and we trigger a Stack Update based off of it.\n\nYou also have the ability to remove CloudFormation Stacks in Project Stages and Regions via the `serverless resources remove` command.\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"Don't Upload `s-resources-cf.json to AWS\",\n  \"body\": \"The `s-resources-cf.json` file is not ready for deployment to AWS because it contains variables that needs to be populated first. You can deploy the CF template files that reside in the `_meta/resources` folder instead, as these are the files that are generated after populating the variables (i.e. stage/region variables). [Click here for more info about templates and variables.](http://docs.serverless.com/v0.4.0/docs/templates-variables).\"\n}\n[/block]","sync_unique":"","updates":[],"version":"56bacbe64aa5930d00da77d8","link_url":"","project":"5611c207f2aeda0d002b3734","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Project Resources

Using CloudFormation Resources in Your Serverless Project

The Serverless framework keeps one CloudFormation template in the root of your project by default, labeled `s-resources-cf.json`. To better organize your resources alongside your business logic, you can include more `s-resources-cf.json` files in the root of your project, component, and in the root of a component subfolder. This allows you to specify resources specifically for all of the functions in that subfolder (e.g., custom lambda policies, DynamoDB tables your functions use, etc.). Please note, when a `s-resources-cf.json` file is in a component or subfolder within a component, it can only have the following root properties, which we use to easily merge this file's assets into the `s-resources-cf.json` in your project root: `Resources` and `LambdaIamPolicyStatements`. The Framework comes with commands you can use to automatically deploy your resources, or remove them. When you run `serverless resources deploy`, the following happens: * We dynamically create a new CloudFormation template, starting by copying the `s-resources-cf.json` in the root of your Project. * The `s-resources-cf.json` files in your Components and their subfolders are merged into the dynamic CloudFormation template. * Any Project Templates or Variables in the dynamic CloudFormation template are populated. * The dynamic CloudFormation file is then saved to your Project's `_meta/resources` folder, in the stage and region your are deploying to. If you specified the `noExeCf` option, this command will stop here and not upload the file to CloudFormation. * The staged and region'ed CloudFormation file is then uploaded to CloudFormation and we trigger a Stack Update based off of it. You also have the ability to remove CloudFormation Stacks in Project Stages and Regions via the `serverless resources remove` command. [block:callout] { "type": "warning", "title": "Don't Upload `s-resources-cf.json to AWS", "body": "The `s-resources-cf.json` file is not ready for deployment to AWS because it contains variables that needs to be populated first. You can deploy the CF template files that reside in the `_meta/resources` folder instead, as these are the files that are generated after populating the variables (i.e. stage/region variables). [Click here for more info about templates and variables.](http://docs.serverless.com/v0.4.0/docs/templates-variables)." } [/block]
The Serverless framework keeps one CloudFormation template in the root of your project by default, labeled `s-resources-cf.json`. To better organize your resources alongside your business logic, you can include more `s-resources-cf.json` files in the root of your project, component, and in the root of a component subfolder. This allows you to specify resources specifically for all of the functions in that subfolder (e.g., custom lambda policies, DynamoDB tables your functions use, etc.). Please note, when a `s-resources-cf.json` file is in a component or subfolder within a component, it can only have the following root properties, which we use to easily merge this file's assets into the `s-resources-cf.json` in your project root: `Resources` and `LambdaIamPolicyStatements`. The Framework comes with commands you can use to automatically deploy your resources, or remove them. When you run `serverless resources deploy`, the following happens: * We dynamically create a new CloudFormation template, starting by copying the `s-resources-cf.json` in the root of your Project. * The `s-resources-cf.json` files in your Components and their subfolders are merged into the dynamic CloudFormation template. * Any Project Templates or Variables in the dynamic CloudFormation template are populated. * The dynamic CloudFormation file is then saved to your Project's `_meta/resources` folder, in the stage and region your are deploying to. If you specified the `noExeCf` option, this command will stop here and not upload the file to CloudFormation. * The staged and region'ed CloudFormation file is then uploaded to CloudFormation and we trigger a Stack Update based off of it. You also have the ability to remove CloudFormation Stacks in Project Stages and Regions via the `serverless resources remove` command. [block:callout] { "type": "warning", "title": "Don't Upload `s-resources-cf.json to AWS", "body": "The `s-resources-cf.json` file is not ready for deployment to AWS because it contains variables that needs to be populated first. You can deploy the CF template files that reside in the `_meta/resources` folder instead, as these are the files that are generated after populating the variables (i.e. stage/region variables). [Click here for more info about templates and variables.](http://docs.serverless.com/v0.4.0/docs/templates-variables)." } [/block]
{"_id":"56bacbea4aa5930d00da7802","slug":"application-architectures","sync_unique":"","title":"Project Architectures","api":{"auth":"required","params":[],"results":{"codes":[{"code":"{}","language":"json","status":200,"name":""},{"language":"json","status":400,"name":"","code":"{}"}]},"settings":"","url":""},"hidden":false,"link_external":false,"updates":[],"excerpt":"Determining How to Containerize Your Logic","link_url":"","project":"5611c207f2aeda0d002b3734","type":"basic","version":"56bacbe64aa5930d00da77d8","body":"One of the strengths of the Serverless framework is it gives you the freedom to containerize/isolate your logic any way you'd like. This is possible due to simple nesting of folders: `project/components/subfolder/functions`.  They allow the following architectures and patterns to be available to you in the framework:\n\n###Monolithic \nIf you choose, you can contain all of your logic into a single Lambda function.  Then add multiple endpoints or events to that single Lambda function.  In the Framework, you could do this by creating a `component` that has only one `function`.  When you deploy a function, it containerizes its entire parent component.  So this will work out of the box.\n\nFor example create the following component/function:  `restApi/api`.  Whenever the `api` function is deployed, it will include all logic within the `restApi` component.  You can add as many endpoints or events to the `api` function as you'd like to build out your REST API or event-related service.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Consider Using GraphQL\",\n  \"body\": \"If you're making a REST API, consider using [GraphQL](https://github.com/graphql/graphql-js) in front of your databases to reduce the number of endpoints you need.  GraphQL may make Monolithic approaches viable again.\\n\\nHere's an [example Serverless Blog REST API](https://github.com/serverless/serverless-graphql-blog) that has only one endpoint, powered by GraphQL.\"\n}\n[/block]\n###Microservices \nFramework `components` can contain subfolders to group related functions together. You can think of this subfolder as a `resource` (e.g., `restApi/users`). It's a common pattern to have only a single Lambda function in a `resource`, which can handle all logic for whatever that `resource` is dedicated to.\n\n* `restApi/users/all`\n* `restApi/posts/all`\n* `restApi/comments/all`\n\nFor example, a REST API could have a `users` resource containing one 'all' function that handles all actions for `users`.  Assign endpoints for `create, read, update, delete` to the `all` function.  API Gateway can pass the METHOD and PATH into your function via the `event` object, so you can determine inside your function how to handle/route incoming request.\n\nThe benefit of this approach is agility.  By replicating the same `component` logic across multiple resource-specific lambda functions, you can easily update/iterate these pieces of your application without affecting any other parts of your application.\n\n###Nanoservices \nFor the most agile solution, replicate your `component` logic into Lambda functions for every single endpoint and event you have.\n\nFor example, a REST API could have a `users` subfolder/resource containing multiple functions for `create, read, update, delete`.  \n\n* `restApi/users/create`\n* `restApi/users/read`\n* `restApi/users/update`\n* `restApi/users/delete`\n\nThis way you can update/iterate on each endpoint or event individually, without affecting any other parts of your application.  Like your `restApi/users/create` function. \n\n###Mixing\nYou can always mix the above approaches:\n\n* `restApi/users/all`\n* `restApi/posts/create`\n* `restApi/posts/read`\n* `restApi/posts/updated`\n* `restApi/posts/delete`","createdAt":"2016-01-29T17:54:33.300Z","githubsync":"","user":"5611c1e58c76a61900fd0739","__v":5,"category":"56bc3b9430784e0d001b4a5e","order":2,"metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Project Architectures

Determining How to Containerize Your Logic

One of the strengths of the Serverless framework is it gives you the freedom to containerize/isolate your logic any way you'd like. This is possible due to simple nesting of folders: `project/components/subfolder/functions`. They allow the following architectures and patterns to be available to you in the framework: ###Monolithic If you choose, you can contain all of your logic into a single Lambda function. Then add multiple endpoints or events to that single Lambda function. In the Framework, you could do this by creating a `component` that has only one `function`. When you deploy a function, it containerizes its entire parent component. So this will work out of the box. For example create the following component/function: `restApi/api`. Whenever the `api` function is deployed, it will include all logic within the `restApi` component. You can add as many endpoints or events to the `api` function as you'd like to build out your REST API or event-related service. [block:callout] { "type": "info", "title": "Consider Using GraphQL", "body": "If you're making a REST API, consider using [GraphQL](https://github.com/graphql/graphql-js) in front of your databases to reduce the number of endpoints you need. GraphQL may make Monolithic approaches viable again.\n\nHere's an [example Serverless Blog REST API](https://github.com/serverless/serverless-graphql-blog) that has only one endpoint, powered by GraphQL." } [/block] ###Microservices Framework `components` can contain subfolders to group related functions together. You can think of this subfolder as a `resource` (e.g., `restApi/users`). It's a common pattern to have only a single Lambda function in a `resource`, which can handle all logic for whatever that `resource` is dedicated to. * `restApi/users/all` * `restApi/posts/all` * `restApi/comments/all` For example, a REST API could have a `users` resource containing one 'all' function that handles all actions for `users`. Assign endpoints for `create, read, update, delete` to the `all` function. API Gateway can pass the METHOD and PATH into your function via the `event` object, so you can determine inside your function how to handle/route incoming request. The benefit of this approach is agility. By replicating the same `component` logic across multiple resource-specific lambda functions, you can easily update/iterate these pieces of your application without affecting any other parts of your application. ###Nanoservices For the most agile solution, replicate your `component` logic into Lambda functions for every single endpoint and event you have. For example, a REST API could have a `users` subfolder/resource containing multiple functions for `create, read, update, delete`. * `restApi/users/create` * `restApi/users/read` * `restApi/users/update` * `restApi/users/delete` This way you can update/iterate on each endpoint or event individually, without affecting any other parts of your application. Like your `restApi/users/create` function. ###Mixing You can always mix the above approaches: * `restApi/users/all` * `restApi/posts/create` * `restApi/posts/read` * `restApi/posts/updated` * `restApi/posts/delete`
One of the strengths of the Serverless framework is it gives you the freedom to containerize/isolate your logic any way you'd like. This is possible due to simple nesting of folders: `project/components/subfolder/functions`. They allow the following architectures and patterns to be available to you in the framework: ###Monolithic If you choose, you can contain all of your logic into a single Lambda function. Then add multiple endpoints or events to that single Lambda function. In the Framework, you could do this by creating a `component` that has only one `function`. When you deploy a function, it containerizes its entire parent component. So this will work out of the box. For example create the following component/function: `restApi/api`. Whenever the `api` function is deployed, it will include all logic within the `restApi` component. You can add as many endpoints or events to the `api` function as you'd like to build out your REST API or event-related service. [block:callout] { "type": "info", "title": "Consider Using GraphQL", "body": "If you're making a REST API, consider using [GraphQL](https://github.com/graphql/graphql-js) in front of your databases to reduce the number of endpoints you need. GraphQL may make Monolithic approaches viable again.\n\nHere's an [example Serverless Blog REST API](https://github.com/serverless/serverless-graphql-blog) that has only one endpoint, powered by GraphQL." } [/block] ###Microservices Framework `components` can contain subfolders to group related functions together. You can think of this subfolder as a `resource` (e.g., `restApi/users`). It's a common pattern to have only a single Lambda function in a `resource`, which can handle all logic for whatever that `resource` is dedicated to. * `restApi/users/all` * `restApi/posts/all` * `restApi/comments/all` For example, a REST API could have a `users` resource containing one 'all' function that handles all actions for `users`. Assign endpoints for `create, read, update, delete` to the `all` function. API Gateway can pass the METHOD and PATH into your function via the `event` object, so you can determine inside your function how to handle/route incoming request. The benefit of this approach is agility. By replicating the same `component` logic across multiple resource-specific lambda functions, you can easily update/iterate these pieces of your application without affecting any other parts of your application. ###Nanoservices For the most agile solution, replicate your `component` logic into Lambda functions for every single endpoint and event you have. For example, a REST API could have a `users` subfolder/resource containing multiple functions for `create, read, update, delete`. * `restApi/users/create` * `restApi/users/read` * `restApi/users/update` * `restApi/users/delete` This way you can update/iterate on each endpoint or event individually, without affecting any other parts of your application. Like your `restApi/users/create` function. ###Mixing You can always mix the above approaches: * `restApi/users/all` * `restApi/posts/create` * `restApi/posts/read` * `restApi/posts/updated` * `restApi/posts/delete`
{"_id":"56bacbea4aa5930d00da7803","user":"562120887c515c0d008eee9b","category":"56bc3b9430784e0d001b4a5e","slug":"templates-variables","api":{"auth":"required","params":[],"results":{"codes":[{"name":"","code":"{}","language":"json","status":200},{"name":"","code":"{}","language":"json","status":400}]},"settings":"","url":""},"createdAt":"2016-01-13T20:08:09.084Z","link_external":false,"order":3,"updates":["56a07f4c4583912300b5f01b","56a0e554470ae00d00c30573","56c26286ddcb5119004cab70","56c3b4d434df460d00c2bea6","56cf3235336aa60b0086a1fb","56da86353dede50b00eacb3c"],"version":"56bacbe64aa5930d00da77d8","__v":11,"hidden":false,"sync_unique":"","title":"Templates & Variables","type":"basic","excerpt":"Templates offer reusable configuration syntax, Variables offer dynamic configuration values","githubsync":"","project":"5611c207f2aeda0d002b3734","body":"Serverless Projects use configuration files written in JSON which can get big, and they sometimes need to include dynamic values that change for stages and regions (ie. ARNs).  \n\nTo reduce redundancy in the config files, we created Project Templates.  To allow for dynamic values in the config files, we created Project Variables.\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"Templates & Variables are for Configuration Only\",\n  \"body\": \"Templates and variables are used for configuration of the project only. This information is not usable in your lambda functions. To set variables which can be used by your lambda functions, use [environment variables](http://docs.serverless.com/docs/env-set).\"\n}\n[/block]\n## Templates\nTemplates are variables containing objects, arrays or strings.  These dramatically reduce redundancy in your configuration files, since you can use the same template in multiple places.\n\nHere is an example of a template:\n```\n{\n  \"apiGatewayRequestTemplate\": {\n    \"application/json\": {\n      \"body\": \"$input.json('$')\",\n      \"pathParams\" : \"$input.params().path\",\n      \"queryParams\" : \"$input.params().querystring\"\n    }\n  }\n}\n```\n\nYou can add specify templates in your `s-project.json, s-component.json, s-module.json, s-function.json` configuration files by enclosing them in `$${}`, like this:\n```\n\"requestTemplates\": \"$${apiGatewayRequestTemplate}\"\n```\n\nTo define templates in your project, add them to `s-templates.json` files to the root of your Project, Component, Function folders. \n\n```\nproject\n|_ s-templates.json\n    component\n    |_ s-templates.json\n        function\n        |_ s-templates.json\n```\nYou can add them wherever you think is best.  The reason you can add template files in multiple folders is because templates defined in parent folders can be extended by templates defined in subfolders.\n\nLet's put the examples above together.  Say we have two template files that extend the template  \"apiGatewayRequestTemplate\": \n\n```\n// project/s-templates.json\n\n{\n  \"apiGatewayRequestTemplate\": {\n    \"application/json\": {\n      \"body\": \"$input.json('$')\",\n      \"pathParams\" : \"$input.params().path\",\n      \"queryParams\" : \"$input.params().querystring\"\n    }\n  }\n}\n\n// project/component/function/s-templates.json\n\n{\n  \"apiGatewayRequestTemplate\": {\n    \"application/json\": {\n      \"pathId\": \"$input.params('id')\"\n    }\n  }\n}\n```\nThis template is used for an endpoint's API Gateway Request Template.  In a Serverless project, this information is specified in the `s-function.json` containing the endpoint, like this:\n\n```\n{\n  \"name\": \"show\",\n  \"handler\": \"multi/show/handler.handler\",\n  \"runtime\": \"nodejs\",\n  \"timeout\": 6,\n  \"memorySize\": 256,\n  \"custom\": {},\n  \"endpoints\": [\n    {\n      \"path\": \"users/show/{id}\",\n      \"method\": \"GET\",\n      \"authorizationType\": \"none\",\n      \"apiKeyRequired\": false,\n      \"requestParameters\": {},\n      \"requestTemplates\": \"$${apiGatewayRequestTemplate}\",\n      \"responses\": {}\n    }\n  ]\n}\n```\nThe `apiGatewayRequestTemplate` template in the endpoint syntax above would be populated with the combination of both of the above templates.\n\nAlso, you can extend a template in a parent folder by templates in multiple subfolders at the same time.  Each subfolders will get an aggregated template that contains unique values, depending on what values they extended the parent template with. \n\nLastly, you can put templates in your `s-resources-cf.json` file as well.  Project Variables (described below) can also be included in templates.  The Framework first populates all templates, then populates all variables.\n\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Templates For Function Names\",\n  \"body\": \"Create custom Function Name Templates by putting a `\\\"functionName\\\": \\\"${project}-${stage}-${name}\\\"` key in `s-templates.json` in the root of your project.  `${name}` is a reserved Project Variable and is always populated with the name property in the current configuration file.  Then in `s-function.json`, put this: `\\\"customName\\\": \\\"$${functionName}\\\"`\"\n}\n[/block]\n## Variables\nVariables hold strings or integers.  They enable you to add dynamic values to your configuration files that change with each project stage and region.  This is great for AWS Account specific data that changes across your stages and regions, like ARNs.  \n\nAll of your variables are defined inside the `_meta/variables` folder (the `_meta` folder is gitgnored by default). Inside this variables folder you'll find a JSON file for each stage and each region for that stage.\n\nHere's an example of defining a new variable in the `us-east-1` region in the `dev` stage. If you open the `s-variables-dev-useast1.json` file, you'll find the following default variables which are used by our framework:\n```\n{\n  \"region\": \"us-east-1\",\n  \"resourcesStackName\": \"projectName-dev-r\",\n  \"iamRoleArnLambda\": \"arn:aws:iam::AWSaccount:role/projectName-dev-r-IamRoleLambda-someRole\"\n}\n```\nAs you can see, these values are specific to your project and your AWS account.\n\nYou can now reference this variable in any of your project's configuration files by enclosing it in `${}` (just like with templates, but with a single $ sign). For example, here is a variable being used in the CloudFormation syntax in your `s-project.json` file:\n```\n\"IamPolicyLambda\": {\n        \"Type\": \"AWS::IAM::Policy\",\n        \"Properties\": {\n          \"PolicyName\": \"${region}-lambda\",\n```\n\nYou can use also use variables in `s-template.json` files.  The framework first populates all templates, then populates all variables.\n\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Templates & Variables in CloudFormation Syntax\",\n  \"body\": \"CloudFormation syntax in your configuration files can also contain templates and variables.  CloudFormation syntax will always be populated with template and variable values before any CloudFormation operations are performed.\"\n}\n[/block]","link_url":"","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Templates & Variables

Templates offer reusable configuration syntax, Variables offer dynamic configuration values

Serverless Projects use configuration files written in JSON which can get big, and they sometimes need to include dynamic values that change for stages and regions (ie. ARNs). To reduce redundancy in the config files, we created Project Templates. To allow for dynamic values in the config files, we created Project Variables. [block:callout] { "type": "warning", "title": "Templates & Variables are for Configuration Only", "body": "Templates and variables are used for configuration of the project only. This information is not usable in your lambda functions. To set variables which can be used by your lambda functions, use [environment variables](http://docs.serverless.com/docs/env-set)." } [/block] ## Templates Templates are variables containing objects, arrays or strings. These dramatically reduce redundancy in your configuration files, since you can use the same template in multiple places. Here is an example of a template: ``` { "apiGatewayRequestTemplate": { "application/json": { "body": "$input.json('$')", "pathParams" : "$input.params().path", "queryParams" : "$input.params().querystring" } } } ``` You can add specify templates in your `s-project.json, s-component.json, s-module.json, s-function.json` configuration files by enclosing them in `$${}`, like this: ``` "requestTemplates": "$${apiGatewayRequestTemplate}" ``` To define templates in your project, add them to `s-templates.json` files to the root of your Project, Component, Function folders. ``` project |_ s-templates.json component |_ s-templates.json function |_ s-templates.json ``` You can add them wherever you think is best. The reason you can add template files in multiple folders is because templates defined in parent folders can be extended by templates defined in subfolders. Let's put the examples above together. Say we have two template files that extend the template "apiGatewayRequestTemplate": ``` // project/s-templates.json { "apiGatewayRequestTemplate": { "application/json": { "body": "$input.json('$')", "pathParams" : "$input.params().path", "queryParams" : "$input.params().querystring" } } } // project/component/function/s-templates.json { "apiGatewayRequestTemplate": { "application/json": { "pathId": "$input.params('id')" } } } ``` This template is used for an endpoint's API Gateway Request Template. In a Serverless project, this information is specified in the `s-function.json` containing the endpoint, like this: ``` { "name": "show", "handler": "multi/show/handler.handler", "runtime": "nodejs", "timeout": 6, "memorySize": 256, "custom": {}, "endpoints": [ { "path": "users/show/{id}", "method": "GET", "authorizationType": "none", "apiKeyRequired": false, "requestParameters": {}, "requestTemplates": "$${apiGatewayRequestTemplate}", "responses": {} } ] } ``` The `apiGatewayRequestTemplate` template in the endpoint syntax above would be populated with the combination of both of the above templates. Also, you can extend a template in a parent folder by templates in multiple subfolders at the same time. Each subfolders will get an aggregated template that contains unique values, depending on what values they extended the parent template with. Lastly, you can put templates in your `s-resources-cf.json` file as well. Project Variables (described below) can also be included in templates. The Framework first populates all templates, then populates all variables. [block:callout] { "type": "info", "title": "Templates For Function Names", "body": "Create custom Function Name Templates by putting a `\"functionName\": \"${project}-${stage}-${name}\"` key in `s-templates.json` in the root of your project. `${name}` is a reserved Project Variable and is always populated with the name property in the current configuration file. Then in `s-function.json`, put this: `\"customName\": \"$${functionName}\"`" } [/block] ## Variables Variables hold strings or integers. They enable you to add dynamic values to your configuration files that change with each project stage and region. This is great for AWS Account specific data that changes across your stages and regions, like ARNs. All of your variables are defined inside the `_meta/variables` folder (the `_meta` folder is gitgnored by default). Inside this variables folder you'll find a JSON file for each stage and each region for that stage. Here's an example of defining a new variable in the `us-east-1` region in the `dev` stage. If you open the `s-variables-dev-useast1.json` file, you'll find the following default variables which are used by our framework: ``` { "region": "us-east-1", "resourcesStackName": "projectName-dev-r", "iamRoleArnLambda": "arn:aws:iam::AWSaccount:role/projectName-dev-r-IamRoleLambda-someRole" } ``` As you can see, these values are specific to your project and your AWS account. You can now reference this variable in any of your project's configuration files by enclosing it in `${}` (just like with templates, but with a single $ sign). For example, here is a variable being used in the CloudFormation syntax in your `s-project.json` file: ``` "IamPolicyLambda": { "Type": "AWS::IAM::Policy", "Properties": { "PolicyName": "${region}-lambda", ``` You can use also use variables in `s-template.json` files. The framework first populates all templates, then populates all variables. [block:callout] { "type": "info", "title": "Templates & Variables in CloudFormation Syntax", "body": "CloudFormation syntax in your configuration files can also contain templates and variables. CloudFormation syntax will always be populated with template and variable values before any CloudFormation operations are performed." } [/block]
Serverless Projects use configuration files written in JSON which can get big, and they sometimes need to include dynamic values that change for stages and regions (ie. ARNs). To reduce redundancy in the config files, we created Project Templates. To allow for dynamic values in the config files, we created Project Variables. [block:callout] { "type": "warning", "title": "Templates & Variables are for Configuration Only", "body": "Templates and variables are used for configuration of the project only. This information is not usable in your lambda functions. To set variables which can be used by your lambda functions, use [environment variables](http://docs.serverless.com/docs/env-set)." } [/block] ## Templates Templates are variables containing objects, arrays or strings. These dramatically reduce redundancy in your configuration files, since you can use the same template in multiple places. Here is an example of a template: ``` { "apiGatewayRequestTemplate": { "application/json": { "body": "$input.json('$')", "pathParams" : "$input.params().path", "queryParams" : "$input.params().querystring" } } } ``` You can add specify templates in your `s-project.json, s-component.json, s-module.json, s-function.json` configuration files by enclosing them in `$${}`, like this: ``` "requestTemplates": "$${apiGatewayRequestTemplate}" ``` To define templates in your project, add them to `s-templates.json` files to the root of your Project, Component, Function folders. ``` project |_ s-templates.json component |_ s-templates.json function |_ s-templates.json ``` You can add them wherever you think is best. The reason you can add template files in multiple folders is because templates defined in parent folders can be extended by templates defined in subfolders. Let's put the examples above together. Say we have two template files that extend the template "apiGatewayRequestTemplate": ``` // project/s-templates.json { "apiGatewayRequestTemplate": { "application/json": { "body": "$input.json('$')", "pathParams" : "$input.params().path", "queryParams" : "$input.params().querystring" } } } // project/component/function/s-templates.json { "apiGatewayRequestTemplate": { "application/json": { "pathId": "$input.params('id')" } } } ``` This template is used for an endpoint's API Gateway Request Template. In a Serverless project, this information is specified in the `s-function.json` containing the endpoint, like this: ``` { "name": "show", "handler": "multi/show/handler.handler", "runtime": "nodejs", "timeout": 6, "memorySize": 256, "custom": {}, "endpoints": [ { "path": "users/show/{id}", "method": "GET", "authorizationType": "none", "apiKeyRequired": false, "requestParameters": {}, "requestTemplates": "$${apiGatewayRequestTemplate}", "responses": {} } ] } ``` The `apiGatewayRequestTemplate` template in the endpoint syntax above would be populated with the combination of both of the above templates. Also, you can extend a template in a parent folder by templates in multiple subfolders at the same time. Each subfolders will get an aggregated template that contains unique values, depending on what values they extended the parent template with. Lastly, you can put templates in your `s-resources-cf.json` file as well. Project Variables (described below) can also be included in templates. The Framework first populates all templates, then populates all variables. [block:callout] { "type": "info", "title": "Templates For Function Names", "body": "Create custom Function Name Templates by putting a `\"functionName\": \"${project}-${stage}-${name}\"` key in `s-templates.json` in the root of your project. `${name}` is a reserved Project Variable and is always populated with the name property in the current configuration file. Then in `s-function.json`, put this: `\"customName\": \"$${functionName}\"`" } [/block] ## Variables Variables hold strings or integers. They enable you to add dynamic values to your configuration files that change with each project stage and region. This is great for AWS Account specific data that changes across your stages and regions, like ARNs. All of your variables are defined inside the `_meta/variables` folder (the `_meta` folder is gitgnored by default). Inside this variables folder you'll find a JSON file for each stage and each region for that stage. Here's an example of defining a new variable in the `us-east-1` region in the `dev` stage. If you open the `s-variables-dev-useast1.json` file, you'll find the following default variables which are used by our framework: ``` { "region": "us-east-1", "resourcesStackName": "projectName-dev-r", "iamRoleArnLambda": "arn:aws:iam::AWSaccount:role/projectName-dev-r-IamRoleLambda-someRole" } ``` As you can see, these values are specific to your project and your AWS account. You can now reference this variable in any of your project's configuration files by enclosing it in `${}` (just like with templates, but with a single $ sign). For example, here is a variable being used in the CloudFormation syntax in your `s-project.json` file: ``` "IamPolicyLambda": { "Type": "AWS::IAM::Policy", "Properties": { "PolicyName": "${region}-lambda", ``` You can use also use variables in `s-template.json` files. The framework first populates all templates, then populates all variables. [block:callout] { "type": "info", "title": "Templates & Variables in CloudFormation Syntax", "body": "CloudFormation syntax in your configuration files can also contain templates and variables. CloudFormation syntax will always be populated with template and variable values before any CloudFormation operations are performed." } [/block]
{"_id":"56bc3c4d09764a0d001a039e","__v":17,"link_url":"","category":"56bc3b9430784e0d001b4a5e","createdAt":"2016-02-11T07:46:21.909Z","excerpt":"All you need to know about configuring your functions, endpoints and event sources.","slug":"function-configuration","updates":["56be017dba9df50d00a7a1bc","56bfba3bff5b440d0053edb4","56bfffab8e032e170076dd2a","56c0f27cd344e517000207ff","56eed0e4a5bcfd0e0095172c"],"version":"56bacbe64aa5930d00da77d8","body":"[block:callout]\n{\n  \"type\": \"warning\",\n  \"body\": \"The `s-function.json` file is just a reflection of AWS configurations. If some of the Function and Endpoint configurations feel alien to you, you need to familiarize yourself with [AWS Lambda docs (including event sources)](http://docs.aws.amazon.com/lambda/latest/dg/welcome.html) and [API Gateway docs](https://aws.amazon.com/api-gateway/).\",\n  \"title\": \"AWS Docs\"\n}\n[/block]\nServerless Functions is the core of your project. All function configurations are in the `s-function.json` file, and it's the most complex Serverless JSON file. This file contains configuration for your Function, its Endpoints and Event Sources. Here's an example `s-function.json`:\n\n```\n{\n  \"name\": \"function1\",\n  \"description\": \"My first lambda function in project ${project} in stage ${stage}\",\n  \"customName\": false,\n  \"customRole\": false,\n  \"handler\": \"function1/handler.handler\",\n  \"timeout\": 6,\n  \"memorySize\": 1024,\n  \"custom\": {\n    \"excludePatterns\": [],\n    \"envVars\": []\n  },\n  \"endpoints\": [\n    {\n      \"path\": \"fun\",\n      \"method\": \"GET\",\n      \"type\": \"AWS\",\n      \"authorizationType\": \"none\",\n      \"apiKeyRequired\": false,\n      \"requestParameters\": {},\n      \"requestTemplates\": {\n        \"application/json\": \"\"\n      },\n      \"responses\": {\n        \"400\": {\n          \"statusCode\": \"400\"\n        },\n        \"default\": {\n          \"statusCode\": \"200\",\n          \"responseParameters\": {},\n          \"responseModels\": {},\n          \"responseTemplates\": {\n            \"application/json\": \"\"\n          }\n        }\n      }\n    }\n  ],\n  \"events\": [\n    {\n      \"name\" : \"myEventSource\",\n      \"type\": \"schedule\",\n      \"config\": {\n         \"schedule\": \"rate(5 minutes)\"\n      }\n    }\n], \n}\n```\n\nThe `s-function.json` file properties can be divided into three categories: **Function**, **Endpoint** and **Event** configurations.\n\n## Function Configurations\n* **name**: the name of this function. This obviously matches the name of the function folder.\n* **customName**: the name of the lambda function. It's set to `false` by default. This means that you don't want to set a custom name for your lambda, and instead we'll name the lambda for you using a combination of project, component and function names.\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"name vs. customName\",\n  \"body\": \"The `name` property is the function name within the context of your Serverless Project, while the `customName` property is the **actual lambda name that is deployed to AWS**. If you don't set a `customName`, we'll generate a lambda name for you that is just a combination of the project, component and function names.\"\n}\n[/block]\n* **customRole**: you can set a custom IAM role ARN in this property to override the default project IAM role. It's set to false by default.\n* **handler**: The path to the lambda `handler.js` file relative to the function folder. This property gives you flexibility to change your handler file.\n* **timeout**: the maximum running time allowed for your lambda function. Default is 6 seconds. Maximum allowed timeout by AWS is 300 seconds.\n* **memorySize**: the memory size of your lambda function. Default is 1024MB, but you can set it up to 1.5GB. This is a limit set by AWS lambda.\n* **custom**: this property allows plugin authors to add more function configurations for their plugins. It has two default properties: \n    * **excludePatterns**: this is where you set whatever you want to exclude during function deployment.\n    * **envVars**: a list of all the environment variables that this function needs. It's useful to list the env vars here so that when you run `sls env list` you'll be notified of which env vars are needed by each function.\n\n## Endpoint Configurations \nEach function (`s-function.json`) can have multiple endpoints. They are all defined in the `endpoints` property. It's an  array that contains multiple Endpoint objects. Each of which have the following configurations:\n\n* **path**: The path of the endpoint. This value gets added to the stage and AWS host to construct the full endpoint url (i.e. `https://fpq68h492f.execute-api.us-east-1.amazonaws.com/development/group1/endpoint-path1`)\n* **method**: The HTTP method for this endpoint. Set to `GET` by default.\n* **authorizationType**: The type of authorization for your endpoint. Default is `none`.\n* **apiKeyRequired**: Whether or not an API Key is required for your endpoint. Default is `false`.\n* **requestParameters**: Sets the AWS request parameters for your endpoint.\n* **requestTemplates**: Sets the AWS request templates for your endpoint.\n* **responses**: Sets the AWS responses parameters and templates.\n\n## Event Sources Configurations \nEach function (`s-function.json`) can have multiple event sources. They are all defined in the `events` property. It's an array that contains multiple Event objects. Each of which have the following configurations:\n\n* **name**: a name for your event source that is unique within your function. We use this name to reference the event source and construct the event source `sPath`.\n* **type**: the type of your event source. We currently support 5 event sources: `dynamodbstream`, `kinesisstream`, `s3`, `sns`, and `schedule`.\n* **config**: configuration object for your event source. The properties of this object depends on the event source `type`. Below are examples for each event source types and their configurations.\n\n### Event Sources Examples\n**DynamoDB Stream**\n```\n\"name\" : \"myDynamoDbTable\",\n\"type\": \"dynamodbstream\",\n\"config\": {\n    \"streamArn\": \"${streamArnVariable}\", (required!)\n    \"startingPosition\": \"LATEST\", (default is \"TRIM_HORIZON\" if not provided)\n    \"batchSize\": 50, (default is 100 if not provided)\n    \"enabled\": false (default is true if not provided) \n}\n```\n**Kinesis Stream**\n```\n\"name\" : \"myKinesisStream\",\n\"type\": \"kinesisstream\",\n\"config\": {\n    \"streamArn\": \"${streamArnVariable}\", (required!)\n    \"startingPosition\": \"LATEST\", (default is \"TRIM_HORIZON\" if not provided)\n    \"batchSize\": 50, (default is 100 if not provided)\n    \"enabled\": false (default is true if not provided) \n}\n```\n**S3**\n```\n\"name\" : \"myS3Event\",\n\"type\": \"s3\",\n\"config\": {\n    \"bucket\": \"${testEventBucket}\", (required! - bucket name)\n    \"bucketEvents\": [\"s3:ObjectCreated:*\"] (required! - an array of events that should trigger the lambda)\n}\n```\n**SNS**\n```\n\"name\" : \"mySNSEvent\",\n\"type\": \"sns\",\n\"config\": {\n     \"topicName\": \"test-event-source\" (required! - the topic name you want your lambda to subscribe to)\n}\n```\n**Schedule**\n```\n\"name\" : \"mySchedule\",\n\"type\": \"schedule\",\n\"config\": {\n    \"schedule\": \"rate(5 minutes)\", (required! - could also take a cron expression: \"cron(0 20 * * ? *)\")\n    \"enabled\": true (default is false if not provided)\n}\n```\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Real World Examples\",\n  \"body\": \"If you'd like to see a real world working example of `s-function.json` with event sources, [check out this test function](https://github.com/serverless/serverless/blob/master/tests/test-prj/nodejscomponent/group1/function1/s-function.json#L10-L40).\"\n}\n[/block]","order":4,"sync_unique":"","user":"562120887c515c0d008eee9b","type":"basic","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"githubsync":"","hidden":false,"isReference":false,"link_external":false,"project":"5611c207f2aeda0d002b3734","title":"Function Configuration","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Function Configuration

All you need to know about configuring your functions, endpoints and event sources.

[block:callout] { "type": "warning", "body": "The `s-function.json` file is just a reflection of AWS configurations. If some of the Function and Endpoint configurations feel alien to you, you need to familiarize yourself with [AWS Lambda docs (including event sources)](http://docs.aws.amazon.com/lambda/latest/dg/welcome.html) and [API Gateway docs](https://aws.amazon.com/api-gateway/).", "title": "AWS Docs" } [/block] Serverless Functions is the core of your project. All function configurations are in the `s-function.json` file, and it's the most complex Serverless JSON file. This file contains configuration for your Function, its Endpoints and Event Sources. Here's an example `s-function.json`: ``` { "name": "function1", "description": "My first lambda function in project ${project} in stage ${stage}", "customName": false, "customRole": false, "handler": "function1/handler.handler", "timeout": 6, "memorySize": 1024, "custom": { "excludePatterns": [], "envVars": [] }, "endpoints": [ { "path": "fun", "method": "GET", "type": "AWS", "authorizationType": "none", "apiKeyRequired": false, "requestParameters": {}, "requestTemplates": { "application/json": "" }, "responses": { "400": { "statusCode": "400" }, "default": { "statusCode": "200", "responseParameters": {}, "responseModels": {}, "responseTemplates": { "application/json": "" } } } } ], "events": [ { "name" : "myEventSource", "type": "schedule", "config": { "schedule": "rate(5 minutes)" } } ], } ``` The `s-function.json` file properties can be divided into three categories: **Function**, **Endpoint** and **Event** configurations. ## Function Configurations * **name**: the name of this function. This obviously matches the name of the function folder. * **customName**: the name of the lambda function. It's set to `false` by default. This means that you don't want to set a custom name for your lambda, and instead we'll name the lambda for you using a combination of project, component and function names. [block:callout] { "type": "warning", "title": "name vs. customName", "body": "The `name` property is the function name within the context of your Serverless Project, while the `customName` property is the **actual lambda name that is deployed to AWS**. If you don't set a `customName`, we'll generate a lambda name for you that is just a combination of the project, component and function names." } [/block] * **customRole**: you can set a custom IAM role ARN in this property to override the default project IAM role. It's set to false by default. * **handler**: The path to the lambda `handler.js` file relative to the function folder. This property gives you flexibility to change your handler file. * **timeout**: the maximum running time allowed for your lambda function. Default is 6 seconds. Maximum allowed timeout by AWS is 300 seconds. * **memorySize**: the memory size of your lambda function. Default is 1024MB, but you can set it up to 1.5GB. This is a limit set by AWS lambda. * **custom**: this property allows plugin authors to add more function configurations for their plugins. It has two default properties: * **excludePatterns**: this is where you set whatever you want to exclude during function deployment. * **envVars**: a list of all the environment variables that this function needs. It's useful to list the env vars here so that when you run `sls env list` you'll be notified of which env vars are needed by each function. ## Endpoint Configurations Each function (`s-function.json`) can have multiple endpoints. They are all defined in the `endpoints` property. It's an array that contains multiple Endpoint objects. Each of which have the following configurations: * **path**: The path of the endpoint. This value gets added to the stage and AWS host to construct the full endpoint url (i.e. `https://fpq68h492f.execute-api.us-east-1.amazonaws.com/development/group1/endpoint-path1`) * **method**: The HTTP method for this endpoint. Set to `GET` by default. * **authorizationType**: The type of authorization for your endpoint. Default is `none`. * **apiKeyRequired**: Whether or not an API Key is required for your endpoint. Default is `false`. * **requestParameters**: Sets the AWS request parameters for your endpoint. * **requestTemplates**: Sets the AWS request templates for your endpoint. * **responses**: Sets the AWS responses parameters and templates. ## Event Sources Configurations Each function (`s-function.json`) can have multiple event sources. They are all defined in the `events` property. It's an array that contains multiple Event objects. Each of which have the following configurations: * **name**: a name for your event source that is unique within your function. We use this name to reference the event source and construct the event source `sPath`. * **type**: the type of your event source. We currently support 5 event sources: `dynamodbstream`, `kinesisstream`, `s3`, `sns`, and `schedule`. * **config**: configuration object for your event source. The properties of this object depends on the event source `type`. Below are examples for each event source types and their configurations. ### Event Sources Examples **DynamoDB Stream** ``` "name" : "myDynamoDbTable", "type": "dynamodbstream", "config": { "streamArn": "${streamArnVariable}", (required!) "startingPosition": "LATEST", (default is "TRIM_HORIZON" if not provided) "batchSize": 50, (default is 100 if not provided) "enabled": false (default is true if not provided) } ``` **Kinesis Stream** ``` "name" : "myKinesisStream", "type": "kinesisstream", "config": { "streamArn": "${streamArnVariable}", (required!) "startingPosition": "LATEST", (default is "TRIM_HORIZON" if not provided) "batchSize": 50, (default is 100 if not provided) "enabled": false (default is true if not provided) } ``` **S3** ``` "name" : "myS3Event", "type": "s3", "config": { "bucket": "${testEventBucket}", (required! - bucket name) "bucketEvents": ["s3:ObjectCreated:*"] (required! - an array of events that should trigger the lambda) } ``` **SNS** ``` "name" : "mySNSEvent", "type": "sns", "config": { "topicName": "test-event-source" (required! - the topic name you want your lambda to subscribe to) } ``` **Schedule** ``` "name" : "mySchedule", "type": "schedule", "config": { "schedule": "rate(5 minutes)", (required! - could also take a cron expression: "cron(0 20 * * ? *)") "enabled": true (default is false if not provided) } ``` [block:callout] { "type": "info", "title": "Real World Examples", "body": "If you'd like to see a real world working example of `s-function.json` with event sources, [check out this test function](https://github.com/serverless/serverless/blob/master/tests/test-prj/nodejscomponent/group1/function1/s-function.json#L10-L40)." } [/block]
[block:callout] { "type": "warning", "body": "The `s-function.json` file is just a reflection of AWS configurations. If some of the Function and Endpoint configurations feel alien to you, you need to familiarize yourself with [AWS Lambda docs (including event sources)](http://docs.aws.amazon.com/lambda/latest/dg/welcome.html) and [API Gateway docs](https://aws.amazon.com/api-gateway/).", "title": "AWS Docs" } [/block] Serverless Functions is the core of your project. All function configurations are in the `s-function.json` file, and it's the most complex Serverless JSON file. This file contains configuration for your Function, its Endpoints and Event Sources. Here's an example `s-function.json`: ``` { "name": "function1", "description": "My first lambda function in project ${project} in stage ${stage}", "customName": false, "customRole": false, "handler": "function1/handler.handler", "timeout": 6, "memorySize": 1024, "custom": { "excludePatterns": [], "envVars": [] }, "endpoints": [ { "path": "fun", "method": "GET", "type": "AWS", "authorizationType": "none", "apiKeyRequired": false, "requestParameters": {}, "requestTemplates": { "application/json": "" }, "responses": { "400": { "statusCode": "400" }, "default": { "statusCode": "200", "responseParameters": {}, "responseModels": {}, "responseTemplates": { "application/json": "" } } } } ], "events": [ { "name" : "myEventSource", "type": "schedule", "config": { "schedule": "rate(5 minutes)" } } ], } ``` The `s-function.json` file properties can be divided into three categories: **Function**, **Endpoint** and **Event** configurations. ## Function Configurations * **name**: the name of this function. This obviously matches the name of the function folder. * **customName**: the name of the lambda function. It's set to `false` by default. This means that you don't want to set a custom name for your lambda, and instead we'll name the lambda for you using a combination of project, component and function names. [block:callout] { "type": "warning", "title": "name vs. customName", "body": "The `name` property is the function name within the context of your Serverless Project, while the `customName` property is the **actual lambda name that is deployed to AWS**. If you don't set a `customName`, we'll generate a lambda name for you that is just a combination of the project, component and function names." } [/block] * **customRole**: you can set a custom IAM role ARN in this property to override the default project IAM role. It's set to false by default. * **handler**: The path to the lambda `handler.js` file relative to the function folder. This property gives you flexibility to change your handler file. * **timeout**: the maximum running time allowed for your lambda function. Default is 6 seconds. Maximum allowed timeout by AWS is 300 seconds. * **memorySize**: the memory size of your lambda function. Default is 1024MB, but you can set it up to 1.5GB. This is a limit set by AWS lambda. * **custom**: this property allows plugin authors to add more function configurations for their plugins. It has two default properties: * **excludePatterns**: this is where you set whatever you want to exclude during function deployment. * **envVars**: a list of all the environment variables that this function needs. It's useful to list the env vars here so that when you run `sls env list` you'll be notified of which env vars are needed by each function. ## Endpoint Configurations Each function (`s-function.json`) can have multiple endpoints. They are all defined in the `endpoints` property. It's an array that contains multiple Endpoint objects. Each of which have the following configurations: * **path**: The path of the endpoint. This value gets added to the stage and AWS host to construct the full endpoint url (i.e. `https://fpq68h492f.execute-api.us-east-1.amazonaws.com/development/group1/endpoint-path1`) * **method**: The HTTP method for this endpoint. Set to `GET` by default. * **authorizationType**: The type of authorization for your endpoint. Default is `none`. * **apiKeyRequired**: Whether or not an API Key is required for your endpoint. Default is `false`. * **requestParameters**: Sets the AWS request parameters for your endpoint. * **requestTemplates**: Sets the AWS request templates for your endpoint. * **responses**: Sets the AWS responses parameters and templates. ## Event Sources Configurations Each function (`s-function.json`) can have multiple event sources. They are all defined in the `events` property. It's an array that contains multiple Event objects. Each of which have the following configurations: * **name**: a name for your event source that is unique within your function. We use this name to reference the event source and construct the event source `sPath`. * **type**: the type of your event source. We currently support 5 event sources: `dynamodbstream`, `kinesisstream`, `s3`, `sns`, and `schedule`. * **config**: configuration object for your event source. The properties of this object depends on the event source `type`. Below are examples for each event source types and their configurations. ### Event Sources Examples **DynamoDB Stream** ``` "name" : "myDynamoDbTable", "type": "dynamodbstream", "config": { "streamArn": "${streamArnVariable}", (required!) "startingPosition": "LATEST", (default is "TRIM_HORIZON" if not provided) "batchSize": 50, (default is 100 if not provided) "enabled": false (default is true if not provided) } ``` **Kinesis Stream** ``` "name" : "myKinesisStream", "type": "kinesisstream", "config": { "streamArn": "${streamArnVariable}", (required!) "startingPosition": "LATEST", (default is "TRIM_HORIZON" if not provided) "batchSize": 50, (default is 100 if not provided) "enabled": false (default is true if not provided) } ``` **S3** ``` "name" : "myS3Event", "type": "s3", "config": { "bucket": "${testEventBucket}", (required! - bucket name) "bucketEvents": ["s3:ObjectCreated:*"] (required! - an array of events that should trigger the lambda) } ``` **SNS** ``` "name" : "mySNSEvent", "type": "sns", "config": { "topicName": "test-event-source" (required! - the topic name you want your lambda to subscribe to) } ``` **Schedule** ``` "name" : "mySchedule", "type": "schedule", "config": { "schedule": "rate(5 minutes)", (required! - could also take a cron expression: "cron(0 20 * * ? *)") "enabled": true (default is false if not provided) } ``` [block:callout] { "type": "info", "title": "Real World Examples", "body": "If you'd like to see a real world working example of `s-function.json` with event sources, [check out this test function](https://github.com/serverless/serverless/blob/master/tests/test-prj/nodejscomponent/group1/function1/s-function.json#L10-L40)." } [/block]
{"_id":"56bacbea4aa5930d00da7804","type":"basic","user":"562120887c515c0d008eee9b","version":"56bacbe64aa5930d00da77d8","__v":0,"api":{"settings":"","auth":"required","params":[],"url":"","results":{"codes":[{"name":"","status":200,"language":"json","code":"{}"},{"status":400,"language":"json","code":"{}","name":""}]}},"body":"Every Serverless Project uses resources from Amazon Web Services and divides these resources into three groups:\n\n* AWS Lambdas\n* AWS API Gateway REST API\n* AWS Other Resources (IAM Roles, DynamoDB tables, S3 Buckets, etc.)\n\nServerless Projects don't have environments (they live exclusively on AWS).  However, there is still need to separate and isolate the AWS resources a Project uses for development, testing and production purposes and Serverless does this through *Stages*.  Stages are similar to environments, except they exist merely to separate and isolate your Project's AWS resources.\n\nEach Serverless Project can have one or multiple Stages, and each Stage can have one or multiple Regions.  Regions are based off of [AWS Regions](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/), like `us-east-1`.  Some AWS resources  come with their own \"stage\" concepts and Serverless Project Stages are designed to integrate with those, wherever possible.  Here is how:\n\n**AWS Lambdas**\nYour Project will have one set of of deployed Lambda Functions on AWS, which can be replicated across each Region your Project uses.  Every Lambda Function can have multiple *versions* and *aliases*.  When you deploy a Function in your Project to a Stage, it deploy a Lambda that will be immediately versioned and aliased under the name of that Stage.\n\n**AWS API Gateway REST API**\nIf your Functions have Endpoint data in their `s-function.json` files, a REST API on AWS API Gateway will automatically be created for your Project.  Projects can only have one REST API, which can be replicated across each Region your Project uses.  Every API Gateway REST API can have multiple stages.  When you deploy an Endpoint in your Project to a Project Stage, it builds the Endpoint on your API Gateway REST API and then creates a deployment in that API Gateway stage.\n\n**AWS Other Resources**\nYour Project's other AWS resources are the only AWS resources that have separate deployments for each Stage.  These separate Stage deployments can be replicated across each Region your Project uses as well.  \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Creating Your Project Stages\"\n}\n[/block]\n\nWe recommend every Project have the following Stages.\n\n* dev\n* beta\n* prod\n\nIf you are working on a team with multiple developers, we recommend giving each developer working on the Project their own Stage.  In this case, your Project might have Stages like this:\n\n* dev\n* tom\n* jeff\n* beta\n* prod\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Deploying Your Functions\"\n}\n[/block]\nWhen you deploy your Function's Code (aka your AWS Lambda Function), it is given a `LATEST` version by default.  However, pointing your Event Source Maps or your REST API Endpoints to `LATEST` is highly discouraged.  This is because when multiple developers are working on the same Lambda function, they can trample each-other's work, if they have any resources that are pointing toward the `LATEST` version. \n\nTo avoid all of this, Serverless never uses `LATEST`.  Every time you create or update your Lambda Function, it is automatically versioned and aliased to the Project Stage you specify.  This avoids the \"trampling\" issue entirely.  Further, it allows Serverless to include Environment Variables and Stage-specific IAM Roles within the Lambda Function, which AWS does not yet have support for.\n\n**Here is what happens when you deploy your Function's Code:**\n\n  * If no Stage is set, it deploys to your Project's “dev” Stage by default\n  * Your Environment Variables are downloaded from your Project's Bucket and the Variables for the specified Stage are added into your Code.\n  * The IAM role specified in the s-project.json for the specified Stage is added to your Lambda on deployment.\n  * Your Lambda is uploaded to your Project Bucket with a version number attached.\n  * Your Lambda is deployed via CloudFormation w/ `publish: true` set.  This publishes a new Version immediately.\n  * An update request is sent to your deployed Lambda Version to Alias it with the specified Stage.\n\n**Here is what happens when you deploy your Function's Endpoint:**\n\n  * If no Stage is set, it deploys to your Project's “dev” Stage by default\n  * The Endpoint is constructed on your REST API in the specified Region\n  * A new Deployment is created.\n  * After Deployment is created, the Stage variable is reset to the Stage name.","createdAt":"2015-12-02T13:57:47.101Z","hidden":false,"updates":[],"link_external":false,"order":5,"slug":"workflow","link_url":"","project":"5611c207f2aeda0d002b3734","sync_unique":"","title":"Workflow","category":"56bc3b9430784e0d001b4a5e","excerpt":"The recommended workflow for Serverless Projects.","githubsync":"","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Workflow

The recommended workflow for Serverless Projects.

Every Serverless Project uses resources from Amazon Web Services and divides these resources into three groups: * AWS Lambdas * AWS API Gateway REST API * AWS Other Resources (IAM Roles, DynamoDB tables, S3 Buckets, etc.) Serverless Projects don't have environments (they live exclusively on AWS). However, there is still need to separate and isolate the AWS resources a Project uses for development, testing and production purposes and Serverless does this through *Stages*. Stages are similar to environments, except they exist merely to separate and isolate your Project's AWS resources. Each Serverless Project can have one or multiple Stages, and each Stage can have one or multiple Regions. Regions are based off of [AWS Regions](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/), like `us-east-1`. Some AWS resources come with their own "stage" concepts and Serverless Project Stages are designed to integrate with those, wherever possible. Here is how: **AWS Lambdas** Your Project will have one set of of deployed Lambda Functions on AWS, which can be replicated across each Region your Project uses. Every Lambda Function can have multiple *versions* and *aliases*. When you deploy a Function in your Project to a Stage, it deploy a Lambda that will be immediately versioned and aliased under the name of that Stage. **AWS API Gateway REST API** If your Functions have Endpoint data in their `s-function.json` files, a REST API on AWS API Gateway will automatically be created for your Project. Projects can only have one REST API, which can be replicated across each Region your Project uses. Every API Gateway REST API can have multiple stages. When you deploy an Endpoint in your Project to a Project Stage, it builds the Endpoint on your API Gateway REST API and then creates a deployment in that API Gateway stage. **AWS Other Resources** Your Project's other AWS resources are the only AWS resources that have separate deployments for each Stage. These separate Stage deployments can be replicated across each Region your Project uses as well. [block:api-header] { "type": "basic", "title": "Creating Your Project Stages" } [/block] We recommend every Project have the following Stages. * dev * beta * prod If you are working on a team with multiple developers, we recommend giving each developer working on the Project their own Stage. In this case, your Project might have Stages like this: * dev * tom * jeff * beta * prod [block:api-header] { "type": "basic", "title": "Deploying Your Functions" } [/block] When you deploy your Function's Code (aka your AWS Lambda Function), it is given a `LATEST` version by default. However, pointing your Event Source Maps or your REST API Endpoints to `LATEST` is highly discouraged. This is because when multiple developers are working on the same Lambda function, they can trample each-other's work, if they have any resources that are pointing toward the `LATEST` version. To avoid all of this, Serverless never uses `LATEST`. Every time you create or update your Lambda Function, it is automatically versioned and aliased to the Project Stage you specify. This avoids the "trampling" issue entirely. Further, it allows Serverless to include Environment Variables and Stage-specific IAM Roles within the Lambda Function, which AWS does not yet have support for. **Here is what happens when you deploy your Function's Code:** * If no Stage is set, it deploys to your Project's “dev” Stage by default * Your Environment Variables are downloaded from your Project's Bucket and the Variables for the specified Stage are added into your Code. * The IAM role specified in the s-project.json for the specified Stage is added to your Lambda on deployment. * Your Lambda is uploaded to your Project Bucket with a version number attached. * Your Lambda is deployed via CloudFormation w/ `publish: true` set. This publishes a new Version immediately. * An update request is sent to your deployed Lambda Version to Alias it with the specified Stage. **Here is what happens when you deploy your Function's Endpoint:** * If no Stage is set, it deploys to your Project's “dev” Stage by default * The Endpoint is constructed on your REST API in the specified Region * A new Deployment is created. * After Deployment is created, the Stage variable is reset to the Stage name.
Every Serverless Project uses resources from Amazon Web Services and divides these resources into three groups: * AWS Lambdas * AWS API Gateway REST API * AWS Other Resources (IAM Roles, DynamoDB tables, S3 Buckets, etc.) Serverless Projects don't have environments (they live exclusively on AWS). However, there is still need to separate and isolate the AWS resources a Project uses for development, testing and production purposes and Serverless does this through *Stages*. Stages are similar to environments, except they exist merely to separate and isolate your Project's AWS resources. Each Serverless Project can have one or multiple Stages, and each Stage can have one or multiple Regions. Regions are based off of [AWS Regions](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/), like `us-east-1`. Some AWS resources come with their own "stage" concepts and Serverless Project Stages are designed to integrate with those, wherever possible. Here is how: **AWS Lambdas** Your Project will have one set of of deployed Lambda Functions on AWS, which can be replicated across each Region your Project uses. Every Lambda Function can have multiple *versions* and *aliases*. When you deploy a Function in your Project to a Stage, it deploy a Lambda that will be immediately versioned and aliased under the name of that Stage. **AWS API Gateway REST API** If your Functions have Endpoint data in their `s-function.json` files, a REST API on AWS API Gateway will automatically be created for your Project. Projects can only have one REST API, which can be replicated across each Region your Project uses. Every API Gateway REST API can have multiple stages. When you deploy an Endpoint in your Project to a Project Stage, it builds the Endpoint on your API Gateway REST API and then creates a deployment in that API Gateway stage. **AWS Other Resources** Your Project's other AWS resources are the only AWS resources that have separate deployments for each Stage. These separate Stage deployments can be replicated across each Region your Project uses as well. [block:api-header] { "type": "basic", "title": "Creating Your Project Stages" } [/block] We recommend every Project have the following Stages. * dev * beta * prod If you are working on a team with multiple developers, we recommend giving each developer working on the Project their own Stage. In this case, your Project might have Stages like this: * dev * tom * jeff * beta * prod [block:api-header] { "type": "basic", "title": "Deploying Your Functions" } [/block] When you deploy your Function's Code (aka your AWS Lambda Function), it is given a `LATEST` version by default. However, pointing your Event Source Maps or your REST API Endpoints to `LATEST` is highly discouraged. This is because when multiple developers are working on the same Lambda function, they can trample each-other's work, if they have any resources that are pointing toward the `LATEST` version. To avoid all of this, Serverless never uses `LATEST`. Every time you create or update your Lambda Function, it is automatically versioned and aliased to the Project Stage you specify. This avoids the "trampling" issue entirely. Further, it allows Serverless to include Environment Variables and Stage-specific IAM Roles within the Lambda Function, which AWS does not yet have support for. **Here is what happens when you deploy your Function's Code:** * If no Stage is set, it deploys to your Project's “dev” Stage by default * Your Environment Variables are downloaded from your Project's Bucket and the Variables for the specified Stage are added into your Code. * The IAM role specified in the s-project.json for the specified Stage is added to your Lambda on deployment. * Your Lambda is uploaded to your Project Bucket with a version number attached. * Your Lambda is deployed via CloudFormation w/ `publish: true` set. This publishes a new Version immediately. * An update request is sent to your deployed Lambda Version to Alias it with the specified Stage. **Here is what happens when you deploy your Function's Endpoint:** * If no Stage is set, it deploys to your Project's “dev” Stage by default * The Endpoint is constructed on your REST API in the specified Region * A new Deployment is created. * After Deployment is created, the Stage variable is reset to the Stage name.
{"_id":"56bacbe94aa5930d00da77fb","createdAt":"2016-01-18T05:55:53.562Z","githubsync":"","type":"basic","api":{"settings":"","auth":"required","params":[],"url":"","results":{"codes":[{"language":"json","status":200,"name":"","code":"{}"},{"name":"","code":"{}","language":"json","status":400}]}},"title":"Installing Plugins","version":"56bacbe64aa5930d00da77d8","sync_unique":"","category":"56bc3b9430784e0d001b4a5e","excerpt":"","hidden":false,"isReference":false,"link_url":"","order":6,"project":"5611c207f2aeda0d002b3734","body":"You can extend the Serverless Framework through Serverless Plugins that have been authored by our community.  They are packaged as *npm* modules.\n\nRight now, the available plugins are listed in the Serverless Framework's README file (we are working on making discovery easier).  To install them, find their npm names and follow these steps:\n\n* Go to the root of your Serverless Project\n* Run `npm install <plugin> --save`\n* In your Project's `s-project.json`, in the `plugins` property, add the npm name of your recently added plugin to the array, like this:\n```\nplugins: [ \n     \"serverless-optimizer-plugin\"\n]\n```","link_external":false,"slug":"installing-plugins","updates":["56c2711947394f0d00e2285d","56c27418326dc317005b99a8","56efc7ae04e6d30e000384c9"],"user":"5611c1e58c76a61900fd0739","__v":3,"metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Installing Plugins


You can extend the Serverless Framework through Serverless Plugins that have been authored by our community. They are packaged as *npm* modules. Right now, the available plugins are listed in the Serverless Framework's README file (we are working on making discovery easier). To install them, find their npm names and follow these steps: * Go to the root of your Serverless Project * Run `npm install <plugin> --save` * In your Project's `s-project.json`, in the `plugins` property, add the npm name of your recently added plugin to the array, like this: ``` plugins: [ "serverless-optimizer-plugin" ] ```
You can extend the Serverless Framework through Serverless Plugins that have been authored by our community. They are packaged as *npm* modules. Right now, the available plugins are listed in the Serverless Framework's README file (we are working on making discovery easier). To install them, find their npm names and follow these steps: * Go to the root of your Serverless Project * Run `npm install <plugin> --save` * In your Project's `s-project.json`, in the `plugins` property, add the npm name of your recently added plugin to the array, like this: ``` plugins: [ "serverless-optimizer-plugin" ] ```
{"_id":"56bacbe94aa5930d00da77fc","githubsync":"","link_url":"","project":"5611c207f2aeda0d002b3734","type":"basic","__v":0,"hidden":false,"slug":"creating-plugins","sync_unique":"","title":"Creating Plugins","version":"56bacbe64aa5930d00da77d8","createdAt":"2016-01-13T20:40:45.663Z","api":{"settings":"","auth":"required","params":[],"url":"","results":{"codes":[{"name":"","code":"{}","language":"json","status":200},{"language":"json","status":400,"name":"","code":"{}"}]}},"category":"56bc3b9430784e0d001b4a5e","excerpt":"All you need to know about creating and publishing Serverless Plugins.","link_external":false,"order":7,"updates":[],"user":"562120887c515c0d008eee9b","body":"One of our core principles is to make the Framework completely extensible.  To stick to that principle, we have designed the entire framework so developers can modify or extend everything that it does.\n\nAll of the functionality in the Serverless Framework is divided into **Actions**.  For example, the functionality to create a new Serverless Project exists in an Action, and creating a new stage in that project exists in a separate Action.  If an operation is long or complex, like deploying a Lambda function, it is divided into multiple Actions so developers can modify parts of the process, instead of the whole process.  Actions can also call other Actions.  For example, the ProjectCreate Action calls StageCreate and RegionCreate Actions.\n\nEven better, Serverless also features **Hooks** which allow you to add functions that run *before* and *after* an individual Action.  Like we said, extensibility is one of our core principles.  \n\nTo add custom **Actions** and **Hooks**, make a **Serverless Plugin**.  The fastest way to do this is to use the [Serverless Plugin Boilerplate project](https://github.com/serverless/serverless-plugin-boilerplate).  It has detailed instructions and inline comments to help you build your plugin.","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Creating Plugins

All you need to know about creating and publishing Serverless Plugins.

One of our core principles is to make the Framework completely extensible. To stick to that principle, we have designed the entire framework so developers can modify or extend everything that it does. All of the functionality in the Serverless Framework is divided into **Actions**. For example, the functionality to create a new Serverless Project exists in an Action, and creating a new stage in that project exists in a separate Action. If an operation is long or complex, like deploying a Lambda function, it is divided into multiple Actions so developers can modify parts of the process, instead of the whole process. Actions can also call other Actions. For example, the ProjectCreate Action calls StageCreate and RegionCreate Actions. Even better, Serverless also features **Hooks** which allow you to add functions that run *before* and *after* an individual Action. Like we said, extensibility is one of our core principles. To add custom **Actions** and **Hooks**, make a **Serverless Plugin**. The fastest way to do this is to use the [Serverless Plugin Boilerplate project](https://github.com/serverless/serverless-plugin-boilerplate). It has detailed instructions and inline comments to help you build your plugin.
One of our core principles is to make the Framework completely extensible. To stick to that principle, we have designed the entire framework so developers can modify or extend everything that it does. All of the functionality in the Serverless Framework is divided into **Actions**. For example, the functionality to create a new Serverless Project exists in an Action, and creating a new stage in that project exists in a separate Action. If an operation is long or complex, like deploying a Lambda function, it is divided into multiple Actions so developers can modify parts of the process, instead of the whole process. Actions can also call other Actions. For example, the ProjectCreate Action calls StageCreate and RegionCreate Actions. Even better, Serverless also features **Hooks** which allow you to add functions that run *before* and *after* an individual Action. Like we said, extensibility is one of our core principles. To add custom **Actions** and **Hooks**, make a **Serverless Plugin**. The fastest way to do this is to use the [Serverless Plugin Boilerplate project](https://github.com/serverless/serverless-plugin-boilerplate). It has detailed instructions and inline comments to help you build your plugin.
{"_id":"56bacbea4aa5930d00da7805","category":"56bc3b9430784e0d001b4a5e","type":"basic","isReference":false,"link_external":false,"order":8,"project":"5611c207f2aeda0d002b3734","updates":["569cb068ceb7510d00f2a556","56df1e1101b2ec17009284bc"],"version":"56bacbe64aa5930d00da77d8","body":"## Don't give `AdministratorAccess` to AWS API keys\nWhile the getting started guide says to create an administrative user with `AdministratorAccess` permissions, it only does this to get you going faster. As stated this should not be done in a production environment. Our recommendation is to give your users with API access key `PowerUserAccess` at a maximum. The fallout is you will not be able to execute a cloudformation json file from the command line that creates any IAM resources. This should be done from the AWS CloudFormation UI, behind a user that has 2FA enabled and a secure password. All the Serverless tooling has a `-c, --noExeCf` option that will simply update your CloudFormation file, which can then be executed in the UI.\n\n## Keep your lambda codebase as small as possible\nThe smaller the size of code, the quicker your container gets up and running. The less code in the execution path, the quicker your runtime VM returns a result. Both of these statements verified by AWS Lambda engineers.\n\n## Reuse your Lambda code\nAll Serverless Functions can use the `lib` folder located within the Component that holds the Function. If you feel that your functions uses the same code logic, it's best to keep that logic in that `lib` folder.\n\n## Keep your CloudFormation resources organized\nYou can define CF resources in the `s-project.json` or `s-module.json`. If there's a resources that is used only by a single Module, it's best to define it in the `s-module.json` to keep your Project resources organized. And if you decide to share your Module with the community, they'll have that resource available out of the box.\n\n## Initialize external services outside of your Lambda code\nWhen using services (like DynamoDB) make sure to initialize outside of your lambda code. Ex: module initializer (for Node), or to a static constructor (for Java). If you initiate a connection to DDB inside the Lambda function, that code will run on every invoke.","excerpt":"Some best practices that we recommend while working with the Serverless Framework.","githubsync":"","link_url":"","slug":"best-practices","sync_unique":"","__v":1,"api":{"settings":"","auth":"required","params":[],"url":"","results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]}},"createdAt":"2015-10-16T17:33:26.678Z","hidden":false,"title":"Best Practices","user":"562120887c515c0d008eee9b","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Best Practices

Some best practices that we recommend while working with the Serverless Framework.

## Don't give `AdministratorAccess` to AWS API keys While the getting started guide says to create an administrative user with `AdministratorAccess` permissions, it only does this to get you going faster. As stated this should not be done in a production environment. Our recommendation is to give your users with API access key `PowerUserAccess` at a maximum. The fallout is you will not be able to execute a cloudformation json file from the command line that creates any IAM resources. This should be done from the AWS CloudFormation UI, behind a user that has 2FA enabled and a secure password. All the Serverless tooling has a `-c, --noExeCf` option that will simply update your CloudFormation file, which can then be executed in the UI. ## Keep your lambda codebase as small as possible The smaller the size of code, the quicker your container gets up and running. The less code in the execution path, the quicker your runtime VM returns a result. Both of these statements verified by AWS Lambda engineers. ## Reuse your Lambda code All Serverless Functions can use the `lib` folder located within the Component that holds the Function. If you feel that your functions uses the same code logic, it's best to keep that logic in that `lib` folder. ## Keep your CloudFormation resources organized You can define CF resources in the `s-project.json` or `s-module.json`. If there's a resources that is used only by a single Module, it's best to define it in the `s-module.json` to keep your Project resources organized. And if you decide to share your Module with the community, they'll have that resource available out of the box. ## Initialize external services outside of your Lambda code When using services (like DynamoDB) make sure to initialize outside of your lambda code. Ex: module initializer (for Node), or to a static constructor (for Java). If you initiate a connection to DDB inside the Lambda function, that code will run on every invoke.
## Don't give `AdministratorAccess` to AWS API keys While the getting started guide says to create an administrative user with `AdministratorAccess` permissions, it only does this to get you going faster. As stated this should not be done in a production environment. Our recommendation is to give your users with API access key `PowerUserAccess` at a maximum. The fallout is you will not be able to execute a cloudformation json file from the command line that creates any IAM resources. This should be done from the AWS CloudFormation UI, behind a user that has 2FA enabled and a secure password. All the Serverless tooling has a `-c, --noExeCf` option that will simply update your CloudFormation file, which can then be executed in the UI. ## Keep your lambda codebase as small as possible The smaller the size of code, the quicker your container gets up and running. The less code in the execution path, the quicker your runtime VM returns a result. Both of these statements verified by AWS Lambda engineers. ## Reuse your Lambda code All Serverless Functions can use the `lib` folder located within the Component that holds the Function. If you feel that your functions uses the same code logic, it's best to keep that logic in that `lib` folder. ## Keep your CloudFormation resources organized You can define CF resources in the `s-project.json` or `s-module.json`. If there's a resources that is used only by a single Module, it's best to define it in the `s-module.json` to keep your Project resources organized. And if you decide to share your Module with the community, they'll have that resource available out of the box. ## Initialize external services outside of your Lambda code When using services (like DynamoDB) make sure to initialize outside of your lambda code. Ex: module initializer (for Node), or to a static constructor (for Java). If you initiate a connection to DDB inside the Lambda function, that code will run on every invoke.
{"_id":"56bacbe74aa5930d00da77dd","body":"The Serverless Framework is mostly a command line utility that makes it easy to manage your serverless projects. We've designed the CLI to be as user-friendly as possible. A typical Serverless command consists of a **context** and an **action**, along with some **options** and **parameters** where applicable. For example, for the following command:\n\n```\nserverless project create -n project-name -r us-east-1\n```\n\nThis command has a \"project\" **context**, and a \"create\" **action**. `-n project-name` and `-r us-east-1` are both options that the `serverless project create` command needs. It still needs more options, but the CLI is smart enough to know what's missing, and it'll prompt you for only what's missing. \n[block:callout]\n{\n  \"type\": \"info\",\n  \"body\": \"A parameter doesn't require the dash that an option requires (ex. `-s <some-option>`), which makes it a little easier to type. But that also means that the ordering of the parameters matter if a command needs more than one parameter.\\n\\nWe try to be consistent in our use of parameters and options. If there's a lot of data required from the user, we prefer setting them as options so that you wouldn't have to think about the ordering, but for simple commands, using parameters is better.\",\n  \"title\": \"The difference between a Parameter and an Option\"\n}\n[/block]\nSome commands (ie deployment commands) need a function and endpoint paths as parameters. These paths have a standard format:\n* Function Path: `<componentName>/<functionName>`\n* Endpoint Path: `<componentName>/<functionName>@<endpointUrl>~<endpointMethod>`\n* Event Path: `<componentName>/<functionName>#<eventName>`\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Function Paths Are Flexible\",\n  \"body\": \"Function Path just means the path to the function root directory relative to the component root. So if your function/endpoint/event are contained in extra sub folders, those subfolders should be included in the function path.\"\n}\n[/block]\nHere's a summary of all the available Serverless commands:\n\n```\nserverless project create\nserverless project init\nserverless project install\n\nserverless stage create\nserverless region create\nserverless component create\nserverless function create\n\nserverless function run\nserverless function logs\nserverless function deploy\nserverless endpoint deploy\nserverless event deploy\nserverless resources deploy\nserverless dash deploy\n\nserverless project remove\nserverless stage remove\nserverless region remove\nserverless resources remove\n\nserverless dash summary\nserverless env get\nserverless env list\nserverless env set\nserverless env unset\n```\n[block:callout]\n{\n  \"type\": \"success\",\n  \"title\": \"A Nifty Shortcut\",\n  \"body\": \"It's a bit tedious to type the `serverless` command every time you want to do something. You can use the `sls` or the `slss` shortcut instead. For example, you can create a new project by typing: `sls project create`. This applies to **all** other commands as well. Pretty neat, ha!\"\n}\n[/block]\nYou can find detailed information about each Serverless command, its required options and parameters, along with some examples below. Keep reading!\n\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Getting Help & Debugging\",\n  \"body\": \"Whenever you feel confused, just run `serverless` in the terminal. This will generate helpful information about all the available commands. You can also add the `-h` or `--help` option to any command for information about that specific command.\\n\\nIf you're facing some bugs, just add the `--debug` option to any command, which will run the command in **Debug Mode** that generates helpful information about what's going on with the code. \\n\\nYou can also ask for help from our community by [creating a new issue on our repo](https://github.com/serverless/serverless/issues/new), or asking in our [Gitter chat room](https://gitter.im/serverless/serverless) (ping [@ac360](https://github.com/ac360) or [@eahefnawy](https://github.com/eahefnawy) for support). Just make sure you provide your installed version of the Serverless Framework by running `serverless version`.\"\n}\n[/block]\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Turn Off CLI Interactivity\",\n  \"body\": \"We've designed our CLI with best user experience in mind. So most commands are in interactive mode where you'll be prompted for any missing options. However, when you're using our CLI programmatically (ie. By using Continuous Integration tools), you'll need to turn off the interactive mode. You can do that by setting an environment variable called `CI` to true.\"\n}\n[/block]","excerpt":"An overview of how the Serverless CLI works.","link_external":false,"project":"5611c207f2aeda0d002b3734","createdAt":"2015-12-07T12:03:00.487Z","githubsync":"","hidden":false,"isReference":false,"link_url":"","slug":"commands-overview","title":"CLI Overview","category":"56bacbe74aa5930d00da77da","order":0,"sync_unique":"","updates":["5683968cf46b2b0d0032b13a","568b3857d4e2360d0098013d","56f0d9d742c16f0e00e1fe8a"],"user":"562120887c515c0d008eee9b","__v":4,"api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"type":"basic","version":"56bacbe64aa5930d00da77d8","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

CLI Overview

An overview of how the Serverless CLI works.

The Serverless Framework is mostly a command line utility that makes it easy to manage your serverless projects. We've designed the CLI to be as user-friendly as possible. A typical Serverless command consists of a **context** and an **action**, along with some **options** and **parameters** where applicable. For example, for the following command: ``` serverless project create -n project-name -r us-east-1 ``` This command has a "project" **context**, and a "create" **action**. `-n project-name` and `-r us-east-1` are both options that the `serverless project create` command needs. It still needs more options, but the CLI is smart enough to know what's missing, and it'll prompt you for only what's missing. [block:callout] { "type": "info", "body": "A parameter doesn't require the dash that an option requires (ex. `-s <some-option>`), which makes it a little easier to type. But that also means that the ordering of the parameters matter if a command needs more than one parameter.\n\nWe try to be consistent in our use of parameters and options. If there's a lot of data required from the user, we prefer setting them as options so that you wouldn't have to think about the ordering, but for simple commands, using parameters is better.", "title": "The difference between a Parameter and an Option" } [/block] Some commands (ie deployment commands) need a function and endpoint paths as parameters. These paths have a standard format: * Function Path: `<componentName>/<functionName>` * Endpoint Path: `<componentName>/<functionName>@<endpointUrl>~<endpointMethod>` * Event Path: `<componentName>/<functionName>#<eventName>` [block:callout] { "type": "info", "title": "Function Paths Are Flexible", "body": "Function Path just means the path to the function root directory relative to the component root. So if your function/endpoint/event are contained in extra sub folders, those subfolders should be included in the function path." } [/block] Here's a summary of all the available Serverless commands: ``` serverless project create serverless project init serverless project install serverless stage create serverless region create serverless component create serverless function create serverless function run serverless function logs serverless function deploy serverless endpoint deploy serverless event deploy serverless resources deploy serverless dash deploy serverless project remove serverless stage remove serverless region remove serverless resources remove serverless dash summary serverless env get serverless env list serverless env set serverless env unset ``` [block:callout] { "type": "success", "title": "A Nifty Shortcut", "body": "It's a bit tedious to type the `serverless` command every time you want to do something. You can use the `sls` or the `slss` shortcut instead. For example, you can create a new project by typing: `sls project create`. This applies to **all** other commands as well. Pretty neat, ha!" } [/block] You can find detailed information about each Serverless command, its required options and parameters, along with some examples below. Keep reading! [block:callout] { "type": "info", "title": "Getting Help & Debugging", "body": "Whenever you feel confused, just run `serverless` in the terminal. This will generate helpful information about all the available commands. You can also add the `-h` or `--help` option to any command for information about that specific command.\n\nIf you're facing some bugs, just add the `--debug` option to any command, which will run the command in **Debug Mode** that generates helpful information about what's going on with the code. \n\nYou can also ask for help from our community by [creating a new issue on our repo](https://github.com/serverless/serverless/issues/new), or asking in our [Gitter chat room](https://gitter.im/serverless/serverless) (ping [@ac360](https://github.com/ac360) or [@eahefnawy](https://github.com/eahefnawy) for support). Just make sure you provide your installed version of the Serverless Framework by running `serverless version`." } [/block] [block:callout] { "type": "info", "title": "Turn Off CLI Interactivity", "body": "We've designed our CLI with best user experience in mind. So most commands are in interactive mode where you'll be prompted for any missing options. However, when you're using our CLI programmatically (ie. By using Continuous Integration tools), you'll need to turn off the interactive mode. You can do that by setting an environment variable called `CI` to true." } [/block]
The Serverless Framework is mostly a command line utility that makes it easy to manage your serverless projects. We've designed the CLI to be as user-friendly as possible. A typical Serverless command consists of a **context** and an **action**, along with some **options** and **parameters** where applicable. For example, for the following command: ``` serverless project create -n project-name -r us-east-1 ``` This command has a "project" **context**, and a "create" **action**. `-n project-name` and `-r us-east-1` are both options that the `serverless project create` command needs. It still needs more options, but the CLI is smart enough to know what's missing, and it'll prompt you for only what's missing. [block:callout] { "type": "info", "body": "A parameter doesn't require the dash that an option requires (ex. `-s <some-option>`), which makes it a little easier to type. But that also means that the ordering of the parameters matter if a command needs more than one parameter.\n\nWe try to be consistent in our use of parameters and options. If there's a lot of data required from the user, we prefer setting them as options so that you wouldn't have to think about the ordering, but for simple commands, using parameters is better.", "title": "The difference between a Parameter and an Option" } [/block] Some commands (ie deployment commands) need a function and endpoint paths as parameters. These paths have a standard format: * Function Path: `<componentName>/<functionName>` * Endpoint Path: `<componentName>/<functionName>@<endpointUrl>~<endpointMethod>` * Event Path: `<componentName>/<functionName>#<eventName>` [block:callout] { "type": "info", "title": "Function Paths Are Flexible", "body": "Function Path just means the path to the function root directory relative to the component root. So if your function/endpoint/event are contained in extra sub folders, those subfolders should be included in the function path." } [/block] Here's a summary of all the available Serverless commands: ``` serverless project create serverless project init serverless project install serverless stage create serverless region create serverless component create serverless function create serverless function run serverless function logs serverless function deploy serverless endpoint deploy serverless event deploy serverless resources deploy serverless dash deploy serverless project remove serverless stage remove serverless region remove serverless resources remove serverless dash summary serverless env get serverless env list serverless env set serverless env unset ``` [block:callout] { "type": "success", "title": "A Nifty Shortcut", "body": "It's a bit tedious to type the `serverless` command every time you want to do something. You can use the `sls` or the `slss` shortcut instead. For example, you can create a new project by typing: `sls project create`. This applies to **all** other commands as well. Pretty neat, ha!" } [/block] You can find detailed information about each Serverless command, its required options and parameters, along with some examples below. Keep reading! [block:callout] { "type": "info", "title": "Getting Help & Debugging", "body": "Whenever you feel confused, just run `serverless` in the terminal. This will generate helpful information about all the available commands. You can also add the `-h` or `--help` option to any command for information about that specific command.\n\nIf you're facing some bugs, just add the `--debug` option to any command, which will run the command in **Debug Mode** that generates helpful information about what's going on with the code. \n\nYou can also ask for help from our community by [creating a new issue on our repo](https://github.com/serverless/serverless/issues/new), or asking in our [Gitter chat room](https://gitter.im/serverless/serverless) (ping [@ac360](https://github.com/ac360) or [@eahefnawy](https://github.com/eahefnawy) for support). Just make sure you provide your installed version of the Serverless Framework by running `serverless version`." } [/block] [block:callout] { "type": "info", "title": "Turn Off CLI Interactivity", "body": "We've designed our CLI with best user experience in mind. So most commands are in interactive mode where you'll be prompted for any missing options. However, when you're using our CLI programmatically (ie. By using Continuous Integration tools), you'll need to turn off the interactive mode. You can do that by setting an environment variable called `CI` to true." } [/block]
{"_id":"56bacbe74aa5930d00da77de","api":{"results":{"codes":[{"language":"json","code":"{}","name":"","status":200},{"code":"{}","name":"","status":400,"language":"json"}]},"settings":"","auth":"required","params":[],"url":""},"githubsync":"","link_external":false,"project":"5611c207f2aeda0d002b3734","slug":"project-create","title":"Project Create","type":"basic","excerpt":"Creates a new Serverless project.","hidden":false,"link_url":"","user":"562120887c515c0d008eee9b","version":"56bacbe64aa5930d00da77d8","body":"```\nserverless project create\n```\nCreates a new Serverless project in the current working directory with a default `dev` stage. It takes the following options:\n\n* `-n <name>` the name of your project.\n* `-d <domain>` the domain of your project.\n* `-e <notificationEmail>` an email to use for AWS alarms.\n* `-p <awsProfile>` an AWS profile that is defined in `~/.aws/credentials` file.\n* `-r <region>` a lambda supported region for your project.\n* `-s <stage>` **Optional** - the first stage for your new project. default is `dev`\n* `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"body\": \"Use camelCase when naming your project as Serverless uses CloudFormation heavily and they tokenize resources names with `-`.\",\n  \"title\": \"Pro Tip\"\n}\n[/block]\n### Examples\n```\nserverless project create\n```\nIn this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience.\n\n```\nserverless project create -n myProject -d my-project.com\n```\nIn this example, you provided the name and the domain of the project, so you'll only be prompted for the **region**, **email** and **AWS profile**.\n\n```\nserverless project create -c true\n```\nIn this example, you've instructed Serverless to **not** execute CloudFormation. So after you enter the project information, the CloudFormation stack won't be created, and you'll have to manually upload the relevant CF template file from the `_meta/resources` folder to AWS.","sync_unique":"","updates":[],"createdAt":"2015-12-02T14:17:05.360Z","order":1,"__v":0,"category":"56bacbe74aa5930d00da77da","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Project Create

Creates a new Serverless project.

``` serverless project create ``` Creates a new Serverless project in the current working directory with a default `dev` stage. It takes the following options: * `-n <name>` the name of your project. * `-d <domain>` the domain of your project. * `-e <notificationEmail>` an email to use for AWS alarms. * `-p <awsProfile>` an AWS profile that is defined in `~/.aws/credentials` file. * `-r <region>` a lambda supported region for your project. * `-s <stage>` **Optional** - the first stage for your new project. default is `dev` * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. [block:callout] { "type": "info", "body": "Use camelCase when naming your project as Serverless uses CloudFormation heavily and they tokenize resources names with `-`.", "title": "Pro Tip" } [/block] ### Examples ``` serverless project create ``` In this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience. ``` serverless project create -n myProject -d my-project.com ``` In this example, you provided the name and the domain of the project, so you'll only be prompted for the **region**, **email** and **AWS profile**. ``` serverless project create -c true ``` In this example, you've instructed Serverless to **not** execute CloudFormation. So after you enter the project information, the CloudFormation stack won't be created, and you'll have to manually upload the relevant CF template file from the `_meta/resources` folder to AWS.
``` serverless project create ``` Creates a new Serverless project in the current working directory with a default `dev` stage. It takes the following options: * `-n <name>` the name of your project. * `-d <domain>` the domain of your project. * `-e <notificationEmail>` an email to use for AWS alarms. * `-p <awsProfile>` an AWS profile that is defined in `~/.aws/credentials` file. * `-r <region>` a lambda supported region for your project. * `-s <stage>` **Optional** - the first stage for your new project. default is `dev` * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. [block:callout] { "type": "info", "body": "Use camelCase when naming your project as Serverless uses CloudFormation heavily and they tokenize resources names with `-`.", "title": "Pro Tip" } [/block] ### Examples ``` serverless project create ``` In this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience. ``` serverless project create -n myProject -d my-project.com ``` In this example, you provided the name and the domain of the project, so you'll only be prompted for the **region**, **email** and **AWS profile**. ``` serverless project create -c true ``` In this example, you've instructed Serverless to **not** execute CloudFormation. So after you enter the project information, the CloudFormation stack won't be created, and you'll have to manually upload the relevant CF template file from the `_meta/resources` folder to AWS.
{"_id":"56bacbe74aa5930d00da77df","excerpt":"Installs a published Serverless project","hidden":false,"link_external":false,"order":2,"slug":"project-install","body":"```\nserverless project install\n```\nInstalls a new Serverless project in the current working directory with a default `dev` stage. It takes the following parameters and options:\n\n* `<npm-module-name>` (parameter): the name of the Serverless project you want to install that is published on npm.\n* `-n <name>` the name of your installed project.\n* `-d <domain>` the domain of your installed project.\n* `-e <notificationEmail>` an email to use for AWS alarms.\n* `-p <awsProfile>` an AWS profile that is defined in `~/.aws/credentials` file.\n* `-r <region>` a lambda supported region for your installed project.\n* `-s <stage>` **Optional** - the first stage for your installed project. default is `dev`\n* `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**.\n\n### Examples\n```\nserverless project install serverless-starter\n```\nIn this example, you've passed the required parameter (the serverless project you want to install), but all options are missing, so you'll be prompted to enter each of the required options for best user experience. Just like with `sls project create`.","githubsync":"","link_url":"","type":"basic","updates":[],"user":"562120887c515c0d008eee9b","version":"56bacbe64aa5930d00da77d8","__v":0,"api":{"auth":"required","params":[],"url":"","results":{"codes":[{"name":"","code":"{}","language":"json","status":200},{"status":400,"name":"","code":"{}","language":"json"}]},"settings":""},"project":"5611c207f2aeda0d002b3734","title":"Project Install","category":"56bacbe74aa5930d00da77da","createdAt":"2016-02-03T03:16:13.494Z","sync_unique":"","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Project Install

Installs a published Serverless project

``` serverless project install ``` Installs a new Serverless project in the current working directory with a default `dev` stage. It takes the following parameters and options: * `<npm-module-name>` (parameter): the name of the Serverless project you want to install that is published on npm. * `-n <name>` the name of your installed project. * `-d <domain>` the domain of your installed project. * `-e <notificationEmail>` an email to use for AWS alarms. * `-p <awsProfile>` an AWS profile that is defined in `~/.aws/credentials` file. * `-r <region>` a lambda supported region for your installed project. * `-s <stage>` **Optional** - the first stage for your installed project. default is `dev` * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. ### Examples ``` serverless project install serverless-starter ``` In this example, you've passed the required parameter (the serverless project you want to install), but all options are missing, so you'll be prompted to enter each of the required options for best user experience. Just like with `sls project create`.
``` serverless project install ``` Installs a new Serverless project in the current working directory with a default `dev` stage. It takes the following parameters and options: * `<npm-module-name>` (parameter): the name of the Serverless project you want to install that is published on npm. * `-n <name>` the name of your installed project. * `-d <domain>` the domain of your installed project. * `-e <notificationEmail>` an email to use for AWS alarms. * `-p <awsProfile>` an AWS profile that is defined in `~/.aws/credentials` file. * `-r <region>` a lambda supported region for your installed project. * `-s <stage>` **Optional** - the first stage for your installed project. default is `dev` * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. ### Examples ``` serverless project install serverless-starter ``` In this example, you've passed the required parameter (the serverless project you want to install), but all options are missing, so you'll be prompted to enter each of the required options for best user experience. Just like with `sls project create`.
{"_id":"56bacbe74aa5930d00da77e0","category":"56bacbe74aa5930d00da77da","link_url":"","order":3,"__v":0,"type":"basic","user":"562120887c515c0d008eee9b","version":"56bacbe64aa5930d00da77d8","createdAt":"2016-02-03T03:22:45.497Z","hidden":false,"project":"5611c207f2aeda0d002b3734","sync_unique":"","updates":[],"body":"```\nserverless project init\n```\n**Must be run within a Serverless Project**. Initializes a new Serverless project. It's useful when you `git clone` a Serverless project, and want to reconstruct the `_meta` folder and set up the project on AWS. It takes the following options:\n\n* `-n <name>` the name of your project.\n* `-d <domain>` the domain of your project.\n* `-e <notificationEmail>` an email to use for AWS alarms.\n* `-p <awsProfile>` an AWS profile that is defined in `~/.aws/credentials` file.\n* `-r <region>` a lambda supported region for your project.\n* `-s <stage>` **Optional** - the first stage for your new project. default is `dev`\n* `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**.\n\n### Examples\n```\nserverless project init\n```\nAfter you `git clone` a Serverless Project and `cd` inside the root directory of the project. You can run `serverless project init` to reconstruct the gitignored `_meta` folder and set up your project on your own AWS account. It's very similar to `sls project create`, except that you're using a shared project with all the code written for you.","excerpt":"Initializes a new Serverless project","link_external":false,"slug":"project-init","title":"Project Init","api":{"auth":"required","params":[],"url":"","results":{"codes":[{"name":"","code":"{}","language":"json","status":200},{"name":"","code":"{}","language":"json","status":400}]},"settings":""},"githubsync":"","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Project Init

Initializes a new Serverless project

``` serverless project init ``` **Must be run within a Serverless Project**. Initializes a new Serverless project. It's useful when you `git clone` a Serverless project, and want to reconstruct the `_meta` folder and set up the project on AWS. It takes the following options: * `-n <name>` the name of your project. * `-d <domain>` the domain of your project. * `-e <notificationEmail>` an email to use for AWS alarms. * `-p <awsProfile>` an AWS profile that is defined in `~/.aws/credentials` file. * `-r <region>` a lambda supported region for your project. * `-s <stage>` **Optional** - the first stage for your new project. default is `dev` * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. ### Examples ``` serverless project init ``` After you `git clone` a Serverless Project and `cd` inside the root directory of the project. You can run `serverless project init` to reconstruct the gitignored `_meta` folder and set up your project on your own AWS account. It's very similar to `sls project create`, except that you're using a shared project with all the code written for you.
``` serverless project init ``` **Must be run within a Serverless Project**. Initializes a new Serverless project. It's useful when you `git clone` a Serverless project, and want to reconstruct the `_meta` folder and set up the project on AWS. It takes the following options: * `-n <name>` the name of your project. * `-d <domain>` the domain of your project. * `-e <notificationEmail>` an email to use for AWS alarms. * `-p <awsProfile>` an AWS profile that is defined in `~/.aws/credentials` file. * `-r <region>` a lambda supported region for your project. * `-s <stage>` **Optional** - the first stage for your new project. default is `dev` * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. ### Examples ``` serverless project init ``` After you `git clone` a Serverless Project and `cd` inside the root directory of the project. You can run `serverless project init` to reconstruct the gitignored `_meta` folder and set up your project on your own AWS account. It's very similar to `sls project create`, except that you're using a shared project with all the code written for you.
{"_id":"56bacbe74aa5930d00da77e1","api":{"settings":"","auth":"required","params":[],"url":"","results":{"codes":[{"status":200,"name":"","code":"{}","language":"json"},{"code":"{}","language":"json","status":400,"name":""}]}},"category":"56bacbe74aa5930d00da77da","user":"562120887c515c0d008eee9b","createdAt":"2016-02-03T03:34:45.982Z","githubsync":"","hidden":false,"sync_unique":"","title":"Project Remove","updates":[],"body":"```\nserverless project remove\n```\n**Must be run within a Serverless Project**. Removes and cleans up your Serverless Project from AWS. It takes the following options:\n\n* `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**.\n\n### Examples\n```\nserverless project remove\n```\nIn this example, the command will remove all stages, regions and CF resources from AWS. This command is useful when you want to clean up your deprecated projects form AWS.\n\n```\nserverless project remove -c\n```\nIn this example, you've set the `-c` to true, so the command will remove all stages and regions of your project, but **it won't remove your CF resources**. It'll output a CF template in the `_meta/resources` folder that you can upload to the AWS console to manually remove your CF resources.","excerpt":"Removes and cleans up your Serverless Project from AWS.","link_external":false,"project":"5611c207f2aeda0d002b3734","slug":"project-remove","__v":0,"link_url":"","order":4,"type":"basic","version":"56bacbe64aa5930d00da77d8","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Project Remove

Removes and cleans up your Serverless Project from AWS.

``` serverless project remove ``` **Must be run within a Serverless Project**. Removes and cleans up your Serverless Project from AWS. It takes the following options: * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. ### Examples ``` serverless project remove ``` In this example, the command will remove all stages, regions and CF resources from AWS. This command is useful when you want to clean up your deprecated projects form AWS. ``` serverless project remove -c ``` In this example, you've set the `-c` to true, so the command will remove all stages and regions of your project, but **it won't remove your CF resources**. It'll output a CF template in the `_meta/resources` folder that you can upload to the AWS console to manually remove your CF resources.
``` serverless project remove ``` **Must be run within a Serverless Project**. Removes and cleans up your Serverless Project from AWS. It takes the following options: * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. ### Examples ``` serverless project remove ``` In this example, the command will remove all stages, regions and CF resources from AWS. This command is useful when you want to clean up your deprecated projects form AWS. ``` serverless project remove -c ``` In this example, you've set the `-c` to true, so the command will remove all stages and regions of your project, but **it won't remove your CF resources**. It'll output a CF template in the `_meta/resources` folder that you can upload to the AWS console to manually remove your CF resources.
{"_id":"56bacbe74aa5930d00da77e2","link_external":false,"api":{"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","auth":"required","params":[],"url":""},"category":"56bacbe74aa5930d00da77da","user":"562120887c515c0d008eee9b","title":"Stage Create","createdAt":"2015-12-02T14:17:17.185Z","excerpt":"creates a new stage for your serverless project","githubsync":"","link_url":"","order":5,"project":"5611c207f2aeda0d002b3734","type":"basic","updates":["5688f4c5e1f9a00d00350af1"],"__v":0,"body":"```\nserverless stage create\n```\n**Must be run inside a Serverless project.** It creates a new stage and its first region for your project. It takes the following options:\n\n* `-s <stage>` The name of your new stage.\n* `-r <region>` A lambda supported region for your new stage.\n\n### Examples\n```\nserverless stage create\n```\nIn this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience.\n\n```\nserverless stage create -s production -r us-east-1\n```\nIn this example, you provided all the required options (stage and region). So your stage will be created right away without prompting for anything else.","hidden":false,"slug":"stage-create","sync_unique":"","version":"56bacbe64aa5930d00da77d8","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Stage Create

creates a new stage for your serverless project

``` serverless stage create ``` **Must be run inside a Serverless project.** It creates a new stage and its first region for your project. It takes the following options: * `-s <stage>` The name of your new stage. * `-r <region>` A lambda supported region for your new stage. ### Examples ``` serverless stage create ``` In this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience. ``` serverless stage create -s production -r us-east-1 ``` In this example, you provided all the required options (stage and region). So your stage will be created right away without prompting for anything else.
``` serverless stage create ``` **Must be run inside a Serverless project.** It creates a new stage and its first region for your project. It takes the following options: * `-s <stage>` The name of your new stage. * `-r <region>` A lambda supported region for your new stage. ### Examples ``` serverless stage create ``` In this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience. ``` serverless stage create -s production -r us-east-1 ``` In this example, you provided all the required options (stage and region). So your stage will be created right away without prompting for anything else.
{"_id":"56bacbe74aa5930d00da77e3","__v":0,"githubsync":"","hidden":false,"type":"basic","api":{"settings":"","auth":"required","params":[],"url":"","results":{"codes":[{"name":"","code":"{}","language":"json","status":200},{"name":"","code":"{}","language":"json","status":400}]}},"body":"```\nserverless stage remove\n```\n**Must be run within a Serverless Project**. Removes an existing stage from your Serverless Project and AWS account, along with the CF resources defined in that stage. It takes the following options:\n\n* `-s <stage>` the stage you want to remove from your Serverless project.\n* `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**.\n\n### Examples\n```\nserverless stage remove -s production\n```\nIn this example, the command will instantly remove the `production` stage from your Serverless Project and AWS account along with any CF resources defined in that stage.\n\n```\nserverless stage remove -s production -c\n```\nIn this example, you've set the `-c` option to `true`, so the command will remove the `production` stage from your Serverless Project and AWS account, but **it won't remove the CF resources for that stage**. Instead, it'll output a CF template in the `_meta/resources` folder that you can execute manually on the AWS console.","link_external":false,"project":"5611c207f2aeda0d002b3734","slug":"stage-remove","updates":[],"version":"56bacbe64aa5930d00da77d8","category":"56bacbe74aa5930d00da77da","order":6,"sync_unique":"","title":"Stage Remove","user":"562120887c515c0d008eee9b","createdAt":"2016-02-03T03:44:42.754Z","excerpt":"Removes a stage from your Serverless Project","link_url":"","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Stage Remove

Removes a stage from your Serverless Project

``` serverless stage remove ``` **Must be run within a Serverless Project**. Removes an existing stage from your Serverless Project and AWS account, along with the CF resources defined in that stage. It takes the following options: * `-s <stage>` the stage you want to remove from your Serverless project. * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. ### Examples ``` serverless stage remove -s production ``` In this example, the command will instantly remove the `production` stage from your Serverless Project and AWS account along with any CF resources defined in that stage. ``` serverless stage remove -s production -c ``` In this example, you've set the `-c` option to `true`, so the command will remove the `production` stage from your Serverless Project and AWS account, but **it won't remove the CF resources for that stage**. Instead, it'll output a CF template in the `_meta/resources` folder that you can execute manually on the AWS console.
``` serverless stage remove ``` **Must be run within a Serverless Project**. Removes an existing stage from your Serverless Project and AWS account, along with the CF resources defined in that stage. It takes the following options: * `-s <stage>` the stage you want to remove from your Serverless project. * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. ### Examples ``` serverless stage remove -s production ``` In this example, the command will instantly remove the `production` stage from your Serverless Project and AWS account along with any CF resources defined in that stage. ``` serverless stage remove -s production -c ``` In this example, you've set the `-c` option to `true`, so the command will remove the `production` stage from your Serverless Project and AWS account, but **it won't remove the CF resources for that stage**. Instead, it'll output a CF template in the `_meta/resources` folder that you can execute manually on the AWS console.
{"_id":"56bacbe74aa5930d00da77e4","api":{"settings":"","auth":"required","params":[],"url":"","results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]}},"excerpt":"Creates a new region for an existing stage.","order":7,"title":"Region Create","body":"```\nserverless region create\n```\n**Must be run inside a Serverless project.** It creates a new region for an existing stage inside your project. It takes the following options:\n\n* `-s <stage>` The name of the stage you want to add a region to. Must exist in your project.\n* `-r <region>` A lambda supported region for your chosen stage.\n\n### Examples\n```\nserverless region create\n```\nIn this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience.\n\n```\nserverless region create -s production -r us-east-1\n```\nIn this example, you're creating a new `us-east-1` region in the `production` stage. If the `production` stage doesn't exist in your project, or already has `us-east-1` region defined, you'll get an error.","githubsync":"","hidden":false,"link_external":false,"slug":"region-create","sync_unique":"","category":"56bacbe74aa5930d00da77da","createdAt":"2015-12-02T14:17:40.588Z","link_url":"","project":"5611c207f2aeda0d002b3734","user":"562120887c515c0d008eee9b","version":"56bacbe64aa5930d00da77d8","__v":0,"type":"basic","updates":["5688f4f96ac8f90d0043c4f5"],"metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Region Create

Creates a new region for an existing stage.

``` serverless region create ``` **Must be run inside a Serverless project.** It creates a new region for an existing stage inside your project. It takes the following options: * `-s <stage>` The name of the stage you want to add a region to. Must exist in your project. * `-r <region>` A lambda supported region for your chosen stage. ### Examples ``` serverless region create ``` In this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience. ``` serverless region create -s production -r us-east-1 ``` In this example, you're creating a new `us-east-1` region in the `production` stage. If the `production` stage doesn't exist in your project, or already has `us-east-1` region defined, you'll get an error.
``` serverless region create ``` **Must be run inside a Serverless project.** It creates a new region for an existing stage inside your project. It takes the following options: * `-s <stage>` The name of the stage you want to add a region to. Must exist in your project. * `-r <region>` A lambda supported region for your chosen stage. ### Examples ``` serverless region create ``` In this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience. ``` serverless region create -s production -r us-east-1 ``` In this example, you're creating a new `us-east-1` region in the `production` stage. If the `production` stage doesn't exist in your project, or already has `us-east-1` region defined, you'll get an error.
{"_id":"56bacbe74aa5930d00da77e5","link_external":false,"title":"Region Remove","createdAt":"2016-02-03T03:50:17.284Z","githubsync":"","sync_unique":"","hidden":false,"order":8,"project":"5611c207f2aeda0d002b3734","slug":"region-remove","type":"basic","__v":0,"api":{"params":[],"url":"","results":{"codes":[{"name":"","code":"{}","language":"json","status":200},{"language":"json","status":400,"name":"","code":"{}"}]},"settings":"","auth":"required"},"category":"56bacbe74aa5930d00da77da","user":"562120887c515c0d008eee9b","version":"56bacbe64aa5930d00da77d8","link_url":"","updates":[],"body":"```\nserverless region remove\n```\n**Must be run within a Serverless Project**. Removes an existing region from an existing stage in your Serverless Project, along with the CF resources defined in that region. It takes the following options:\n\n* `-s <stage>` the stage that contains the region you want to remove from your Serverless Project.\n* `-r <region>` the region you want to remove from your Serverless project.\n* `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**.\n\n### Examples\n```\nserverless region remove -s production -r us-west-2\n```\nIn this example, the command will instantly remove the `us-west-2` region from the `production` stage in your Serverless Project. It will also clean up your AWS account from that region along with any CF resources defined in that region.\n\n```\nserverless region remove -s production -r us-west-2 -c\n```\nIn this example, you've set the `-c` option to `true`, so the command will remove the `us-west-2` region from the `production` stage, but **it won't remove the CF resources for that region**. Instead, it'll output a CF template in the `_meta/resources` folder that you can execute manually on the AWS console.","excerpt":"Removes a region from a stage in your Serverless Project.","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Region Remove

Removes a region from a stage in your Serverless Project.

``` serverless region remove ``` **Must be run within a Serverless Project**. Removes an existing region from an existing stage in your Serverless Project, along with the CF resources defined in that region. It takes the following options: * `-s <stage>` the stage that contains the region you want to remove from your Serverless Project. * `-r <region>` the region you want to remove from your Serverless project. * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. ### Examples ``` serverless region remove -s production -r us-west-2 ``` In this example, the command will instantly remove the `us-west-2` region from the `production` stage in your Serverless Project. It will also clean up your AWS account from that region along with any CF resources defined in that region. ``` serverless region remove -s production -r us-west-2 -c ``` In this example, you've set the `-c` option to `true`, so the command will remove the `us-west-2` region from the `production` stage, but **it won't remove the CF resources for that region**. Instead, it'll output a CF template in the `_meta/resources` folder that you can execute manually on the AWS console.
``` serverless region remove ``` **Must be run within a Serverless Project**. Removes an existing region from an existing stage in your Serverless Project, along with the CF resources defined in that region. It takes the following options: * `-s <stage>` the stage that contains the region you want to remove from your Serverless Project. * `-r <region>` the region you want to remove from your Serverless project. * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. ### Examples ``` serverless region remove -s production -r us-west-2 ``` In this example, the command will instantly remove the `us-west-2` region from the `production` stage in your Serverless Project. It will also clean up your AWS account from that region along with any CF resources defined in that region. ``` serverless region remove -s production -r us-west-2 -c ``` In this example, you've set the `-c` option to `true`, so the command will remove the `us-west-2` region from the `production` stage, but **it won't remove the CF resources for that region**. Instead, it'll output a CF template in the `_meta/resources` folder that you can execute manually on the AWS console.
{"_id":"56bacbe74aa5930d00da77e6","api":{"params":[],"results":{"codes":[{"language":"json","status":200,"name":"","code":"{}"},{"status":400,"name":"","code":"{}","language":"json"}]},"settings":"","url":"","auth":"required"},"createdAt":"2016-01-13T21:22:35.737Z","excerpt":"Creates a new Serverless Component inside your project's root directory.","hidden":false,"link_external":false,"type":"basic","category":"56bacbe74aa5930d00da77da","githubsync":"","order":9,"sync_unique":"","title":"Component Create","link_url":"","project":"5611c207f2aeda0d002b3734","slug":"component-create","updates":[],"user":"562120887c515c0d008eee9b","version":"56bacbe64aa5930d00da77d8","__v":1,"body":"```\nserverless component create\n```\n**Must be run inside a Serverless Project.** It generates a basic scaffolding for a new Serverless Component inside your project's root directory. This command takes the following options and parameters:\n\n* `componentName` (parameter) The name of your new Component.\n* `-r <runtime>` Optional - The runtime of your new component. Default: nodejs.\n\n### Examples\n```\nserverless component create\n```\nIn this example, all options are missing, so you'll be prompted to enter each of the required options/parameters for best user experience. Because you didn't provide a runtime option (`-r`), the created component will have the `nodejs` runtime by default.\n\n```\nserverless component create -r python2.7\n```\nJust like the previous example, but because you provided a runtime of `python2.7`, your component will be a python based component. All the modules and functions that you later create for this component will be python based as well.\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"It's `python2.7` not `python`\",\n  \"body\": \"As you already noticed, the runtime for python is `python2.7` not `python`. We're just keeping in mind the possibility that AWS Lambda provides support for `python3`, since the python community is now divided almost equally between those two versions.\"\n}\n[/block]\n```\nserverless component create my-component\n```\nIn this example, you'll instantly create a Component named `my-component` with a default runtime of `nodejs`. It'll return an error if you already have a Component named \"my-component\" inside your Project.","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Component Create

Creates a new Serverless Component inside your project's root directory.

``` serverless component create ``` **Must be run inside a Serverless Project.** It generates a basic scaffolding for a new Serverless Component inside your project's root directory. This command takes the following options and parameters: * `componentName` (parameter) The name of your new Component. * `-r <runtime>` Optional - The runtime of your new component. Default: nodejs. ### Examples ``` serverless component create ``` In this example, all options are missing, so you'll be prompted to enter each of the required options/parameters for best user experience. Because you didn't provide a runtime option (`-r`), the created component will have the `nodejs` runtime by default. ``` serverless component create -r python2.7 ``` Just like the previous example, but because you provided a runtime of `python2.7`, your component will be a python based component. All the modules and functions that you later create for this component will be python based as well. [block:callout] { "type": "warning", "title": "It's `python2.7` not `python`", "body": "As you already noticed, the runtime for python is `python2.7` not `python`. We're just keeping in mind the possibility that AWS Lambda provides support for `python3`, since the python community is now divided almost equally between those two versions." } [/block] ``` serverless component create my-component ``` In this example, you'll instantly create a Component named `my-component` with a default runtime of `nodejs`. It'll return an error if you already have a Component named "my-component" inside your Project.
``` serverless component create ``` **Must be run inside a Serverless Project.** It generates a basic scaffolding for a new Serverless Component inside your project's root directory. This command takes the following options and parameters: * `componentName` (parameter) The name of your new Component. * `-r <runtime>` Optional - The runtime of your new component. Default: nodejs. ### Examples ``` serverless component create ``` In this example, all options are missing, so you'll be prompted to enter each of the required options/parameters for best user experience. Because you didn't provide a runtime option (`-r`), the created component will have the `nodejs` runtime by default. ``` serverless component create -r python2.7 ``` Just like the previous example, but because you provided a runtime of `python2.7`, your component will be a python based component. All the modules and functions that you later create for this component will be python based as well. [block:callout] { "type": "warning", "title": "It's `python2.7` not `python`", "body": "As you already noticed, the runtime for python is `python2.7` not `python`. We're just keeping in mind the possibility that AWS Lambda provides support for `python3`, since the python community is now divided almost equally between those two versions." } [/block] ``` serverless component create my-component ``` In this example, you'll instantly create a Component named `my-component` with a default runtime of `nodejs`. It'll return an error if you already have a Component named "my-component" inside your Project.
{"_id":"56bacbe74aa5930d00da77e8","category":"56bacbe74aa5930d00da77da","link_external":false,"project":"5611c207f2aeda0d002b3734","sync_unique":"","version":"56bacbe64aa5930d00da77d8","updates":[],"user":"562120887c515c0d008eee9b","createdAt":"2015-12-02T14:18:21.457Z","hidden":false,"link_url":"","title":"Function Create","body":"```\nserverless function create\n```\n**Must be run inside a Serverless Project.** It generates a basic scaffolding for a new Function inside an existing Component within your project. This command takes the following parameters:\n\n* `functionPath` The path of the function you want to create. The function path should start from the component you want to create a function for.\n\n### Examples\n```\nserverless function create component1/function1\n```\nIn this example, you'll create a function named `function1` inside your `component1` component.\n\n```\nserverless function create component1/subfolder/function1\n```\nIn this example, you'll create a function named `function1` inside the `subfolder` subfolder inside component `function1`. The command will create any subfolders you need to make your function path valid.\n\n```\nserverless function create\n```\nIn this example, you did not provide a function path. This will only work if you're running the command from within a component root. In that case you'll be prompted to choose a function name, after that a function with the chosen name will be created in the component you're in.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"body\": \"Depending on whether the runtime of the component you chose for your function is `nodejs` or `python2.7`, the framework will generate the function handler file accordingly. In case of `nodejs` you'll have `handler.js`, in case of `python2.7`, you'll have `handler.py`.\",\n  \"title\": \"Generated Function Runtime\"\n}\n[/block]","excerpt":"Creates a new Function for an existing Component.","slug":"function-create","type":"basic","__v":1,"api":{"settings":"","url":"","auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]}},"githubsync":"","order":10,"metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Function Create

Creates a new Function for an existing Component.

``` serverless function create ``` **Must be run inside a Serverless Project.** It generates a basic scaffolding for a new Function inside an existing Component within your project. This command takes the following parameters: * `functionPath` The path of the function you want to create. The function path should start from the component you want to create a function for. ### Examples ``` serverless function create component1/function1 ``` In this example, you'll create a function named `function1` inside your `component1` component. ``` serverless function create component1/subfolder/function1 ``` In this example, you'll create a function named `function1` inside the `subfolder` subfolder inside component `function1`. The command will create any subfolders you need to make your function path valid. ``` serverless function create ``` In this example, you did not provide a function path. This will only work if you're running the command from within a component root. In that case you'll be prompted to choose a function name, after that a function with the chosen name will be created in the component you're in. [block:callout] { "type": "info", "body": "Depending on whether the runtime of the component you chose for your function is `nodejs` or `python2.7`, the framework will generate the function handler file accordingly. In case of `nodejs` you'll have `handler.js`, in case of `python2.7`, you'll have `handler.py`.", "title": "Generated Function Runtime" } [/block]
``` serverless function create ``` **Must be run inside a Serverless Project.** It generates a basic scaffolding for a new Function inside an existing Component within your project. This command takes the following parameters: * `functionPath` The path of the function you want to create. The function path should start from the component you want to create a function for. ### Examples ``` serverless function create component1/function1 ``` In this example, you'll create a function named `function1` inside your `component1` component. ``` serverless function create component1/subfolder/function1 ``` In this example, you'll create a function named `function1` inside the `subfolder` subfolder inside component `function1`. The command will create any subfolders you need to make your function path valid. ``` serverless function create ``` In this example, you did not provide a function path. This will only work if you're running the command from within a component root. In that case you'll be prompted to choose a function name, after that a function with the chosen name will be created in the component you're in. [block:callout] { "type": "info", "body": "Depending on whether the runtime of the component you chose for your function is `nodejs` or `python2.7`, the framework will generate the function handler file accordingly. In case of `nodejs` you'll have `handler.js`, in case of `python2.7`, you'll have `handler.py`.", "title": "Generated Function Runtime" } [/block]
{"_id":"56bacbe74aa5930d00da77e9","body":"```\nserverless function run\n```\n**Must be run inside a Serverless Project.** It runs your local or deployed function for testing using the `event.json` as a sample event. This command takes the following **parameters**:\n\n* function path (parameter): The relative path of the function you want to run in this format: `<componantName>/<subFolder>/<functionName>`\n* `-s <stage>` The stage you want to run your deployed function. If not provided, the Function will be run locally.\n* `-r <region>`The region you want to run your deployed function. Optional if your Stage has only one region.\n* `-l <BOOLEAN>` Show the log output. Optional.\n* `-i, <invocationType>` AWS lambda [InvocationType](http://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestSyntax). Default value: `RequestResponse`.\n\n### Examples\n\n```\nserverless function run myComponent/subFolder/myFunction\n```\nIn this example, you'll locally run `myFunction` Function which is inside the \"subFolder\" folder inside the \"myComponent\" Component.\n\n```\nserverless function run myComponent/subFolder/myFunction -s dev\n```\nIn this example, you'll run the **deployed** `myFunction` Function.","title":"Function Run","user":"562120887c515c0d008eee9b","version":"56bacbe64aa5930d00da77d8","__v":2,"order":11,"hidden":false,"project":"5611c207f2aeda0d002b3734","sync_unique":"","type":"basic","category":"56bacbe74aa5930d00da77da","createdAt":"2015-12-02T14:18:30.694Z","githubsync":"","link_external":false,"link_url":"","slug":"function-run","updates":["56a8db6270a9440d00ef5fe2","56bdab94d1fb1323003fdaa1"],"api":{"settings":"","url":"","auth":"required","params":[],"results":{"codes":[{"name":"","status":200,"language":"json","code":"{}"},{"language":"json","code":"{}","name":"","status":400}]}},"excerpt":"Runs your local or deployed function for testing.","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Function Run

Runs your local or deployed function for testing.

``` serverless function run ``` **Must be run inside a Serverless Project.** It runs your local or deployed function for testing using the `event.json` as a sample event. This command takes the following **parameters**: * function path (parameter): The relative path of the function you want to run in this format: `<componantName>/<subFolder>/<functionName>` * `-s <stage>` The stage you want to run your deployed function. If not provided, the Function will be run locally. * `-r <region>`The region you want to run your deployed function. Optional if your Stage has only one region. * `-l <BOOLEAN>` Show the log output. Optional. * `-i, <invocationType>` AWS lambda [InvocationType](http://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestSyntax). Default value: `RequestResponse`. ### Examples ``` serverless function run myComponent/subFolder/myFunction ``` In this example, you'll locally run `myFunction` Function which is inside the "subFolder" folder inside the "myComponent" Component. ``` serverless function run myComponent/subFolder/myFunction -s dev ``` In this example, you'll run the **deployed** `myFunction` Function.
``` serverless function run ``` **Must be run inside a Serverless Project.** It runs your local or deployed function for testing using the `event.json` as a sample event. This command takes the following **parameters**: * function path (parameter): The relative path of the function you want to run in this format: `<componantName>/<subFolder>/<functionName>` * `-s <stage>` The stage you want to run your deployed function. If not provided, the Function will be run locally. * `-r <region>`The region you want to run your deployed function. Optional if your Stage has only one region. * `-l <BOOLEAN>` Show the log output. Optional. * `-i, <invocationType>` AWS lambda [InvocationType](http://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestSyntax). Default value: `RequestResponse`. ### Examples ``` serverless function run myComponent/subFolder/myFunction ``` In this example, you'll locally run `myFunction` Function which is inside the "subFolder" folder inside the "myComponent" Component. ``` serverless function run myComponent/subFolder/myFunction -s dev ``` In this example, you'll run the **deployed** `myFunction` Function.
{"_id":"56bb2a5368be933500aeea3f","user":"562120887c515c0d008eee9b","version":"56bacbe64aa5930d00da77d8","hidden":false,"title":"Function Logs","__v":1,"excerpt":"Fetches lambda function logs from CloudWatch","body":"```\nserverless function logs\n```\n**Must be run inside a Serverless Project.** It fetches the lambda function logs from CloudWatch. This command takes the following options and parameters:\n​\n* function path (parameter): The path of the function you want to get logs from relative to the component root. If you're running this command from the project root, you have to provide the function path.\n* `-s <stage>` The stage you want to get function logs from. Optional if your Project has only one stage.\n* `-r <region>` Optional - The AWS region you want to get function logs from. Optional if your Stage has only one region.\n* `-t <BOOLEAN>` Optional - Tail the log output. Default is false.\n* `-d <STRING>` Optional - The duration of time in which the log history is shown. Example values: `10m`, `2h`, `1d`, `10minutes`, `1day`.  Default: `5m`.\n* `-f <STRING>` Optional - A log filter pattern.\n* `-i <NUMBER>` Optional - Tail polling interval in milliseconds. Default: `1000`.\n​\n### Examples\n```\nserverless function logs\n```\nIf you don't provide a Function path like in this example, the command will behave depending on where in your Project you're running it. If you're running outside of a function directory, it'll throw an error, if you're running in a Function, you'll get this Function logs.\n​\n```\nserverless function logs myComponent/subfolder/myFunction -s production -r us-east-1\n```\nIn this example, you'll get the \"myFunction\" logs. \n​\n```\nserverless function logs myComponent/subfolder/myFunction -s production -r us-east-1 -t -d 24h -f error\n​\n```\nIn this example, you'll get the \"myFunction\" logs which has a `error` substring for the last 24 hours and will get new logs until you stop the command execution.","createdAt":"2016-02-10T12:17:23.630Z","githubsync":"","link_external":false,"sync_unique":"","api":{"url":"","auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":""},"order":12,"project":"5611c207f2aeda0d002b3734","slug":"function-logs","type":"basic","updates":[],"category":"56bacbe74aa5930d00da77da","link_url":"","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Function Logs

Fetches lambda function logs from CloudWatch

``` serverless function logs ``` **Must be run inside a Serverless Project.** It fetches the lambda function logs from CloudWatch. This command takes the following options and parameters: ​ * function path (parameter): The path of the function you want to get logs from relative to the component root. If you're running this command from the project root, you have to provide the function path. * `-s <stage>` The stage you want to get function logs from. Optional if your Project has only one stage. * `-r <region>` Optional - The AWS region you want to get function logs from. Optional if your Stage has only one region. * `-t <BOOLEAN>` Optional - Tail the log output. Default is false. * `-d <STRING>` Optional - The duration of time in which the log history is shown. Example values: `10m`, `2h`, `1d`, `10minutes`, `1day`. Default: `5m`. * `-f <STRING>` Optional - A log filter pattern. * `-i <NUMBER>` Optional - Tail polling interval in milliseconds. Default: `1000`. ​ ### Examples ``` serverless function logs ``` If you don't provide a Function path like in this example, the command will behave depending on where in your Project you're running it. If you're running outside of a function directory, it'll throw an error, if you're running in a Function, you'll get this Function logs. ​ ``` serverless function logs myComponent/subfolder/myFunction -s production -r us-east-1 ``` In this example, you'll get the "myFunction" logs. ​ ``` serverless function logs myComponent/subfolder/myFunction -s production -r us-east-1 -t -d 24h -f error ​ ``` In this example, you'll get the "myFunction" logs which has a `error` substring for the last 24 hours and will get new logs until you stop the command execution.
``` serverless function logs ``` **Must be run inside a Serverless Project.** It fetches the lambda function logs from CloudWatch. This command takes the following options and parameters: ​ * function path (parameter): The path of the function you want to get logs from relative to the component root. If you're running this command from the project root, you have to provide the function path. * `-s <stage>` The stage you want to get function logs from. Optional if your Project has only one stage. * `-r <region>` Optional - The AWS region you want to get function logs from. Optional if your Stage has only one region. * `-t <BOOLEAN>` Optional - Tail the log output. Default is false. * `-d <STRING>` Optional - The duration of time in which the log history is shown. Example values: `10m`, `2h`, `1d`, `10minutes`, `1day`. Default: `5m`. * `-f <STRING>` Optional - A log filter pattern. * `-i <NUMBER>` Optional - Tail polling interval in milliseconds. Default: `1000`. ​ ### Examples ``` serverless function logs ``` If you don't provide a Function path like in this example, the command will behave depending on where in your Project you're running it. If you're running outside of a function directory, it'll throw an error, if you're running in a Function, you'll get this Function logs. ​ ``` serverless function logs myComponent/subfolder/myFunction -s production -r us-east-1 ``` In this example, you'll get the "myFunction" logs. ​ ``` serverless function logs myComponent/subfolder/myFunction -s production -r us-east-1 -t -d 24h -f error ​ ``` In this example, you'll get the "myFunction" logs which has a `error` substring for the last 24 hours and will get new logs until you stop the command execution.
{"_id":"56bacbe74aa5930d00da77ea","order":13,"link_external":false,"type":"basic","updates":["569e3f620306a10d00ce9aca"],"user":"562120887c515c0d008eee9b","version":"56bacbe64aa5930d00da77d8","title":"Function Deploy","api":{"auth":"required","params":[],"results":{"codes":[{"code":"{}","name":"","status":200,"language":"json"},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"body":"```\nserverless function deploy\n```\n**Must be run inside a Serverless Project.** It deploys your Function to AWS. This command takes the following options and parameters:\n\n* function path (parameter): The path of the function you want to deploy relative to the component root. If not provided it'll deploy all functions in the Component or its subfolder depending on the CWD you're running the command from. If you're running this command from the project root, you have to provide the function path.\n* `-s <stage>` The stage you want to deploy your Function to. Optional if your Project has only one stage.\n* `-r <region>` Optional - The AWS region you want to deploy your Function to. If not provided, the Function will be deployed to **all** the regions defined in your chosen stage by default.\n* `-f <alias>` Optional - Sets an alias for your Function.\n* `-a <all>` Optional - Deploy all your Functions.\n\n### Examples\n```\nserverless function deploy\n```\nIf you don't provide a Function path like in this example, the command will behave depending on where in your Project you're running it. If you're running in your project root directory, it'll throw an error, if you're running in a Component, it'll only deploy all the functions inside that Component, if you're running in a subfolder inside a Component, it'll only deploy all the functions inside that subfolder, if you're running in a Function, you'll deploy only this Function.\n\n```\nserverless function deploy myComponent/subfolder/myFunction -s production -r us-east-1\n```\nIn this example, you'll instantly deploy the \"myFunction\" Function, which is inside the \"subfolder\" subfolder, inside the \"myComponent\" Component. The Function will be deployed to the `us-east-1` region in the `production` stage.\n\n```\nserverless function deploy myComponent/myModule/myFunction -f myAlias\n```\nIn this example, you'll be prompted to choose a stage if your project has more than one stage. After that, the command will deploy the Function with the provided path to all regions defined in the chosen stage while setting an alias `myAlias` to your Function.\n\n```\nserverless function deploy myComponent/myFunction myComponent/subfolder/myOtherFunction\n```\nIn this example, you'll deploy the **two** functions `myFunction` and `myOtherFunction` because you provided two Funciton paths. But first you'll be prompted to choose a stage if your Project has more than one stage, after that deployment to all regions in that stage will begin.","category":"56bacbe74aa5930d00da77da","createdAt":"2015-12-02T14:18:59.133Z","githubsync":"","hidden":false,"project":"5611c207f2aeda0d002b3734","__v":1,"excerpt":"Deploys your function to AWS.","link_url":"","slug":"function-deploy","sync_unique":"","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Function Deploy

Deploys your function to AWS.

``` serverless function deploy ``` **Must be run inside a Serverless Project.** It deploys your Function to AWS. This command takes the following options and parameters: * function path (parameter): The path of the function you want to deploy relative to the component root. If not provided it'll deploy all functions in the Component or its subfolder depending on the CWD you're running the command from. If you're running this command from the project root, you have to provide the function path. * `-s <stage>` The stage you want to deploy your Function to. Optional if your Project has only one stage. * `-r <region>` Optional - The AWS region you want to deploy your Function to. If not provided, the Function will be deployed to **all** the regions defined in your chosen stage by default. * `-f <alias>` Optional - Sets an alias for your Function. * `-a <all>` Optional - Deploy all your Functions. ### Examples ``` serverless function deploy ``` If you don't provide a Function path like in this example, the command will behave depending on where in your Project you're running it. If you're running in your project root directory, it'll throw an error, if you're running in a Component, it'll only deploy all the functions inside that Component, if you're running in a subfolder inside a Component, it'll only deploy all the functions inside that subfolder, if you're running in a Function, you'll deploy only this Function. ``` serverless function deploy myComponent/subfolder/myFunction -s production -r us-east-1 ``` In this example, you'll instantly deploy the "myFunction" Function, which is inside the "subfolder" subfolder, inside the "myComponent" Component. The Function will be deployed to the `us-east-1` region in the `production` stage. ``` serverless function deploy myComponent/myModule/myFunction -f myAlias ``` In this example, you'll be prompted to choose a stage if your project has more than one stage. After that, the command will deploy the Function with the provided path to all regions defined in the chosen stage while setting an alias `myAlias` to your Function. ``` serverless function deploy myComponent/myFunction myComponent/subfolder/myOtherFunction ``` In this example, you'll deploy the **two** functions `myFunction` and `myOtherFunction` because you provided two Funciton paths. But first you'll be prompted to choose a stage if your Project has more than one stage, after that deployment to all regions in that stage will begin.
``` serverless function deploy ``` **Must be run inside a Serverless Project.** It deploys your Function to AWS. This command takes the following options and parameters: * function path (parameter): The path of the function you want to deploy relative to the component root. If not provided it'll deploy all functions in the Component or its subfolder depending on the CWD you're running the command from. If you're running this command from the project root, you have to provide the function path. * `-s <stage>` The stage you want to deploy your Function to. Optional if your Project has only one stage. * `-r <region>` Optional - The AWS region you want to deploy your Function to. If not provided, the Function will be deployed to **all** the regions defined in your chosen stage by default. * `-f <alias>` Optional - Sets an alias for your Function. * `-a <all>` Optional - Deploy all your Functions. ### Examples ``` serverless function deploy ``` If you don't provide a Function path like in this example, the command will behave depending on where in your Project you're running it. If you're running in your project root directory, it'll throw an error, if you're running in a Component, it'll only deploy all the functions inside that Component, if you're running in a subfolder inside a Component, it'll only deploy all the functions inside that subfolder, if you're running in a Function, you'll deploy only this Function. ``` serverless function deploy myComponent/subfolder/myFunction -s production -r us-east-1 ``` In this example, you'll instantly deploy the "myFunction" Function, which is inside the "subfolder" subfolder, inside the "myComponent" Component. The Function will be deployed to the `us-east-1` region in the `production` stage. ``` serverless function deploy myComponent/myModule/myFunction -f myAlias ``` In this example, you'll be prompted to choose a stage if your project has more than one stage. After that, the command will deploy the Function with the provided path to all regions defined in the chosen stage while setting an alias `myAlias` to your Function. ``` serverless function deploy myComponent/myFunction myComponent/subfolder/myOtherFunction ``` In this example, you'll deploy the **two** functions `myFunction` and `myOtherFunction` because you provided two Funciton paths. But first you'll be prompted to choose a stage if your Project has more than one stage, after that deployment to all regions in that stage will begin.
{"_id":"56bacbe74aa5930d00da77eb","link_external":false,"title":"Endpoint Deploy","version":"56bacbe64aa5930d00da77d8","createdAt":"2015-12-08T17:23:09.211Z","githubsync":"","order":14,"slug":"endpoint-deploy","user":"562120887c515c0d008eee9b","__v":1,"body":"```\nserverless endpoint deploy\n```\n**Must be run inside a Serverless Project.** It deploys your endpoints to AWS. This command takes the following options and parameters:\n\n* endpoint path (parameter): The relative path of the endpoint you want to deploy in this format: `<functionPath>@<endpointUrl>~<endpointMethod>`. If not provided it'll deploy all endpoints in the Component or its subfolder depending on the CWD you're running the command from. If you're running this command from the project root, you have to provide the endpoint path.\n* `-s <stage>` The stage you want to deploy your endpoint to. Optional if your project has only one stage.\n* `-r <region>` Optional - The AWS region you want to deploy your endpoint to. If not provided, the endpoint will be deployed to **all** the region defined in your chosen stage by default.\n\n### Examples\n```\nserverless endpoint deploy\n```\nIf you don't provide an Endpoint path like in this example, the command will behave depending on where in your Project you're running it. If you're running in your project root directory, it'll throw an error, if you're running in a Component, it'll only deploy all the endpoints inside that Component, if you're running in a subfolder inside a Component, it'll only deploy all the endpoints inside that subfolder, if you're running in a Function, you'll deploy only the endpoints of that function.\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"Deploy Functions Before Endpoints\",\n  \"body\": \"If you try to deploy an endpoint that points to a lambda functions that **wasn't yet deployed**, you'll get an error message from AWS. Once you deploy your Function at least once, you're free to deploy its endpoints anytime.\"\n}\n[/block]\n```\nserverless endpoint deploy myComponent/subfolder/[email protected]/create~POST -s production -r us-east-1\n```\nIn this example, you'll instantly deploy the endpoint `users/create` that has a method of `POST` and points to the Function `myFunction`, which is inside `subfolder` subfolder inside `myComponent` Component. The endpoint will be deployed to the `us-east-1` region in the `production` stage.\n\n```\nserverless endpoint deploy myComponent/[email protected]/create~POST myComponent/subfolder/[email protected]/list~GET\n```\nIn this example, you'll deploy the **two** endpoints `users/create` and `users/list` because you provided two endpoint paths. But first you'll be prompted to choose a stage if your Project has more than one stage, after that deployment to all regions in that stage will begin.\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"It's Complex but Super Flexible\",\n  \"body\": \"Each Component has a number of functions in its root or in subfolder, and each Function has a number of endpoints, and each endpoint has a number of methods. This makes deployment super flexible, but it also makes the command a bit complex. You can always use the `sls dash deploy` command for a simple interactive CLI deployment dashboard.\"\n}\n[/block]","excerpt":"Deploys an Endpoint to AWS API Gateway.","hidden":false,"project":"5611c207f2aeda0d002b3734","type":"basic","api":{"params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":"","auth":"required"},"category":"56bacbe74aa5930d00da77da","link_url":"","sync_unique":"","updates":[],"metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Endpoint Deploy

Deploys an Endpoint to AWS API Gateway.

``` serverless endpoint deploy ``` **Must be run inside a Serverless Project.** It deploys your endpoints to AWS. This command takes the following options and parameters: * endpoint path (parameter): The relative path of the endpoint you want to deploy in this format: `<functionPath>@<endpointUrl>~<endpointMethod>`. If not provided it'll deploy all endpoints in the Component or its subfolder depending on the CWD you're running the command from. If you're running this command from the project root, you have to provide the endpoint path. * `-s <stage>` The stage you want to deploy your endpoint to. Optional if your project has only one stage. * `-r <region>` Optional - The AWS region you want to deploy your endpoint to. If not provided, the endpoint will be deployed to **all** the region defined in your chosen stage by default. ### Examples ``` serverless endpoint deploy ``` If you don't provide an Endpoint path like in this example, the command will behave depending on where in your Project you're running it. If you're running in your project root directory, it'll throw an error, if you're running in a Component, it'll only deploy all the endpoints inside that Component, if you're running in a subfolder inside a Component, it'll only deploy all the endpoints inside that subfolder, if you're running in a Function, you'll deploy only the endpoints of that function. [block:callout] { "type": "warning", "title": "Deploy Functions Before Endpoints", "body": "If you try to deploy an endpoint that points to a lambda functions that **wasn't yet deployed**, you'll get an error message from AWS. Once you deploy your Function at least once, you're free to deploy its endpoints anytime." } [/block] ``` serverless endpoint deploy myComponent/subfolder/[email protected]/create~POST -s production -r us-east-1 ``` In this example, you'll instantly deploy the endpoint `users/create` that has a method of `POST` and points to the Function `myFunction`, which is inside `subfolder` subfolder inside `myComponent` Component. The endpoint will be deployed to the `us-east-1` region in the `production` stage. ``` serverless endpoint deploy myComponent/[email protected]/create~POST myComponent/subfolder/[email protected]/list~GET ``` In this example, you'll deploy the **two** endpoints `users/create` and `users/list` because you provided two endpoint paths. But first you'll be prompted to choose a stage if your Project has more than one stage, after that deployment to all regions in that stage will begin. [block:callout] { "type": "info", "title": "It's Complex but Super Flexible", "body": "Each Component has a number of functions in its root or in subfolder, and each Function has a number of endpoints, and each endpoint has a number of methods. This makes deployment super flexible, but it also makes the command a bit complex. You can always use the `sls dash deploy` command for a simple interactive CLI deployment dashboard." } [/block]
``` serverless endpoint deploy ``` **Must be run inside a Serverless Project.** It deploys your endpoints to AWS. This command takes the following options and parameters: * endpoint path (parameter): The relative path of the endpoint you want to deploy in this format: `<functionPath>@<endpointUrl>~<endpointMethod>`. If not provided it'll deploy all endpoints in the Component or its subfolder depending on the CWD you're running the command from. If you're running this command from the project root, you have to provide the endpoint path. * `-s <stage>` The stage you want to deploy your endpoint to. Optional if your project has only one stage. * `-r <region>` Optional - The AWS region you want to deploy your endpoint to. If not provided, the endpoint will be deployed to **all** the region defined in your chosen stage by default. ### Examples ``` serverless endpoint deploy ``` If you don't provide an Endpoint path like in this example, the command will behave depending on where in your Project you're running it. If you're running in your project root directory, it'll throw an error, if you're running in a Component, it'll only deploy all the endpoints inside that Component, if you're running in a subfolder inside a Component, it'll only deploy all the endpoints inside that subfolder, if you're running in a Function, you'll deploy only the endpoints of that function. [block:callout] { "type": "warning", "title": "Deploy Functions Before Endpoints", "body": "If you try to deploy an endpoint that points to a lambda functions that **wasn't yet deployed**, you'll get an error message from AWS. Once you deploy your Function at least once, you're free to deploy its endpoints anytime." } [/block] ``` serverless endpoint deploy myComponent/subfolder/[email protected]/create~POST -s production -r us-east-1 ``` In this example, you'll instantly deploy the endpoint `users/create` that has a method of `POST` and points to the Function `myFunction`, which is inside `subfolder` subfolder inside `myComponent` Component. The endpoint will be deployed to the `us-east-1` region in the `production` stage. ``` serverless endpoint deploy myComponent/[email protected]/create~POST myComponent/subfolder/[email protected]/list~GET ``` In this example, you'll deploy the **two** endpoints `users/create` and `users/list` because you provided two endpoint paths. But first you'll be prompted to choose a stage if your Project has more than one stage, after that deployment to all regions in that stage will begin. [block:callout] { "type": "info", "title": "It's Complex but Super Flexible", "body": "Each Component has a number of functions in its root or in subfolder, and each Function has a number of endpoints, and each endpoint has a number of methods. This makes deployment super flexible, but it also makes the command a bit complex. You can always use the `sls dash deploy` command for a simple interactive CLI deployment dashboard." } [/block]
{"_id":"56bb098dfb70442b003683f4","githubsync":"","slug":"event-deploy","updates":[],"user":"562120887c515c0d008eee9b","__v":3,"category":"56bacbe74aa5930d00da77da","createdAt":"2016-02-10T09:57:33.026Z","link_url":"","order":15,"sync_unique":"","version":"56bacbe64aa5930d00da77d8","body":"```\nserverless event deploy\n```\n**Must be run inside a Serverless Project.** It deploys your events to AWS. This command takes the following options and parameters:\n\n* event path (parameter): The relative path of the event you want to deploy in this format: `<functionPath>#<eventName>`. If not provided it'll deploy all events in the Component or its subfolder depending on the CWD you're running the command from. If you're running this command from the project root, you have to provide the event path.\n* `-s <stage>` The stage you want to deploy your event to. Optional if your project has only one stage.\n* `-r <region>` Optional - The AWS region you want to deploy your event to. If not provided, the endpoint will be deployed to **all** the region defined in your chosen stage by default.\n[block:callout]\n{\n  \"type\": \"danger\",\n  \"title\": \"Event Sources Permissions\",\n  \"body\": \"For event sources that are following the **push model** (S3, SNS & Schedule), we create all the required permissions to invoke the lambda for you, so deploying will work right away out of the box. But for the event sources that are following the **pull model** (DynamoDB & Kinesis Streams), you have to give your lambda function permission to access DynamoDB/Kinesis before deploying the event, otherwise deployment will fail.\"\n}\n[/block]\n### Examples\n```\nserverless event deploy\n```\nIf you don't provide an event path like in this example, the command will behave depending on where in your Project you're running it. If you're running in your project root directory, it'll throw an error, if you're running in a Component, it'll only deploy all the events inside that Component, if you're running in a subfolder inside a Component, it'll only deploy all the events inside that subfolder, if you're running in a Function, you'll deploy only the events of that function.\n\n```\nserverless event deploy myComponent/subfolder/myFunction#myEvent -s production -r us-east-1\n```\nIn this example, you'll instantly deploy the event named `myEvent` that is in the Function `myFunction`, which is inside `subfolder` subfolder inside `myComponent` Component. The event will be deployed to the `us-east-1` region in the `production` stage.\n\n```\nserverless event deploy myComponent/myFunction#myEvent myComponent/subfolder/myOtherFunction#myOtherEvent\n```\nIn this example, you'll deploy the **two** events `myEvent` and `myOtherEvent` because you provided two event paths. But first you'll be prompted to choose a stage if your Project has more than one stage, after that deployment to all regions in that stage will begin.","title":"Event Deploy","api":{"settings":"","url":"","auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"code":"{}","name":"","status":400,"language":"json"}]}},"hidden":false,"link_external":false,"project":"5611c207f2aeda0d002b3734","type":"basic","excerpt":"Deploys event sources for your lambda.","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Event Deploy

Deploys event sources for your lambda.

``` serverless event deploy ``` **Must be run inside a Serverless Project.** It deploys your events to AWS. This command takes the following options and parameters: * event path (parameter): The relative path of the event you want to deploy in this format: `<functionPath>#<eventName>`. If not provided it'll deploy all events in the Component or its subfolder depending on the CWD you're running the command from. If you're running this command from the project root, you have to provide the event path. * `-s <stage>` The stage you want to deploy your event to. Optional if your project has only one stage. * `-r <region>` Optional - The AWS region you want to deploy your event to. If not provided, the endpoint will be deployed to **all** the region defined in your chosen stage by default. [block:callout] { "type": "danger", "title": "Event Sources Permissions", "body": "For event sources that are following the **push model** (S3, SNS & Schedule), we create all the required permissions to invoke the lambda for you, so deploying will work right away out of the box. But for the event sources that are following the **pull model** (DynamoDB & Kinesis Streams), you have to give your lambda function permission to access DynamoDB/Kinesis before deploying the event, otherwise deployment will fail." } [/block] ### Examples ``` serverless event deploy ``` If you don't provide an event path like in this example, the command will behave depending on where in your Project you're running it. If you're running in your project root directory, it'll throw an error, if you're running in a Component, it'll only deploy all the events inside that Component, if you're running in a subfolder inside a Component, it'll only deploy all the events inside that subfolder, if you're running in a Function, you'll deploy only the events of that function. ``` serverless event deploy myComponent/subfolder/myFunction#myEvent -s production -r us-east-1 ``` In this example, you'll instantly deploy the event named `myEvent` that is in the Function `myFunction`, which is inside `subfolder` subfolder inside `myComponent` Component. The event will be deployed to the `us-east-1` region in the `production` stage. ``` serverless event deploy myComponent/myFunction#myEvent myComponent/subfolder/myOtherFunction#myOtherEvent ``` In this example, you'll deploy the **two** events `myEvent` and `myOtherEvent` because you provided two event paths. But first you'll be prompted to choose a stage if your Project has more than one stage, after that deployment to all regions in that stage will begin.
``` serverless event deploy ``` **Must be run inside a Serverless Project.** It deploys your events to AWS. This command takes the following options and parameters: * event path (parameter): The relative path of the event you want to deploy in this format: `<functionPath>#<eventName>`. If not provided it'll deploy all events in the Component or its subfolder depending on the CWD you're running the command from. If you're running this command from the project root, you have to provide the event path. * `-s <stage>` The stage you want to deploy your event to. Optional if your project has only one stage. * `-r <region>` Optional - The AWS region you want to deploy your event to. If not provided, the endpoint will be deployed to **all** the region defined in your chosen stage by default. [block:callout] { "type": "danger", "title": "Event Sources Permissions", "body": "For event sources that are following the **push model** (S3, SNS & Schedule), we create all the required permissions to invoke the lambda for you, so deploying will work right away out of the box. But for the event sources that are following the **pull model** (DynamoDB & Kinesis Streams), you have to give your lambda function permission to access DynamoDB/Kinesis before deploying the event, otherwise deployment will fail." } [/block] ### Examples ``` serverless event deploy ``` If you don't provide an event path like in this example, the command will behave depending on where in your Project you're running it. If you're running in your project root directory, it'll throw an error, if you're running in a Component, it'll only deploy all the events inside that Component, if you're running in a subfolder inside a Component, it'll only deploy all the events inside that subfolder, if you're running in a Function, you'll deploy only the events of that function. ``` serverless event deploy myComponent/subfolder/myFunction#myEvent -s production -r us-east-1 ``` In this example, you'll instantly deploy the event named `myEvent` that is in the Function `myFunction`, which is inside `subfolder` subfolder inside `myComponent` Component. The event will be deployed to the `us-east-1` region in the `production` stage. ``` serverless event deploy myComponent/myFunction#myEvent myComponent/subfolder/myOtherFunction#myOtherEvent ``` In this example, you'll deploy the **two** events `myEvent` and `myOtherEvent` because you provided two event paths. But first you'll be prompted to choose a stage if your Project has more than one stage, after that deployment to all regions in that stage will begin.
{"_id":"56bacbe74aa5930d00da77ec","title":"Dash Deploy","type":"basic","user":"562120887c515c0d008eee9b","__v":1,"githubsync":"","link_external":false,"category":"56bacbe74aa5930d00da77da","excerpt":"Prompts the deployment dashboard for functions and endpoints.","createdAt":"2015-12-21T10:20:27.764Z","project":"5611c207f2aeda0d002b3734","slug":"dash-deploy","sync_unique":"","api":{"settings":"","url":"","auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"code":"{}","name":"","status":400,"language":"json"}]}},"body":"```\nserverless dash deploy\n```\n**Must be run inside a Serverless Project.** An interactive CLI dashboard that makes it easy to select and deploy functions and endpoints concurrently. This command is intended to offer great user experience so it can only be used interactively.\n\nThis command will prompt you to choose a stage and region for your deployment, and it'll list all the functions and their endpoints. You just select whatever you want to deploy, and hit `Deploy`. If you run this command in the root directory of your Project, it'll list all functions & endpoints in your Project. if you run it inside a Component, it'll only list the functions & endpoints in that Component, if you run it inside a subfolder inside a component, it'll only list the functions & endpoints inside that subfolder, and if you run it inside a Function, it'll only list the Function & its endpoints.","updates":[],"version":"56bacbe64aa5930d00da77d8","hidden":false,"link_url":"","order":16,"metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Dash Deploy

Prompts the deployment dashboard for functions and endpoints.

``` serverless dash deploy ``` **Must be run inside a Serverless Project.** An interactive CLI dashboard that makes it easy to select and deploy functions and endpoints concurrently. This command is intended to offer great user experience so it can only be used interactively. This command will prompt you to choose a stage and region for your deployment, and it'll list all the functions and their endpoints. You just select whatever you want to deploy, and hit `Deploy`. If you run this command in the root directory of your Project, it'll list all functions & endpoints in your Project. if you run it inside a Component, it'll only list the functions & endpoints in that Component, if you run it inside a subfolder inside a component, it'll only list the functions & endpoints inside that subfolder, and if you run it inside a Function, it'll only list the Function & its endpoints.
``` serverless dash deploy ``` **Must be run inside a Serverless Project.** An interactive CLI dashboard that makes it easy to select and deploy functions and endpoints concurrently. This command is intended to offer great user experience so it can only be used interactively. This command will prompt you to choose a stage and region for your deployment, and it'll list all the functions and their endpoints. You just select whatever you want to deploy, and hit `Deploy`. If you run this command in the root directory of your Project, it'll list all functions & endpoints in your Project. if you run it inside a Component, it'll only list the functions & endpoints in that Component, if you run it inside a subfolder inside a component, it'll only list the functions & endpoints inside that subfolder, and if you run it inside a Function, it'll only list the Function & its endpoints.
{"_id":"56bacbe74aa5930d00da77ed","__v":1,"category":"56bacbe74aa5930d00da77da","link_external":false,"order":17,"createdAt":"2016-02-03T04:33:08.572Z","excerpt":"Displays a summary of your Serverless Project state.","slug":"dash-summary","title":"Dash Summary","version":"56bacbe64aa5930d00da77d8","api":{"params":[],"results":{"codes":[{"name":"","code":"{}","language":"json","status":200},{"language":"json","status":400,"name":"","code":"{}"}]},"settings":"","url":"","auth":"required"},"body":"```\nserverless dash summary\n```\n**Must be run inside a Serverless project.** It displays a summary of your Serverless project state, number of stages, regions, components, functions and endpoints. This simple command doesn't take any options or parameters.","githubsync":"","sync_unique":"","type":"basic","user":"562120887c515c0d008eee9b","hidden":false,"link_url":"","project":"5611c207f2aeda0d002b3734","updates":[],"metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Dash Summary

Displays a summary of your Serverless Project state.

``` serverless dash summary ``` **Must be run inside a Serverless project.** It displays a summary of your Serverless project state, number of stages, regions, components, functions and endpoints. This simple command doesn't take any options or parameters.
``` serverless dash summary ``` **Must be run inside a Serverless project.** It displays a summary of your Serverless project state, number of stages, regions, components, functions and endpoints. This simple command doesn't take any options or parameters.
{"_id":"56bacbe74aa5930d00da77ee","project":"5611c207f2aeda0d002b3734","type":"basic","user":"562120887c515c0d008eee9b","api":{"auth":"required","params":[],"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","url":""},"githubsync":"","hidden":false,"link_external":false,"order":18,"createdAt":"2015-12-02T14:20:47.117Z","slug":"resources-deploy","updates":["56c50bebd1b8770d00922287"],"title":"Resources Deploy","link_url":"","sync_unique":"","version":"56bacbe64aa5930d00da77d8","__v":6,"body":"```\nserverless resources deploy\n```\n**Must be run inside a Serverless Project.** It updates your AWS resources by collecting all the resources defined in your `project/s-resources-cf.json` file as well as any `s-resources-cf.json` files located in the root of your components as well as any subfolders within those components, and populating all the referenced templates and variables. It takes the following options:\n\n* `-s <stage>` the stage you want to deploy resources to\n* `-r <region>` the region in your chosen stage you want to deploy resources to\n* `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**.\n\n### Examples\n```\nserverless resources deploy\n```\nIn this example, you'll be prompted to choose a stage and region to deploy your resources to. After that it'll deploy the resources to the chosen stage and region.\n\n```\nserverless resources deploy -s dev -r us-east-1\n```\nIn this example, you'll instantly deploy your resources to the `us-east-1` region in the `dev` stage.\n\n```\nserverless resources deploy -c -s dev -r us-east-1\n```\nIn this example, you won't deploy the CF template file to AWS. It'll only generate a CF template file called `s-resources-cf-dev-useast1.json` inside the `_meta/resources` folder. You'll have to upload this file manually using the AWS console to deploy your resources.","category":"56bacbe74aa5930d00da77da","excerpt":"Deploys all your project's and modules's CloudFormation resources.","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Resources Deploy

Deploys all your project's and modules's CloudFormation resources.

``` serverless resources deploy ``` **Must be run inside a Serverless Project.** It updates your AWS resources by collecting all the resources defined in your `project/s-resources-cf.json` file as well as any `s-resources-cf.json` files located in the root of your components as well as any subfolders within those components, and populating all the referenced templates and variables. It takes the following options: * `-s <stage>` the stage you want to deploy resources to * `-r <region>` the region in your chosen stage you want to deploy resources to * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. ### Examples ``` serverless resources deploy ``` In this example, you'll be prompted to choose a stage and region to deploy your resources to. After that it'll deploy the resources to the chosen stage and region. ``` serverless resources deploy -s dev -r us-east-1 ``` In this example, you'll instantly deploy your resources to the `us-east-1` region in the `dev` stage. ``` serverless resources deploy -c -s dev -r us-east-1 ``` In this example, you won't deploy the CF template file to AWS. It'll only generate a CF template file called `s-resources-cf-dev-useast1.json` inside the `_meta/resources` folder. You'll have to upload this file manually using the AWS console to deploy your resources.
``` serverless resources deploy ``` **Must be run inside a Serverless Project.** It updates your AWS resources by collecting all the resources defined in your `project/s-resources-cf.json` file as well as any `s-resources-cf.json` files located in the root of your components as well as any subfolders within those components, and populating all the referenced templates and variables. It takes the following options: * `-s <stage>` the stage you want to deploy resources to * `-r <region>` the region in your chosen stage you want to deploy resources to * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. ### Examples ``` serverless resources deploy ``` In this example, you'll be prompted to choose a stage and region to deploy your resources to. After that it'll deploy the resources to the chosen stage and region. ``` serverless resources deploy -s dev -r us-east-1 ``` In this example, you'll instantly deploy your resources to the `us-east-1` region in the `dev` stage. ``` serverless resources deploy -c -s dev -r us-east-1 ``` In this example, you won't deploy the CF template file to AWS. It'll only generate a CF template file called `s-resources-cf-dev-useast1.json` inside the `_meta/resources` folder. You'll have to upload this file manually using the AWS console to deploy your resources.
{"_id":"56bacbe74aa5930d00da77ef","category":"56bacbe74aa5930d00da77da","excerpt":"Removes CloudFormation resources from a given stage/region in your Serverless Project","link_external":false,"project":"5611c207f2aeda0d002b3734","updates":[],"version":"56bacbe64aa5930d00da77d8","__v":0,"api":{"params":[],"url":"","results":{"codes":[{"name":"","code":"{}","language":"json","status":200},{"name":"","code":"{}","language":"json","status":400}]},"settings":"","auth":"required"},"order":19,"slug":"resources-remove","type":"basic","createdAt":"2016-02-03T03:55:29.312Z","link_url":"","body":"```\nserverless resources remove\n```\n**Must be run within a Serverless Project**. Removes CloudFormation resources from a given stage/region in your Serverless Project. It takes the following options:\n\n* `-s <stage>` the stage that contains the region you want to remove resources from.\n* `-r <region>` the region you want to remove resources from.\n* `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**.\n\n### Examples\n```\nserverless resources remove -s production -r us-west-2\n```\nIn this example, the command will instantly remove CloudFormation resources from the `us-west-2` region in the `production` stage.\n\n```\nserverless resources remove -s production -r us-west-2 -c\n```\nIn this example, you've set the `-c` option to `true`, so the command will only output a CF template in the `_meta/resources` folder that you can execute manually on the AWS console to remove the resources.","hidden":false,"sync_unique":"","title":"Resources Remove","user":"562120887c515c0d008eee9b","githubsync":"","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Resources Remove

Removes CloudFormation resources from a given stage/region in your Serverless Project

``` serverless resources remove ``` **Must be run within a Serverless Project**. Removes CloudFormation resources from a given stage/region in your Serverless Project. It takes the following options: * `-s <stage>` the stage that contains the region you want to remove resources from. * `-r <region>` the region you want to remove resources from. * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. ### Examples ``` serverless resources remove -s production -r us-west-2 ``` In this example, the command will instantly remove CloudFormation resources from the `us-west-2` region in the `production` stage. ``` serverless resources remove -s production -r us-west-2 -c ``` In this example, you've set the `-c` option to `true`, so the command will only output a CF template in the `_meta/resources` folder that you can execute manually on the AWS console to remove the resources.
``` serverless resources remove ``` **Must be run within a Serverless Project**. Removes CloudFormation resources from a given stage/region in your Serverless Project. It takes the following options: * `-s <stage>` the stage that contains the region you want to remove resources from. * `-r <region>` the region you want to remove resources from. * `-c <BOOLEAN>` **Optional** - Doesn't execute CloudFormation if true. Default is **false**. ### Examples ``` serverless resources remove -s production -r us-west-2 ``` In this example, the command will instantly remove CloudFormation resources from the `us-west-2` region in the `production` stage. ``` serverless resources remove -s production -r us-west-2 -c ``` In this example, you've set the `-c` option to `true`, so the command will only output a CF template in the `_meta/resources` folder that you can execute manually on the AWS console to remove the resources.
{"_id":"56bacbe74aa5930d00da77f0","project":"5611c207f2aeda0d002b3734","user":"562120887c515c0d008eee9b","body":"```\nserverless env list\n```\n**Must be run inside a Serverless Project.** It lists all the environment variables in your Project in a specific region in a specific stage. It takes the following options:\n\n* `-s <stage>` The name of the stage you want to list environment variables from. If set to \"local\", you'll list all the environment variable in your local machine.\n* `-r <region>` The name of the region you want to list environment variables from. If set to \"all\", you'll list all the environment variables in all regions in your chosen stage. If the chosen stage is \"local\", then you don't have to provide a region.\n\n### Examples\n```\nserverless env list\n```\nIn this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience.\n\n```\nserverless env list -s production -r us-east-1\n```\nIn this example, you provided all the required options (stage and region). So you'll get a list of all the environment variables in the `us-east-1` region inside the `production` stage. Both the stage and region pair that you provided must exist in your Project, otherwise you'll get an error.\n\n```\nserverless env list -s production -r all\n```\nIn this example, you'll get a list of all the environment variables in all regions in the `production` stage. The `production` stage must exist in your Project, otherwise you'll get an error.\n\n```\nserverless env list -s local\n```\nIn this example, you'll get a list of all the environment variables in your local machine (from the `.env` file in the root directory of your Project). You don't have to specify a `region` in that case.","hidden":false,"link_external":false,"order":20,"title":"Env List","__v":0,"excerpt":"Lists all the environment variables of your project.","githubsync":"","sync_unique":"","updates":[],"category":"56bacbe74aa5930d00da77da","link_url":"","slug":"env-list","type":"basic","version":"56bacbe64aa5930d00da77d8","api":{"params":[],"url":"","results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"code":"{}","name":"","status":400,"language":"json"}]},"settings":"","auth":"required"},"createdAt":"2015-12-02T14:21:34.401Z","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Env List

Lists all the environment variables of your project.

``` serverless env list ``` **Must be run inside a Serverless Project.** It lists all the environment variables in your Project in a specific region in a specific stage. It takes the following options: * `-s <stage>` The name of the stage you want to list environment variables from. If set to "local", you'll list all the environment variable in your local machine. * `-r <region>` The name of the region you want to list environment variables from. If set to "all", you'll list all the environment variables in all regions in your chosen stage. If the chosen stage is "local", then you don't have to provide a region. ### Examples ``` serverless env list ``` In this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience. ``` serverless env list -s production -r us-east-1 ``` In this example, you provided all the required options (stage and region). So you'll get a list of all the environment variables in the `us-east-1` region inside the `production` stage. Both the stage and region pair that you provided must exist in your Project, otherwise you'll get an error. ``` serverless env list -s production -r all ``` In this example, you'll get a list of all the environment variables in all regions in the `production` stage. The `production` stage must exist in your Project, otherwise you'll get an error. ``` serverless env list -s local ``` In this example, you'll get a list of all the environment variables in your local machine (from the `.env` file in the root directory of your Project). You don't have to specify a `region` in that case.
``` serverless env list ``` **Must be run inside a Serverless Project.** It lists all the environment variables in your Project in a specific region in a specific stage. It takes the following options: * `-s <stage>` The name of the stage you want to list environment variables from. If set to "local", you'll list all the environment variable in your local machine. * `-r <region>` The name of the region you want to list environment variables from. If set to "all", you'll list all the environment variables in all regions in your chosen stage. If the chosen stage is "local", then you don't have to provide a region. ### Examples ``` serverless env list ``` In this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience. ``` serverless env list -s production -r us-east-1 ``` In this example, you provided all the required options (stage and region). So you'll get a list of all the environment variables in the `us-east-1` region inside the `production` stage. Both the stage and region pair that you provided must exist in your Project, otherwise you'll get an error. ``` serverless env list -s production -r all ``` In this example, you'll get a list of all the environment variables in all regions in the `production` stage. The `production` stage must exist in your Project, otherwise you'll get an error. ``` serverless env list -s local ``` In this example, you'll get a list of all the environment variables in your local machine (from the `.env` file in the root directory of your Project). You don't have to specify a `region` in that case.
{"_id":"56bacbe74aa5930d00da77f1","type":"basic","api":{"results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"status":400,"language":"json","code":"{}","name":""}]},"settings":"","auth":"required","params":[],"url":""},"excerpt":"Gets the value of a specific environment variable key from a specific region in a specific stage.","link_url":"","project":"5611c207f2aeda0d002b3734","slug":"env-get","title":"Env Get","version":"56bacbe64aa5930d00da77d8","body":"```\nserverless env get\n```\n**Must be run inside a Serverless Project.** It gets the value of a specific environment variable key from a specific region in a specific stage. It takes the following options:\n\n* `-k <key>` The environment variable key you want to get the value for.\n* `-s <stage>` The name of the stage you want to get the value of the environment variable from. If set to \"local\", you'll get the value of the env var from your local machine.\n* `-r <region>` The name of the region you want to get the value of the environment variable from. If set to \"all\", you'll get the value of the env var key in all regions in the chosen stage. If the chosen stage is \"local\", then you don't have to provide a region.\n\n### Examples\n```\nserverless env get\n```\nIn this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience.\n\n```\nserverless env get -k ENV_KEY -s production -r us-east-1\n```\nIn this example, you'll get the value of the environment variable key `ENV_KEY` from the `us-east-1` region in the `production` stage. The stage & region names you provided must exist in your Project.\n\n```\nserverless env get -s production -r all\n```\nIn this example, you'll be prompted to enter the environment variable key because it's not provided as an option. Then you'll get the value of that key in **all** regions in the `production` stage.\n\n```\nserverless env get -k ENV_KEY -s local\n```\nIn this example, you'll get the value of the `ENV_KEY` env var from your local machine. You don't have to provide a region in this case.","createdAt":"2015-12-02T14:22:08.096Z","githubsync":"","link_external":false,"order":21,"category":"56bacbe74aa5930d00da77da","sync_unique":"","user":"562120887c515c0d008eee9b","__v":0,"hidden":false,"updates":[],"metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Env Get

Gets the value of a specific environment variable key from a specific region in a specific stage.

``` serverless env get ``` **Must be run inside a Serverless Project.** It gets the value of a specific environment variable key from a specific region in a specific stage. It takes the following options: * `-k <key>` The environment variable key you want to get the value for. * `-s <stage>` The name of the stage you want to get the value of the environment variable from. If set to "local", you'll get the value of the env var from your local machine. * `-r <region>` The name of the region you want to get the value of the environment variable from. If set to "all", you'll get the value of the env var key in all regions in the chosen stage. If the chosen stage is "local", then you don't have to provide a region. ### Examples ``` serverless env get ``` In this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience. ``` serverless env get -k ENV_KEY -s production -r us-east-1 ``` In this example, you'll get the value of the environment variable key `ENV_KEY` from the `us-east-1` region in the `production` stage. The stage & region names you provided must exist in your Project. ``` serverless env get -s production -r all ``` In this example, you'll be prompted to enter the environment variable key because it's not provided as an option. Then you'll get the value of that key in **all** regions in the `production` stage. ``` serverless env get -k ENV_KEY -s local ``` In this example, you'll get the value of the `ENV_KEY` env var from your local machine. You don't have to provide a region in this case.
``` serverless env get ``` **Must be run inside a Serverless Project.** It gets the value of a specific environment variable key from a specific region in a specific stage. It takes the following options: * `-k <key>` The environment variable key you want to get the value for. * `-s <stage>` The name of the stage you want to get the value of the environment variable from. If set to "local", you'll get the value of the env var from your local machine. * `-r <region>` The name of the region you want to get the value of the environment variable from. If set to "all", you'll get the value of the env var key in all regions in the chosen stage. If the chosen stage is "local", then you don't have to provide a region. ### Examples ``` serverless env get ``` In this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience. ``` serverless env get -k ENV_KEY -s production -r us-east-1 ``` In this example, you'll get the value of the environment variable key `ENV_KEY` from the `us-east-1` region in the `production` stage. The stage & region names you provided must exist in your Project. ``` serverless env get -s production -r all ``` In this example, you'll be prompted to enter the environment variable key because it's not provided as an option. Then you'll get the value of that key in **all** regions in the `production` stage. ``` serverless env get -k ENV_KEY -s local ``` In this example, you'll get the value of the `ENV_KEY` env var from your local machine. You don't have to provide a region in this case.
{"_id":"56bacbe74aa5930d00da77f2","hidden":false,"order":22,"title":"Env Set","updates":["5673465af65d9c0d002e3c8e"],"user":"562120887c515c0d008eee9b","project":"5611c207f2aeda0d002b3734","__v":0,"api":{"results":{"codes":[{"language":"json","code":"{}","name":"","status":200},{"code":"{}","name":"","status":400,"language":"json"}]},"settings":"","auth":"required","params":[],"url":""},"body":"```\nserverless env set\n```\n**Must be run inside a Serverless Project.** It sets the value of a specific environment variable key from a specific region in a specific stage. It takes the following options:\n\n* `-k <key>` The environment variable key you want to set the value to.\n* `-v <value>` The environment variable value you want to set to the key.\n* `-s <stage>` The name of the stage you want to set the env var in. If set to \"local\", you'll set the value of the env var in your local machine.\n* `-r <region>` The name of the region you want to set the env var in. If set to \"all\", you'll set the env var in all regions in the chosen stage. If the chosen stage is \"local\", then you don't have to provide a region.\n\n### Examples\n```\nserverless env set\n```\nIn this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience.\n\n```\nserverless env set -k ENV_KEY  -v ENV_VAL\n```\nIn this example, you'll be prompted to choose a stage and region to set the env var in, then you'll set the env var `ENV_KEY=ENV_VAL` in the chosen stage & region.\n\n```\nserverless env set -s production -r all\n```\nIn this example, you'll be prompted to enter the env var key and value, and set them in all regions in the `production` stage.\n\n```\nserverless env set -k ENV_KEY -v ENV_VAL -s local\n```\nIn this example, you'll set the env var `ENV_KEY=ENV_VAL` in your local machine (in the `.env` file).\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"About `.env` File\",\n  \"body\": \"The `.env` file is used for local testing only. It's a common misconception to think that when you set the env var in the `.env` file, it'll be deployed with your Function to a stage/region. That doesn't actually happen because we want to avoid env var collision. You have to set the env var in each stage/region explicitly with the `serverless env set` command, and choose the right stage/region.\"\n}\n[/block]","createdAt":"2015-12-02T14:22:15.710Z","excerpt":"Sets the value of a specific environment variable key in a specific region in a specific stage.","githubsync":"","category":"56bacbe74aa5930d00da77da","slug":"env-set","link_external":false,"link_url":"","sync_unique":"","type":"basic","version":"56bacbe64aa5930d00da77d8","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Env Set

Sets the value of a specific environment variable key in a specific region in a specific stage.

``` serverless env set ``` **Must be run inside a Serverless Project.** It sets the value of a specific environment variable key from a specific region in a specific stage. It takes the following options: * `-k <key>` The environment variable key you want to set the value to. * `-v <value>` The environment variable value you want to set to the key. * `-s <stage>` The name of the stage you want to set the env var in. If set to "local", you'll set the value of the env var in your local machine. * `-r <region>` The name of the region you want to set the env var in. If set to "all", you'll set the env var in all regions in the chosen stage. If the chosen stage is "local", then you don't have to provide a region. ### Examples ``` serverless env set ``` In this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience. ``` serverless env set -k ENV_KEY -v ENV_VAL ``` In this example, you'll be prompted to choose a stage and region to set the env var in, then you'll set the env var `ENV_KEY=ENV_VAL` in the chosen stage & region. ``` serverless env set -s production -r all ``` In this example, you'll be prompted to enter the env var key and value, and set them in all regions in the `production` stage. ``` serverless env set -k ENV_KEY -v ENV_VAL -s local ``` In this example, you'll set the env var `ENV_KEY=ENV_VAL` in your local machine (in the `.env` file). [block:callout] { "type": "warning", "title": "About `.env` File", "body": "The `.env` file is used for local testing only. It's a common misconception to think that when you set the env var in the `.env` file, it'll be deployed with your Function to a stage/region. That doesn't actually happen because we want to avoid env var collision. You have to set the env var in each stage/region explicitly with the `serverless env set` command, and choose the right stage/region." } [/block]
``` serverless env set ``` **Must be run inside a Serverless Project.** It sets the value of a specific environment variable key from a specific region in a specific stage. It takes the following options: * `-k <key>` The environment variable key you want to set the value to. * `-v <value>` The environment variable value you want to set to the key. * `-s <stage>` The name of the stage you want to set the env var in. If set to "local", you'll set the value of the env var in your local machine. * `-r <region>` The name of the region you want to set the env var in. If set to "all", you'll set the env var in all regions in the chosen stage. If the chosen stage is "local", then you don't have to provide a region. ### Examples ``` serverless env set ``` In this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience. ``` serverless env set -k ENV_KEY -v ENV_VAL ``` In this example, you'll be prompted to choose a stage and region to set the env var in, then you'll set the env var `ENV_KEY=ENV_VAL` in the chosen stage & region. ``` serverless env set -s production -r all ``` In this example, you'll be prompted to enter the env var key and value, and set them in all regions in the `production` stage. ``` serverless env set -k ENV_KEY -v ENV_VAL -s local ``` In this example, you'll set the env var `ENV_KEY=ENV_VAL` in your local machine (in the `.env` file). [block:callout] { "type": "warning", "title": "About `.env` File", "body": "The `.env` file is used for local testing only. It's a common misconception to think that when you set the env var in the `.env` file, it'll be deployed with your Function to a stage/region. That doesn't actually happen because we want to avoid env var collision. You have to set the env var in each stage/region explicitly with the `serverless env set` command, and choose the right stage/region." } [/block]
{"_id":"56bacbe74aa5930d00da77f3","api":{"settings":"","auth":"required","params":[],"url":"","results":{"codes":[{"status":200,"language":"json","code":"{}","name":""},{"code":"{}","name":"","status":400,"language":"json"}]}},"order":23,"category":"56bacbe74aa5930d00da77da","slug":"env-unset","sync_unique":"","title":"Env Unset","version":"56bacbe64aa5930d00da77d8","__v":0,"body":"```\nserverless env unset\n```\n**Must be run inside a Serverless Project.** It unsets the value of a specific environment variable key from a specific region in a specific stage. It takes the following options:\n\n* `-k <key>` The environment variable key you want to unset.\n* `-s <stage>` The name of the stage you want to unset the value of the environment variable from. If set to \"local\", you'll unset the value of the env var from your local machine.\n* `-r <region>` The name of the region you want to unset the value of the environment variable from. If set to \"all\", you'll unset the value of the env var key from all regions in the chosen stage. If the chosen stage is \"local\", then you don't have to provide a region.\n\n### Examples\n```\nserverless env unset\n```\nIn this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience.\n\n```\nserverless env unset -k ENV_KEY -s production -r us-east-1\n```\nIn this example, you'll unset the value of the environment variable key `ENV_KEY` from the `us-east-1` region in the `production` stage. The stage & region names you provided must exist in your Project.\n\n```\nserverless env unset -s production -r all\n```\nIn this example, you'll be prompted to enter the environment variable key because it's not provided as an option. Then you'll unset the value of that key in **all** regions in the `production` stage.\n\n```\nserverless env unset -k ENV_KEY -s local\n```\nIn this example, you'll unset the value of the `ENV_KEY` env var from your local machine. You don't have to provide a region in this case.","type":"basic","updates":["568b410ecbd4ca0d00aebfdd"],"githubsync":"","hidden":false,"link_external":false,"link_url":"","project":"5611c207f2aeda0d002b3734","user":"562120887c515c0d008eee9b","createdAt":"2015-12-02T14:22:27.463Z","excerpt":"Unsets the value of a specific environment variable key from a specific region in a specific stage.","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Env Unset

Unsets the value of a specific environment variable key from a specific region in a specific stage.

``` serverless env unset ``` **Must be run inside a Serverless Project.** It unsets the value of a specific environment variable key from a specific region in a specific stage. It takes the following options: * `-k <key>` The environment variable key you want to unset. * `-s <stage>` The name of the stage you want to unset the value of the environment variable from. If set to "local", you'll unset the value of the env var from your local machine. * `-r <region>` The name of the region you want to unset the value of the environment variable from. If set to "all", you'll unset the value of the env var key from all regions in the chosen stage. If the chosen stage is "local", then you don't have to provide a region. ### Examples ``` serverless env unset ``` In this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience. ``` serverless env unset -k ENV_KEY -s production -r us-east-1 ``` In this example, you'll unset the value of the environment variable key `ENV_KEY` from the `us-east-1` region in the `production` stage. The stage & region names you provided must exist in your Project. ``` serverless env unset -s production -r all ``` In this example, you'll be prompted to enter the environment variable key because it's not provided as an option. Then you'll unset the value of that key in **all** regions in the `production` stage. ``` serverless env unset -k ENV_KEY -s local ``` In this example, you'll unset the value of the `ENV_KEY` env var from your local machine. You don't have to provide a region in this case.
``` serverless env unset ``` **Must be run inside a Serverless Project.** It unsets the value of a specific environment variable key from a specific region in a specific stage. It takes the following options: * `-k <key>` The environment variable key you want to unset. * `-s <stage>` The name of the stage you want to unset the value of the environment variable from. If set to "local", you'll unset the value of the env var from your local machine. * `-r <region>` The name of the region you want to unset the value of the environment variable from. If set to "all", you'll unset the value of the env var key from all regions in the chosen stage. If the chosen stage is "local", then you don't have to provide a region. ### Examples ``` serverless env unset ``` In this example, all options are missing, so you'll be prompted to enter each of the required options for best user experience. ``` serverless env unset -k ENV_KEY -s production -r us-east-1 ``` In this example, you'll unset the value of the environment variable key `ENV_KEY` from the `us-east-1` region in the `production` stage. The stage & region names you provided must exist in your Project. ``` serverless env unset -s production -r all ``` In this example, you'll be prompted to enter the environment variable key because it's not provided as an option. Then you'll unset the value of that key in **all** regions in the `production` stage. ``` serverless env unset -k ENV_KEY -s local ``` In this example, you'll unset the value of the `ENV_KEY` env var from your local machine. You don't have to provide a region in this case.
{"_id":"56bacbe84aa5930d00da77f4","api":{"auth":"required","params":[],"results":{"codes":[{"name":"","code":"{}","language":"json","status":200},{"code":"{}","language":"json","status":400,"name":""}]},"settings":"","url":""},"excerpt":"Initializing the Serverless class, and using its methods.","isReference":false,"link_url":"","order":0,"version":"56bacbe64aa5930d00da77d8","project":"5611c207f2aeda0d002b3734","category":"56bacbe74aa5930d00da77dc","createdAt":"2016-01-18T06:16:55.765Z","githubsync":"","hidden":false,"link_external":false,"__v":2,"body":"This is the main Serverless Class.  It contains the Actions, Hooks, Configuration (project path, credentials, etc.) as well as the other classes.\n\nIf you are using Serverless programmatically, you can instantiate it like this:\n```\nlet serverless = new Serverless({\n   awsAdminKeyId:     '<YOUR_AWS_ADMIN_KEY>',\n   awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>',\n   projectPath:       'yourprojectpath'\n});\n```\n\n##`.init()`\nThis initialize the Serverless state.  When called, all assets of your project are loaded into the state and ready to be used.  This returns a promise.\n```\n// Initialize the Serverless state by calling this.  It returns a promise.\nserverless.init() \n   .then(function() {\n        // Do logic\n    })\n```\n\n##`.state`\nThis is where the Serverless state is located.  It contains subclasses of all of your project assets.\n```\n// State\nserverless.state\n// Project\nserverless.state.project\n// Components\nserverless.state.project.components\n// Functions\nserverless.state.project.componentOne.functions\nserverless.state.project.componentOne.functions.functionOne\n```\n##`.getConfig()`\nGets the configuration of your Serverless instance.\n```\nlet config = serverless.getConfig();\n```\n\n##`.updateConfig(config)`\nThis updates the configuration of your Serverless instance.\n```\nserverless.updateConfig({ \n   projectPath: 'new/project/path'\n});\n```\n\n##`.addAction(action, config)`\nAdds an Action to your Serverless instance.  This is commonly used inside Serverless Plugins to modify/extend the Framework.  For more information on how this works, please check out the [Serverless Plugin Boilerplate](https://github.com/serverless/serverless-plugin-boilerplate)\n```\nserverless.addAction(this._customAction.bind(this), {\n        handler:       'customAction',\n        description:   'A custom action from a custom plugin',\n        context:       'custom',\n        contextAction: 'run',\n        options:       [{\n          option:      'option',\n          shortcut:    'o',\n          description: 'test option 1'\n        }],\n        parameters: [ \n          {\n            parameter: 'paths',\n            description: 'One or multiple paths to your function',\n            position: '0->'\n          }\n        ]\n      });\n```\n\n##`.addAction(action, config)`\nAdds an Action to your Serverless instance.  This is commonly used inside Serverless Plugins to modify/extend the Framework.  For more information on how this works, please check out the [Serverless Plugin Boilerplate](https://github.com/serverless/serverless-plugin-boilerplate)\n```\nserverless.addAction(this._customAction.bind(this), {\n        handler:       'customAction',\n        description:   'A custom action from a custom plugin',\n        context:       'custom',\n        contextAction: 'run',\n        options:       [{\n          option:      'option',\n          shortcut:    'o',\n          description: 'test option 1'\n        }],\n        parameters: [ \n          {\n            parameter: 'paths',\n            description: 'One or multiple paths to your function',\n            position: '0->'\n          }\n        ]\n      });\n```","type":"basic","updates":["56b302d4af176a0d00964c87","56eaf4b5d326c30e007caa04"],"slug":"serverless","sync_unique":"","title":"Serverless","user":"5611c1e58c76a61900fd0739","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Serverless

Initializing the Serverless class, and using its methods.

This is the main Serverless Class. It contains the Actions, Hooks, Configuration (project path, credentials, etc.) as well as the other classes. If you are using Serverless programmatically, you can instantiate it like this: ``` let serverless = new Serverless({ awsAdminKeyId: '<YOUR_AWS_ADMIN_KEY>', awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>', projectPath: 'yourprojectpath' }); ``` ##`.init()` This initialize the Serverless state. When called, all assets of your project are loaded into the state and ready to be used. This returns a promise. ``` // Initialize the Serverless state by calling this. It returns a promise. serverless.init() .then(function() { // Do logic }) ``` ##`.state` This is where the Serverless state is located. It contains subclasses of all of your project assets. ``` // State serverless.state // Project serverless.state.project // Components serverless.state.project.components // Functions serverless.state.project.componentOne.functions serverless.state.project.componentOne.functions.functionOne ``` ##`.getConfig()` Gets the configuration of your Serverless instance. ``` let config = serverless.getConfig(); ``` ##`.updateConfig(config)` This updates the configuration of your Serverless instance. ``` serverless.updateConfig({ projectPath: 'new/project/path' }); ``` ##`.addAction(action, config)` Adds an Action to your Serverless instance. This is commonly used inside Serverless Plugins to modify/extend the Framework. For more information on how this works, please check out the [Serverless Plugin Boilerplate](https://github.com/serverless/serverless-plugin-boilerplate) ``` serverless.addAction(this._customAction.bind(this), { handler: 'customAction', description: 'A custom action from a custom plugin', context: 'custom', contextAction: 'run', options: [{ option: 'option', shortcut: 'o', description: 'test option 1' }], parameters: [ { parameter: 'paths', description: 'One or multiple paths to your function', position: '0->' } ] }); ``` ##`.addAction(action, config)` Adds an Action to your Serverless instance. This is commonly used inside Serverless Plugins to modify/extend the Framework. For more information on how this works, please check out the [Serverless Plugin Boilerplate](https://github.com/serverless/serverless-plugin-boilerplate) ``` serverless.addAction(this._customAction.bind(this), { handler: 'customAction', description: 'A custom action from a custom plugin', context: 'custom', contextAction: 'run', options: [{ option: 'option', shortcut: 'o', description: 'test option 1' }], parameters: [ { parameter: 'paths', description: 'One or multiple paths to your function', position: '0->' } ] }); ```
This is the main Serverless Class. It contains the Actions, Hooks, Configuration (project path, credentials, etc.) as well as the other classes. If you are using Serverless programmatically, you can instantiate it like this: ``` let serverless = new Serverless({ awsAdminKeyId: '<YOUR_AWS_ADMIN_KEY>', awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>', projectPath: 'yourprojectpath' }); ``` ##`.init()` This initialize the Serverless state. When called, all assets of your project are loaded into the state and ready to be used. This returns a promise. ``` // Initialize the Serverless state by calling this. It returns a promise. serverless.init() .then(function() { // Do logic }) ``` ##`.state` This is where the Serverless state is located. It contains subclasses of all of your project assets. ``` // State serverless.state // Project serverless.state.project // Components serverless.state.project.components // Functions serverless.state.project.componentOne.functions serverless.state.project.componentOne.functions.functionOne ``` ##`.getConfig()` Gets the configuration of your Serverless instance. ``` let config = serverless.getConfig(); ``` ##`.updateConfig(config)` This updates the configuration of your Serverless instance. ``` serverless.updateConfig({ projectPath: 'new/project/path' }); ``` ##`.addAction(action, config)` Adds an Action to your Serverless instance. This is commonly used inside Serverless Plugins to modify/extend the Framework. For more information on how this works, please check out the [Serverless Plugin Boilerplate](https://github.com/serverless/serverless-plugin-boilerplate) ``` serverless.addAction(this._customAction.bind(this), { handler: 'customAction', description: 'A custom action from a custom plugin', context: 'custom', contextAction: 'run', options: [{ option: 'option', shortcut: 'o', description: 'test option 1' }], parameters: [ { parameter: 'paths', description: 'One or multiple paths to your function', position: '0->' } ] }); ``` ##`.addAction(action, config)` Adds an Action to your Serverless instance. This is commonly used inside Serverless Plugins to modify/extend the Framework. For more information on how this works, please check out the [Serverless Plugin Boilerplate](https://github.com/serverless/serverless-plugin-boilerplate) ``` serverless.addAction(this._customAction.bind(this), { handler: 'customAction', description: 'A custom action from a custom plugin', context: 'custom', contextAction: 'run', options: [{ option: 'option', shortcut: 'o', description: 'test option 1' }], parameters: [ { parameter: 'paths', description: 'One or multiple paths to your function', position: '0->' } ] }); ```
{"_id":"56bacbe84aa5930d00da77f5","project":"5611c207f2aeda0d002b3734","updates":[],"user":"5611c1e58c76a61900fd0739","excerpt":"Initializing the State class, and using its methods.","hidden":false,"slug":"state","version":"56bacbe64aa5930d00da77d8","api":{"results":{"codes":[{"name":"","code":"{}","language":"json","status":200},{"name":"","code":"{}","language":"json","status":400}]},"settings":"","url":"","auth":"required","params":[]},"githubsync":"","link_external":false,"sync_unique":"","type":"basic","createdAt":"2016-01-18T06:17:23.420Z","link_url":"","order":1,"title":"State","__v":2,"body":"The `State` class contains everything you need to know about the state of your project, its components and functions, along with some powerful methods that lets you manipulate your project programmatically.\n\nTo use the `State` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the State class from the `classes` property on the `Serverless` class. Here's how it looks in code:\n```\nlet serverless = new Serverless({\n   awsAdminKeyId:     '<YOUR_AWS_ADMIN_KEY>',\n   awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>',\n   projectPath:       'yourprojectpath'\n});\n\nlet state = new serverless.classes.State(serverless);\n```\n\n##`.load()`\nLoads your the state (project and meta data) from the file system. This method is called when you initialize a new `State` class. But you can use it to get an updated state. This method returns a promise.\n```\nstate.load();\n```\n\n##`.get()`\nGets the project and meta data. Returns an object literal with `project` and `meta` properties.\n```\nlet state = state.get();\n```\n\n##`.getPopulated(options)`\nSame as the `.get()` method, but returns all project data **populated**. That means if you've defined any templates or variables in your `s-*.json` files, they'll be populated for you.\n\nThis method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder.\n```\nlet options = {\n    stage: \"dev\",\n    region: \"us-east-1\"\n};\nlet populatedState = state.getPopulated(options);\n```\n\n##`.set(data)` & `.save()`\nSets/updates the meta or project data of your state in memory. It takes a `data` object with two properties: `project` and `meta`. Each of which is the updated version that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise.\n\nFor example if you want to set/update project name:\n```\nlet Project = state.getProject();\nProject.name = \"newName\"\nlet data = {\n    project: Project\n};\nstate.set(data);\nstate.save();\n```\nNow your `s-project.json` will have `newName` as the project name.\n\n##`.getMeta()`\nGets the meta data of your project. Including stages, regions and their variables.\n```\nlet meta = state.getMeta();\n```\n\n##`.getProject()`\nGets the project data, including all components and functions.\n```\nlet project = state.getProject();\n```\n\n##`.getResources(options)`\nGets all the CloudFormation resources that are defined in your `s-resources-cf.json` file. It takes an options object with `populate`, `stage`, and `region` properties. If `populate` is set to true, it'll return a populated CF template. In that case, `stage` and `region` are needed. If `populate` is false, it'll just return the CF template with the template/variables as they are unpopulated.\n```\nlet options = {\n    populate: true,\n    stage: \"dev\",\n    region: \"us-east-1\"\n};\n\nlet CF = state.getResources(options);\n```\n\n##`.getStages()`\nGets all stages defined in your project.\n```\nlet stages = state.getStages();\n```\n\n##`.getRegions(stage)`\nGets all regions defined within a stage. It requires a stage as a parameter.\n```\nlet regions = state.getRegions(\"dev\");\n```\n\n##`.getComponents(options)`\nGets all components data, all components paths, or specific components data, based on the `options` provided. Here are some examples:\n```\n// no options passed, so will get all components data\nlet components = state.getComponents();\n\n// will get all components paths\nlet options = {\n    returnPaths: true\n};\nlet allComponentsPaths = state.getComponents(options);\n\n// will get two components data by providing the components paths\nlet options  = {\n    paths: [\"component1\", \"component2\"]\n};\nlet myTwoComponents = state.getComponents(options);\n```\n\n##`.getFunctions(options)`\nGets function data or paths based on the provided options. This method can get functions of a specific component or all functions in the project. You can also provide specific function paths. Here are some examples:\n```\n// no options passed, so will get all functions data\nlet allFunctions = state.getFunctions();\n\n// will get all functions paths\nlet options = {\n    returnPaths: true\n};\nlet allFunctionsPaths = state.getFunctions(options);\n\n// will get all functions data for \"nodejs\" component\nlet options  = {\n    component: \"nodejs\"\n};\nlet nodejsFunctions = state.getFunctions(options);\n\n// will get two function data by providing the function paths\nlet options  = {\n    paths: [\"component1/module1/function1\", \"component1/module1/function2\"]\n};\nlet myTwoFunctions = state.getFunctions(options);\n```\n\n##`.getEndpoints(options)`\nGets endpoint data or paths based on the provided options. This method can get endpoints of a specific component, a specific function, or a specific method. It can also simply return all project endpoints if no options provided, or specific endpoints based on paths you provide. Here are some examples:\n```\n// no options passed, so will get all endpoints data\nlet allEndpoints = state.getEndpoints();\n\n// will get all endpionts paths\nlet options = {\n    returnPaths: true\n};\nlet allEndpointsPaths = state.getEndpoints(options);\n\n// will get all endpoints data for \"nodejs\" component\nlet options  = {\n    component: \"nodejs\"\n};\nlet nodejsEndpoints = state.getEndpoints(options);\n\n// will get all endpoints data with a method of \"GET\" for \"function1\" function inside \"module1\" module inside \"nodejs\" component\nlet options  = {\n    component: \"nodejs\",\n    module: \"module1\",\n    function: \"function1\",\n    endpointMethod: \"GET\"\n};\nlet specificEndpoints = state.getEndpoints(options);\n\n// will get two endpoints data by providing the endpoints paths\nlet options  = {\n    paths: [\"component1/[email protected]/show~GET\", \"component1/subfolder/[email protected]/create~POST\"]\n};\nlet myTwoEndpoints = state.getEndpoints(options);\n```\n\n##`.validateStageExists(stage)`\nThis method validates that a specific stage exists in your project. It returns a Boolean.\n```\nlet doesStageExists = state.validateStageExists(\"dev\");\n```\n\n##`.validateRegionExists(stage, region)`\nThis method validates that a specific region exists in a specific stage in your project. It returns a Boolean.\n```\nlet doesRegionExists = state.validateRegionExists(\"dev\", \"us-east-1\");\n```","category":"56bacbe74aa5930d00da77dc","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

State

Initializing the State class, and using its methods.

The `State` class contains everything you need to know about the state of your project, its components and functions, along with some powerful methods that lets you manipulate your project programmatically. To use the `State` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the State class from the `classes` property on the `Serverless` class. Here's how it looks in code: ``` let serverless = new Serverless({ awsAdminKeyId: '<YOUR_AWS_ADMIN_KEY>', awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>', projectPath: 'yourprojectpath' }); let state = new serverless.classes.State(serverless); ``` ##`.load()` Loads your the state (project and meta data) from the file system. This method is called when you initialize a new `State` class. But you can use it to get an updated state. This method returns a promise. ``` state.load(); ``` ##`.get()` Gets the project and meta data. Returns an object literal with `project` and `meta` properties. ``` let state = state.get(); ``` ##`.getPopulated(options)` Same as the `.get()` method, but returns all project data **populated**. That means if you've defined any templates or variables in your `s-*.json` files, they'll be populated for you. This method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder. ``` let options = { stage: "dev", region: "us-east-1" }; let populatedState = state.getPopulated(options); ``` ##`.set(data)` & `.save()` Sets/updates the meta or project data of your state in memory. It takes a `data` object with two properties: `project` and `meta`. Each of which is the updated version that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise. For example if you want to set/update project name: ``` let Project = state.getProject(); Project.name = "newName" let data = { project: Project }; state.set(data); state.save(); ``` Now your `s-project.json` will have `newName` as the project name. ##`.getMeta()` Gets the meta data of your project. Including stages, regions and their variables. ``` let meta = state.getMeta(); ``` ##`.getProject()` Gets the project data, including all components and functions. ``` let project = state.getProject(); ``` ##`.getResources(options)` Gets all the CloudFormation resources that are defined in your `s-resources-cf.json` file. It takes an options object with `populate`, `stage`, and `region` properties. If `populate` is set to true, it'll return a populated CF template. In that case, `stage` and `region` are needed. If `populate` is false, it'll just return the CF template with the template/variables as they are unpopulated. ``` let options = { populate: true, stage: "dev", region: "us-east-1" }; let CF = state.getResources(options); ``` ##`.getStages()` Gets all stages defined in your project. ``` let stages = state.getStages(); ``` ##`.getRegions(stage)` Gets all regions defined within a stage. It requires a stage as a parameter. ``` let regions = state.getRegions("dev"); ``` ##`.getComponents(options)` Gets all components data, all components paths, or specific components data, based on the `options` provided. Here are some examples: ``` // no options passed, so will get all components data let components = state.getComponents(); // will get all components paths let options = { returnPaths: true }; let allComponentsPaths = state.getComponents(options); // will get two components data by providing the components paths let options = { paths: ["component1", "component2"] }; let myTwoComponents = state.getComponents(options); ``` ##`.getFunctions(options)` Gets function data or paths based on the provided options. This method can get functions of a specific component or all functions in the project. You can also provide specific function paths. Here are some examples: ``` // no options passed, so will get all functions data let allFunctions = state.getFunctions(); // will get all functions paths let options = { returnPaths: true }; let allFunctionsPaths = state.getFunctions(options); // will get all functions data for "nodejs" component let options = { component: "nodejs" }; let nodejsFunctions = state.getFunctions(options); // will get two function data by providing the function paths let options = { paths: ["component1/module1/function1", "component1/module1/function2"] }; let myTwoFunctions = state.getFunctions(options); ``` ##`.getEndpoints(options)` Gets endpoint data or paths based on the provided options. This method can get endpoints of a specific component, a specific function, or a specific method. It can also simply return all project endpoints if no options provided, or specific endpoints based on paths you provide. Here are some examples: ``` // no options passed, so will get all endpoints data let allEndpoints = state.getEndpoints(); // will get all endpionts paths let options = { returnPaths: true }; let allEndpointsPaths = state.getEndpoints(options); // will get all endpoints data for "nodejs" component let options = { component: "nodejs" }; let nodejsEndpoints = state.getEndpoints(options); // will get all endpoints data with a method of "GET" for "function1" function inside "module1" module inside "nodejs" component let options = { component: "nodejs", module: "module1", function: "function1", endpointMethod: "GET" }; let specificEndpoints = state.getEndpoints(options); // will get two endpoints data by providing the endpoints paths let options = { paths: ["component1/[email protected]/show~GET", "component1/subfolder/[email protected]/create~POST"] }; let myTwoEndpoints = state.getEndpoints(options); ``` ##`.validateStageExists(stage)` This method validates that a specific stage exists in your project. It returns a Boolean. ``` let doesStageExists = state.validateStageExists("dev"); ``` ##`.validateRegionExists(stage, region)` This method validates that a specific region exists in a specific stage in your project. It returns a Boolean. ``` let doesRegionExists = state.validateRegionExists("dev", "us-east-1"); ```
The `State` class contains everything you need to know about the state of your project, its components and functions, along with some powerful methods that lets you manipulate your project programmatically. To use the `State` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the State class from the `classes` property on the `Serverless` class. Here's how it looks in code: ``` let serverless = new Serverless({ awsAdminKeyId: '<YOUR_AWS_ADMIN_KEY>', awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>', projectPath: 'yourprojectpath' }); let state = new serverless.classes.State(serverless); ``` ##`.load()` Loads your the state (project and meta data) from the file system. This method is called when you initialize a new `State` class. But you can use it to get an updated state. This method returns a promise. ``` state.load(); ``` ##`.get()` Gets the project and meta data. Returns an object literal with `project` and `meta` properties. ``` let state = state.get(); ``` ##`.getPopulated(options)` Same as the `.get()` method, but returns all project data **populated**. That means if you've defined any templates or variables in your `s-*.json` files, they'll be populated for you. This method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder. ``` let options = { stage: "dev", region: "us-east-1" }; let populatedState = state.getPopulated(options); ``` ##`.set(data)` & `.save()` Sets/updates the meta or project data of your state in memory. It takes a `data` object with two properties: `project` and `meta`. Each of which is the updated version that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise. For example if you want to set/update project name: ``` let Project = state.getProject(); Project.name = "newName" let data = { project: Project }; state.set(data); state.save(); ``` Now your `s-project.json` will have `newName` as the project name. ##`.getMeta()` Gets the meta data of your project. Including stages, regions and their variables. ``` let meta = state.getMeta(); ``` ##`.getProject()` Gets the project data, including all components and functions. ``` let project = state.getProject(); ``` ##`.getResources(options)` Gets all the CloudFormation resources that are defined in your `s-resources-cf.json` file. It takes an options object with `populate`, `stage`, and `region` properties. If `populate` is set to true, it'll return a populated CF template. In that case, `stage` and `region` are needed. If `populate` is false, it'll just return the CF template with the template/variables as they are unpopulated. ``` let options = { populate: true, stage: "dev", region: "us-east-1" }; let CF = state.getResources(options); ``` ##`.getStages()` Gets all stages defined in your project. ``` let stages = state.getStages(); ``` ##`.getRegions(stage)` Gets all regions defined within a stage. It requires a stage as a parameter. ``` let regions = state.getRegions("dev"); ``` ##`.getComponents(options)` Gets all components data, all components paths, or specific components data, based on the `options` provided. Here are some examples: ``` // no options passed, so will get all components data let components = state.getComponents(); // will get all components paths let options = { returnPaths: true }; let allComponentsPaths = state.getComponents(options); // will get two components data by providing the components paths let options = { paths: ["component1", "component2"] }; let myTwoComponents = state.getComponents(options); ``` ##`.getFunctions(options)` Gets function data or paths based on the provided options. This method can get functions of a specific component or all functions in the project. You can also provide specific function paths. Here are some examples: ``` // no options passed, so will get all functions data let allFunctions = state.getFunctions(); // will get all functions paths let options = { returnPaths: true }; let allFunctionsPaths = state.getFunctions(options); // will get all functions data for "nodejs" component let options = { component: "nodejs" }; let nodejsFunctions = state.getFunctions(options); // will get two function data by providing the function paths let options = { paths: ["component1/module1/function1", "component1/module1/function2"] }; let myTwoFunctions = state.getFunctions(options); ``` ##`.getEndpoints(options)` Gets endpoint data or paths based on the provided options. This method can get endpoints of a specific component, a specific function, or a specific method. It can also simply return all project endpoints if no options provided, or specific endpoints based on paths you provide. Here are some examples: ``` // no options passed, so will get all endpoints data let allEndpoints = state.getEndpoints(); // will get all endpionts paths let options = { returnPaths: true }; let allEndpointsPaths = state.getEndpoints(options); // will get all endpoints data for "nodejs" component let options = { component: "nodejs" }; let nodejsEndpoints = state.getEndpoints(options); // will get all endpoints data with a method of "GET" for "function1" function inside "module1" module inside "nodejs" component let options = { component: "nodejs", module: "module1", function: "function1", endpointMethod: "GET" }; let specificEndpoints = state.getEndpoints(options); // will get two endpoints data by providing the endpoints paths let options = { paths: ["component1/[email protected]/show~GET", "component1/subfolder/[email protected]/create~POST"] }; let myTwoEndpoints = state.getEndpoints(options); ``` ##`.validateStageExists(stage)` This method validates that a specific stage exists in your project. It returns a Boolean. ``` let doesStageExists = state.validateStageExists("dev"); ``` ##`.validateRegionExists(stage, region)` This method validates that a specific region exists in a specific stage in your project. It returns a Boolean. ``` let doesRegionExists = state.validateRegionExists("dev", "us-east-1"); ```
{"_id":"56bacbe84aa5930d00da77f6","body":"The `Project` class contains everything you need to know about your project, its components, and functions, along with some powerful methods that lets you manipulate your project programmatically.\n\nTo use the `Project` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Project` class from the `classes` property on the `Serverless` class. Here's how it looks in code:\n```\nlet serverless = new Serverless({\n   awsAdminKeyId:     '<YOUR_AWS_ADMIN_KEY>',\n   awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>',\n   projectPath:       'yourprojectpath'\n});\n\nlet project = new serverless.classes.Project(serverless);\n```\n\n##`.load()`\nLoads your Project from the file system. This method returns a promise.\n```\nproject.load();\n```\n\n##`.get()`\nGets the project data, along with its components, modules and functions.\n```\nlet project = project.get();\n```\n\n##`.getPopulated(options)`\nSame as the `.get()` method, but returns all project data **populated**. That means if you've defined any templates or variables in your `s-*.json` files, they'll be populated for you.\n\nThis method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder.\n```\nlet options = {\n    stage: \"dev\",\n    region: \"us-east-1\"\n};\nlet populatedProject = project.getPopulated(options);\n```\n\n##`.getTemplates()`\nGets all the templates defined in your project in all the `s-templates.json` files.\n```\nlet projectTemplates = project.getTemplates();\n```\n\n##`.set(data)` & `.save()`\nSets/updates the project data. It takes a `data` object that is simply the updated project data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise.\n\nFor example if you want to set/update project name:\n```\nlet data = project.get();\ndata.name = \"newName\"\nproject.set(data);\nstate.save();\n```\nNow your `s-project.json` will have `newName` as the project name.","project":"5611c207f2aeda0d002b3734","type":"basic","api":{"url":"","auth":"required","params":[],"results":{"codes":[{"name":"","code":"{}","language":"json","status":200},{"name":"","code":"{}","language":"json","status":400}]},"settings":""},"githubsync":"","link_external":false,"order":2,"slug":"project","title":"Project","version":"56bacbe64aa5930d00da77d8","createdAt":"2016-01-18T06:17:28.963Z","excerpt":"Initializing the Project class, and using its methods.","hidden":false,"sync_unique":"","user":"5611c1e58c76a61900fd0739","__v":1,"category":"56bacbe74aa5930d00da77dc","link_url":"","updates":[],"metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Project

Initializing the Project class, and using its methods.

The `Project` class contains everything you need to know about your project, its components, and functions, along with some powerful methods that lets you manipulate your project programmatically. To use the `Project` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Project` class from the `classes` property on the `Serverless` class. Here's how it looks in code: ``` let serverless = new Serverless({ awsAdminKeyId: '<YOUR_AWS_ADMIN_KEY>', awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>', projectPath: 'yourprojectpath' }); let project = new serverless.classes.Project(serverless); ``` ##`.load()` Loads your Project from the file system. This method returns a promise. ``` project.load(); ``` ##`.get()` Gets the project data, along with its components, modules and functions. ``` let project = project.get(); ``` ##`.getPopulated(options)` Same as the `.get()` method, but returns all project data **populated**. That means if you've defined any templates or variables in your `s-*.json` files, they'll be populated for you. This method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder. ``` let options = { stage: "dev", region: "us-east-1" }; let populatedProject = project.getPopulated(options); ``` ##`.getTemplates()` Gets all the templates defined in your project in all the `s-templates.json` files. ``` let projectTemplates = project.getTemplates(); ``` ##`.set(data)` & `.save()` Sets/updates the project data. It takes a `data` object that is simply the updated project data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise. For example if you want to set/update project name: ``` let data = project.get(); data.name = "newName" project.set(data); state.save(); ``` Now your `s-project.json` will have `newName` as the project name.
The `Project` class contains everything you need to know about your project, its components, and functions, along with some powerful methods that lets you manipulate your project programmatically. To use the `Project` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Project` class from the `classes` property on the `Serverless` class. Here's how it looks in code: ``` let serverless = new Serverless({ awsAdminKeyId: '<YOUR_AWS_ADMIN_KEY>', awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>', projectPath: 'yourprojectpath' }); let project = new serverless.classes.Project(serverless); ``` ##`.load()` Loads your Project from the file system. This method returns a promise. ``` project.load(); ``` ##`.get()` Gets the project data, along with its components, modules and functions. ``` let project = project.get(); ``` ##`.getPopulated(options)` Same as the `.get()` method, but returns all project data **populated**. That means if you've defined any templates or variables in your `s-*.json` files, they'll be populated for you. This method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder. ``` let options = { stage: "dev", region: "us-east-1" }; let populatedProject = project.getPopulated(options); ``` ##`.getTemplates()` Gets all the templates defined in your project in all the `s-templates.json` files. ``` let projectTemplates = project.getTemplates(); ``` ##`.set(data)` & `.save()` Sets/updates the project data. It takes a `data` object that is simply the updated project data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise. For example if you want to set/update project name: ``` let data = project.get(); data.name = "newName" project.set(data); state.save(); ``` Now your `s-project.json` will have `newName` as the project name.
{"_id":"56bacbe84aa5930d00da77f7","body":"The `Component` class contains everything you need to know about a specific Component and its functions, along with some powerful methods that lets you manipulate your components programmatically.\n\nTo use the `Component` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Component` class from the `classes` property on the `Serverless` class. You'll need to pass the `serverless` instance that you initialized earlier along with a `config` object that contains the `sPath` of your Component.\n\nHere's how it looks in code:\n```\nlet serverless = new Serverless({\n   awsAdminKeyId:     '<YOUR_AWS_ADMIN_KEY>',\n   awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>',\n   projectPath:       'yourprojectpath'\n});\n\nlet config = {\n    sPath: \"nodejscomponent\"\n};\nlet component = new serverless.classes.Component(serverless, config);\n```\n\n##`.updateConfig(config)`\nUpdates the config of your newly created Component class. It takes a `config` parameter with a `sPath` property.\n```\nlet config = {\n    sPath: \"nodejscomponent\"\n};\ncomponent.updateConfig(config);\n```\n\n##`.load()`\nLoads your Component from the file system. This method returns a promise.\n```\ncomponent.load();\n```\n\n##`.get()`\nGets the component data, along with its modules and functions.\n```\nlet component = component.get();\n```\n\n##`.getPopulated(options)`\nSame as the `.get()` method, but returns all component data **populated**. That means if you've defined any templates or variables in your `s-*.json` files, they'll be populated for you.\n\nThis method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder.\n```\nlet options = {\n    stage: \"dev\",\n    region: \"us-east-1\"\n};\nlet populatedComponent = component.getPopulated(options);\n```\n\n##`.set(data)` & `.save()`\nSets/updates the component data. It takes a `data` object that is simply the updated component data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise.\n\nFor example if you want to set/update component runtime:\n```\nlet data = component.get();\ndata.name = \"newName\";\ncomponent.set(data);\ncomponent.save();\n```\nNow your `s-component.json` will have `newName` as the value of the `name` property.","githubsync":"","hidden":false,"title":"Component","user":"5611c1e58c76a61900fd0739","category":"56bacbe74aa5930d00da77dc","createdAt":"2016-01-18T06:17:51.894Z","order":3,"version":"56bacbe64aa5930d00da77d8","api":{"auth":"required","params":[],"results":{"codes":[{"name":"","code":"{}","language":"json","status":200},{"name":"","code":"{}","language":"json","status":400}]},"settings":"","url":""},"excerpt":"Initializing the Component class, and using its methods.","project":"5611c207f2aeda0d002b3734","sync_unique":"","updates":[],"__v":2,"link_external":false,"link_url":"","slug":"component","type":"basic","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Component

Initializing the Component class, and using its methods.

The `Component` class contains everything you need to know about a specific Component and its functions, along with some powerful methods that lets you manipulate your components programmatically. To use the `Component` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Component` class from the `classes` property on the `Serverless` class. You'll need to pass the `serverless` instance that you initialized earlier along with a `config` object that contains the `sPath` of your Component. Here's how it looks in code: ``` let serverless = new Serverless({ awsAdminKeyId: '<YOUR_AWS_ADMIN_KEY>', awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>', projectPath: 'yourprojectpath' }); let config = { sPath: "nodejscomponent" }; let component = new serverless.classes.Component(serverless, config); ``` ##`.updateConfig(config)` Updates the config of your newly created Component class. It takes a `config` parameter with a `sPath` property. ``` let config = { sPath: "nodejscomponent" }; component.updateConfig(config); ``` ##`.load()` Loads your Component from the file system. This method returns a promise. ``` component.load(); ``` ##`.get()` Gets the component data, along with its modules and functions. ``` let component = component.get(); ``` ##`.getPopulated(options)` Same as the `.get()` method, but returns all component data **populated**. That means if you've defined any templates or variables in your `s-*.json` files, they'll be populated for you. This method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder. ``` let options = { stage: "dev", region: "us-east-1" }; let populatedComponent = component.getPopulated(options); ``` ##`.set(data)` & `.save()` Sets/updates the component data. It takes a `data` object that is simply the updated component data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise. For example if you want to set/update component runtime: ``` let data = component.get(); data.name = "newName"; component.set(data); component.save(); ``` Now your `s-component.json` will have `newName` as the value of the `name` property.
The `Component` class contains everything you need to know about a specific Component and its functions, along with some powerful methods that lets you manipulate your components programmatically. To use the `Component` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Component` class from the `classes` property on the `Serverless` class. You'll need to pass the `serverless` instance that you initialized earlier along with a `config` object that contains the `sPath` of your Component. Here's how it looks in code: ``` let serverless = new Serverless({ awsAdminKeyId: '<YOUR_AWS_ADMIN_KEY>', awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>', projectPath: 'yourprojectpath' }); let config = { sPath: "nodejscomponent" }; let component = new serverless.classes.Component(serverless, config); ``` ##`.updateConfig(config)` Updates the config of your newly created Component class. It takes a `config` parameter with a `sPath` property. ``` let config = { sPath: "nodejscomponent" }; component.updateConfig(config); ``` ##`.load()` Loads your Component from the file system. This method returns a promise. ``` component.load(); ``` ##`.get()` Gets the component data, along with its modules and functions. ``` let component = component.get(); ``` ##`.getPopulated(options)` Same as the `.get()` method, but returns all component data **populated**. That means if you've defined any templates or variables in your `s-*.json` files, they'll be populated for you. This method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder. ``` let options = { stage: "dev", region: "us-east-1" }; let populatedComponent = component.getPopulated(options); ``` ##`.set(data)` & `.save()` Sets/updates the component data. It takes a `data` object that is simply the updated component data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise. For example if you want to set/update component runtime: ``` let data = component.get(); data.name = "newName"; component.set(data); component.save(); ``` Now your `s-component.json` will have `newName` as the value of the `name` property.
{"_id":"56bacbe84aa5930d00da77f9","category":"56bacbe74aa5930d00da77dc","githubsync":"","link_external":false,"link_url":"","api":{"url":"","auth":"required","params":[],"results":{"codes":[{"name":"","code":"{}","language":"json","status":200},{"code":"{}","language":"json","status":400,"name":""}]},"settings":""},"createdAt":"2016-01-18T06:18:05.400Z","project":"5611c207f2aeda0d002b3734","title":"Function","__v":1,"slug":"function","sync_unique":"","type":"basic","updates":[],"user":"5611c1e58c76a61900fd0739","body":"The `Function` class contains everything you need to know about a specific Function and its endpoints, along with some powerful methods that lets you manipulate your functions programmatically.\n\nTo use the `Function` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Function` class from the `classes` property on the `Serverless` class. You'll need to pass the `serverless` instance that you initialized earlier along with a `config` object that contains the sPath of your Function.\n\nHere's how it looks in code:\n```\nlet serverless = new Serverless({\n   awsAdminKeyId:     '<YOUR_AWS_ADMIN_KEY>',\n   awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>',\n   projectPath:       'yourprojectpath'\n});\n\nlet config = {\n    sPath: \"nodejscomponent/function1\"\n};\nlet function = new serverless.classes.Function(serverless, config);\n```\n\n##`.updateConfig(config)`\nUpdates the config of your newly created Function class. It takes a `config` parameter with an `sPath` property.\n```\nlet config = {\n    sPath: \"nodejscomponent/function1\"\n};\nfunction.updateConfig(config);\n```\n\n##`.load()`\nLoads your Function from the file system. This method returns a promise.\n```\nfunction.load();\n```\n\n##`.get()`\nGets the function data, along with its endpoints.\n```\nlet function = function.get();\n```\n\n##`.getPopulated(options)`\nSame as the `.get()` method, but returns all function data **populated**. That means if you've defined any templates or variables in your `s-function.json` file, they'll be populated for you.\n\nThis method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder.\n```\nlet options = {\n    stage: \"dev\",\n    region: \"us-east-1\"\n};\nlet populatedFunction = function.getPopulated(options);\n```\n\n##`.set(data)` & `.save()`\nSets/updates the function data. It takes a `data` object that is simply the updated function data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise.\n\nFor example if you want to set/update component runtime:\n```\nlet data = function.get();\ndata.timeout = 10;\nfunction.set(data);\nfunction.save();\n```\nNow your `s-function.json` will have `timeout` set to `10`.","excerpt":"Initializing the Function class, and using its methods.","hidden":false,"order":4,"version":"56bacbe64aa5930d00da77d8","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Function

Initializing the Function class, and using its methods.

The `Function` class contains everything you need to know about a specific Function and its endpoints, along with some powerful methods that lets you manipulate your functions programmatically. To use the `Function` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Function` class from the `classes` property on the `Serverless` class. You'll need to pass the `serverless` instance that you initialized earlier along with a `config` object that contains the sPath of your Function. Here's how it looks in code: ``` let serverless = new Serverless({ awsAdminKeyId: '<YOUR_AWS_ADMIN_KEY>', awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>', projectPath: 'yourprojectpath' }); let config = { sPath: "nodejscomponent/function1" }; let function = new serverless.classes.Function(serverless, config); ``` ##`.updateConfig(config)` Updates the config of your newly created Function class. It takes a `config` parameter with an `sPath` property. ``` let config = { sPath: "nodejscomponent/function1" }; function.updateConfig(config); ``` ##`.load()` Loads your Function from the file system. This method returns a promise. ``` function.load(); ``` ##`.get()` Gets the function data, along with its endpoints. ``` let function = function.get(); ``` ##`.getPopulated(options)` Same as the `.get()` method, but returns all function data **populated**. That means if you've defined any templates or variables in your `s-function.json` file, they'll be populated for you. This method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder. ``` let options = { stage: "dev", region: "us-east-1" }; let populatedFunction = function.getPopulated(options); ``` ##`.set(data)` & `.save()` Sets/updates the function data. It takes a `data` object that is simply the updated function data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise. For example if you want to set/update component runtime: ``` let data = function.get(); data.timeout = 10; function.set(data); function.save(); ``` Now your `s-function.json` will have `timeout` set to `10`.
The `Function` class contains everything you need to know about a specific Function and its endpoints, along with some powerful methods that lets you manipulate your functions programmatically. To use the `Function` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Function` class from the `classes` property on the `Serverless` class. You'll need to pass the `serverless` instance that you initialized earlier along with a `config` object that contains the sPath of your Function. Here's how it looks in code: ``` let serverless = new Serverless({ awsAdminKeyId: '<YOUR_AWS_ADMIN_KEY>', awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>', projectPath: 'yourprojectpath' }); let config = { sPath: "nodejscomponent/function1" }; let function = new serverless.classes.Function(serverless, config); ``` ##`.updateConfig(config)` Updates the config of your newly created Function class. It takes a `config` parameter with an `sPath` property. ``` let config = { sPath: "nodejscomponent/function1" }; function.updateConfig(config); ``` ##`.load()` Loads your Function from the file system. This method returns a promise. ``` function.load(); ``` ##`.get()` Gets the function data, along with its endpoints. ``` let function = function.get(); ``` ##`.getPopulated(options)` Same as the `.get()` method, but returns all function data **populated**. That means if you've defined any templates or variables in your `s-function.json` file, they'll be populated for you. This method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder. ``` let options = { stage: "dev", region: "us-east-1" }; let populatedFunction = function.getPopulated(options); ``` ##`.set(data)` & `.save()` Sets/updates the function data. It takes a `data` object that is simply the updated function data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise. For example if you want to set/update component runtime: ``` let data = function.get(); data.timeout = 10; function.set(data); function.save(); ``` Now your `s-function.json` will have `timeout` set to `10`.
{"_id":"56bacbe84aa5930d00da77fa","__v":2,"excerpt":"Initializing the Endpoint class, and using its methods.","githubsync":"","hidden":false,"link_external":false,"order":5,"updates":["569f8941daf2d417000c72c0"],"category":"56bacbe74aa5930d00da77dc","project":"5611c207f2aeda0d002b3734","sync_unique":"","type":"basic","api":{"settings":"","url":"","auth":"required","params":[],"results":{"codes":[{"language":"json","status":200,"name":"","code":"{}"},{"name":"","code":"{}","language":"json","status":400}]}},"user":"5611c1e58c76a61900fd0739","body":"The `Endpoint` class contains everything you need to know about a specific Endpoint, along with some powerful methods that lets you manipulate your endpoints programmatically.\n\nTo use the `Endpoint` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Endpoint` class from the `classes` property on the `Serverless` class. You'll need to pass the `serverless` instance that you initialized earlier along with a `config` object that contains the `sPath` of your endpoint.\n\nHere's how it looks in code:\n```\nlet serverless = new Serverless({\n   awsAdminKeyId:     '<YOUR_AWS_ADMIN_KEY>',\n   awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>',\n   projectPath:       'yourprojectpath'\n});\n\nlet config = {\n    sPath: \"nodejscomponent/[email protected]/create~GET\"\n};\nlet endpoint = new serverless.classes.Endpoint(serverless, config);\n```\n\n##`.updateConfig(config)`\nUpdates the config of your newly created Endpoint class. It takes a `config` parameter with an `sPath` property.\n```\nlet config = {\n    sPath: \"nodejscomponent/[email protected]/create~GET\"\n};\n\nendpoint.updateConfig(config);\n```\n\n##`.load()`\nLoads your Endpoint from the file system. This method returns a promise.\n```\nendpoint.load();\n```\n\n##`.get()`\nGets the endpoint data.\n```\nlet endpoint = endpoint.get();\n```\n\n##`.getPopulated(options)`\nSame as the `.get()` method, but returns all endpoint data **populated**. That means if you've defined any templates or variables in your `s-function.json` file, they'll be populated for you.\n\nThis method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder.\n```\nlet options = {\n    stage: \"dev\",\n    region: \"us-east-1\"\n};\nlet populatedEndpoint = endpoint.getPopulated(options);\n```\n\n##`.set(data)` & `.save()`\nSets/updates the endpoint data. It takes a `data` object that is simply the updated endpoint data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise.\n\nFor example if you want to set/update Endpoint method:\n```\nlet data = endpoint.get();\ndata.method = \"POST\";\nendpoint.set(data);\nendpoint.save();\n```\nNow your `s-function.json` will have the endpoint method set to `POST` instead of `GET`.","createdAt":"2016-01-18T06:18:11.000Z","link_url":"","slug":"endpoint","title":"Endpoint","version":"56bacbe64aa5930d00da77d8","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Endpoint

Initializing the Endpoint class, and using its methods.

The `Endpoint` class contains everything you need to know about a specific Endpoint, along with some powerful methods that lets you manipulate your endpoints programmatically. To use the `Endpoint` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Endpoint` class from the `classes` property on the `Serverless` class. You'll need to pass the `serverless` instance that you initialized earlier along with a `config` object that contains the `sPath` of your endpoint. Here's how it looks in code: ``` let serverless = new Serverless({ awsAdminKeyId: '<YOUR_AWS_ADMIN_KEY>', awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>', projectPath: 'yourprojectpath' }); let config = { sPath: "nodejscomponent/[email protected]/create~GET" }; let endpoint = new serverless.classes.Endpoint(serverless, config); ``` ##`.updateConfig(config)` Updates the config of your newly created Endpoint class. It takes a `config` parameter with an `sPath` property. ``` let config = { sPath: "nodejscomponent/[email protected]/create~GET" }; endpoint.updateConfig(config); ``` ##`.load()` Loads your Endpoint from the file system. This method returns a promise. ``` endpoint.load(); ``` ##`.get()` Gets the endpoint data. ``` let endpoint = endpoint.get(); ``` ##`.getPopulated(options)` Same as the `.get()` method, but returns all endpoint data **populated**. That means if you've defined any templates or variables in your `s-function.json` file, they'll be populated for you. This method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder. ``` let options = { stage: "dev", region: "us-east-1" }; let populatedEndpoint = endpoint.getPopulated(options); ``` ##`.set(data)` & `.save()` Sets/updates the endpoint data. It takes a `data` object that is simply the updated endpoint data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise. For example if you want to set/update Endpoint method: ``` let data = endpoint.get(); data.method = "POST"; endpoint.set(data); endpoint.save(); ``` Now your `s-function.json` will have the endpoint method set to `POST` instead of `GET`.
The `Endpoint` class contains everything you need to know about a specific Endpoint, along with some powerful methods that lets you manipulate your endpoints programmatically. To use the `Endpoint` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Endpoint` class from the `classes` property on the `Serverless` class. You'll need to pass the `serverless` instance that you initialized earlier along with a `config` object that contains the `sPath` of your endpoint. Here's how it looks in code: ``` let serverless = new Serverless({ awsAdminKeyId: '<YOUR_AWS_ADMIN_KEY>', awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>', projectPath: 'yourprojectpath' }); let config = { sPath: "nodejscomponent/[email protected]/create~GET" }; let endpoint = new serverless.classes.Endpoint(serverless, config); ``` ##`.updateConfig(config)` Updates the config of your newly created Endpoint class. It takes a `config` parameter with an `sPath` property. ``` let config = { sPath: "nodejscomponent/[email protected]/create~GET" }; endpoint.updateConfig(config); ``` ##`.load()` Loads your Endpoint from the file system. This method returns a promise. ``` endpoint.load(); ``` ##`.get()` Gets the endpoint data. ``` let endpoint = endpoint.get(); ``` ##`.getPopulated(options)` Same as the `.get()` method, but returns all endpoint data **populated**. That means if you've defined any templates or variables in your `s-function.json` file, they'll be populated for you. This method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder. ``` let options = { stage: "dev", region: "us-east-1" }; let populatedEndpoint = endpoint.getPopulated(options); ``` ##`.set(data)` & `.save()` Sets/updates the endpoint data. It takes a `data` object that is simply the updated endpoint data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise. For example if you want to set/update Endpoint method: ``` let data = endpoint.get(); data.method = "POST"; endpoint.set(data); endpoint.save(); ``` Now your `s-function.json` will have the endpoint method set to `POST` instead of `GET`.
{"_id":"56bcae01eba85017004331bf","api":{"url":"","settings":"","results":{"codes":[{"name":"","code":"{}","language":"json","status":200},{"code":"{}","language":"json","status":400,"name":""}]},"auth":"required","params":[]},"excerpt":"Initializing the Event class, and using its methods.","slug":"event","version":"56bacbe64aa5930d00da77d8","link_url":"","sync_unique":"","__v":0,"createdAt":"2016-02-11T15:51:29.051Z","hidden":false,"link_external":false,"updates":[],"user":"562120887c515c0d008eee9b","category":"56bacbe74aa5930d00da77dc","githubsync":"","order":6,"type":"basic","body":"The `Event` class contains everything you need to know about a specific Event source, along with some powerful methods that lets you manipulate your event sources programmatically.\n\nTo use the `Event` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Event` class from the `classes` property on the `Serverless` class. You'll need to pass the `serverless` instance that you initialized earlier along with a `config` object that contains the `sPath` of your endpoint.\n\nHere's how it looks in code:\n```\nlet serverless = new Serverless({\n   awsAdminKeyId:     '<YOUR_AWS_ADMIN_KEY>',\n   awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>',\n   projectPath:       'yourprojectpath'\n});\n\nlet config = {\n    sPath: \"nodejscomponent/function1#eventName\"\n};\nlet event = new serverless.classes.Event(serverless, config);\n```\n\n##`.updateConfig(config)`\nUpdates the config of your newly created Event class. It takes a `config` parameter with an `sPath` property.\n```\nlet config = {\n    sPath: \"nodejscomponent/function1#eventName\"\n};\n\nendpoint.updateConfig(config);\n```\n\n##`.load()`\nLoads your Event from the file system. This method returns a promise.\n```\nevent.load();\n```\n\n##`.get()`\nGets the event data.\n```\nlet event = event.get();\n```\n\n##`.getPopulated(options)`\nSame as the `.get()` method, but returns all event data **populated**. That means if you've defined any templates or variables in your `s-function.json` file, they'll be populated for you.\n\nThis method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder.\n```\nlet options = {\n    stage: \"dev\",\n    region: \"us-east-1\"\n};\nlet populatedEvent = event.getPopulated(options);\n```\n\n##`.set(data)` & `.save()`\nSets/updates the event data. It takes a `data` object that is simply the updated event data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise.\n\nFor example if you want to set/update event name:\n```\nlet data = event.get();\ndata.name = \"newEventName\";\nevent.set(data);\nevent.save();\n```\nNow your `s-function.json` will have the event name set to `newEventName.","project":"5611c207f2aeda0d002b3734","title":"Event","metadata":{"title":"","description":"","image":[]},"childrenPages":[]}

Event

Initializing the Event class, and using its methods.

The `Event` class contains everything you need to know about a specific Event source, along with some powerful methods that lets you manipulate your event sources programmatically. To use the `Event` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Event` class from the `classes` property on the `Serverless` class. You'll need to pass the `serverless` instance that you initialized earlier along with a `config` object that contains the `sPath` of your endpoint. Here's how it looks in code: ``` let serverless = new Serverless({ awsAdminKeyId: '<YOUR_AWS_ADMIN_KEY>', awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>', projectPath: 'yourprojectpath' }); let config = { sPath: "nodejscomponent/function1#eventName" }; let event = new serverless.classes.Event(serverless, config); ``` ##`.updateConfig(config)` Updates the config of your newly created Event class. It takes a `config` parameter with an `sPath` property. ``` let config = { sPath: "nodejscomponent/function1#eventName" }; endpoint.updateConfig(config); ``` ##`.load()` Loads your Event from the file system. This method returns a promise. ``` event.load(); ``` ##`.get()` Gets the event data. ``` let event = event.get(); ``` ##`.getPopulated(options)` Same as the `.get()` method, but returns all event data **populated**. That means if you've defined any templates or variables in your `s-function.json` file, they'll be populated for you. This method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder. ``` let options = { stage: "dev", region: "us-east-1" }; let populatedEvent = event.getPopulated(options); ``` ##`.set(data)` & `.save()` Sets/updates the event data. It takes a `data` object that is simply the updated event data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise. For example if you want to set/update event name: ``` let data = event.get(); data.name = "newEventName"; event.set(data); event.save(); ``` Now your `s-function.json` will have the event name set to `newEventName.
The `Event` class contains everything you need to know about a specific Event source, along with some powerful methods that lets you manipulate your event sources programmatically. To use the `Event` class, you first need to initialize the main `Serverless` class, just like you did before, and then initialize the `Event` class from the `classes` property on the `Serverless` class. You'll need to pass the `serverless` instance that you initialized earlier along with a `config` object that contains the `sPath` of your endpoint. Here's how it looks in code: ``` let serverless = new Serverless({ awsAdminKeyId: '<YOUR_AWS_ADMIN_KEY>', awsAdminSecretKey: '<YOUR_AWS_ADMIN_SECRET_KEY>', projectPath: 'yourprojectpath' }); let config = { sPath: "nodejscomponent/function1#eventName" }; let event = new serverless.classes.Event(serverless, config); ``` ##`.updateConfig(config)` Updates the config of your newly created Event class. It takes a `config` parameter with an `sPath` property. ``` let config = { sPath: "nodejscomponent/function1#eventName" }; endpoint.updateConfig(config); ``` ##`.load()` Loads your Event from the file system. This method returns a promise. ``` event.load(); ``` ##`.get()` Gets the event data. ``` let event = event.get(); ``` ##`.getPopulated(options)` Same as the `.get()` method, but returns all event data **populated**. That means if you've defined any templates or variables in your `s-function.json` file, they'll be populated for you. This method requires `stage` and `region` defined as `options` properties. We use these properties to populate the correct variables from the `_meta` folder. ``` let options = { stage: "dev", region: "us-east-1" }; let populatedEvent = event.getPopulated(options); ``` ##`.set(data)` & `.save()` Sets/updates the event data. It takes a `data` object that is simply the updated event data that you want to set. After you set your new data in memory, you can persist your new data on the file system using the `.save()` method. Note that the `save()` method returns a promise. For example if you want to set/update event name: ``` let data = event.get(); data.name = "newEventName"; event.set(data); event.save(); ``` Now your `s-function.json` will have the event name set to `newEventName.