0.1.2 • Public • Published


    Potential prototype of v2.

    This is a backwards compatible prototype that builds on inertia of v1 community and brings them into the future with us.

    It enables a highly configurable & composable pieces and multi-cloud & third party resource for all existing serverless projects & more.

    See Examples

    Backing Product Philosophy

    • Domain Expertise is paramount - We must eat, sleep, breathe serverless.
    • Next level user experience - UX/DX is baked into every nut & bolt. Remove all points of friction in our users lives.
    • We must be users of our product - Dogfooding is everything, otherwise it’s all guess work
    • Invent and Simplify - We must trust our instincts and move fast
    • Measure everything - Learn from mistakes but not be afraid to make them
    • Growth state of mind - Bake in growth mechanisms (activation/retention/analytics) throughout product
    • Iterate and improve - Slow time to market = death
    • Mantra - Have fun & build awesome. We create the future.

    Table of Contents

    How to use examples

    # Clone down repo 
    git clone
    # in root 
    npm install
    # cd into an example folder 
    cd examples/basic
    # run config command 
    node ../../index.js config
    # run deploy command 
    node ../../index.js deploy
    # or any other v1 command 
    node ../../index.js info/remove etc

    Additionally if you just want the end user experience use one of the 2 demo repos:

    Whats New?

    Standardized Service Config

    Service config is now a first class citizen in serverless. Developers can now specify all the configuration requirements of a given service.

    The config key in serverless.yml enables:

    • Easier service re-use
    • Streamlined setup via proto config
    • Composition of services
    • Future usage in GUI tools
    # Service configuration. Values needed for service to work
        displayName: "Send grid API Key"
        type: string
        required: true
        default: 'your-api-key'

    Config types are based heavily on the RAML type system

    Config values are written out to a .serverless.config.json file

      "stageName": {
        "SECRET_API_KEY": "xxxx"
      "dev": {
        "SECRET_API_KEY": "yyyy"

    See example in larger config example.

    Multi-cloud & third party resource support

    Serverless v1 resources were limited by the choice of the service provider. For example if the provider was set at aws, resources was limited to a single CloudFormation Stack.

    This is no longer the case!

    We are expanding the functionality of resources to handle multiple resources.

    See example(s) in github webhook examples.

    # Multi cloud / third party resource defintion examples
      # provision github webhook
        type: Github:Webhook
          apiToken: ${config.GITHUB_AUTH_TOKEN}
          repository: ${config.GITHUB_REPO}
      # provision cloud formation
        type: AWS:CloudFormation
            Type: 'AWS::DynamoDB::Table'
              TableName: 'overbearing-ops'
                - AttributeName: id
                  AttributeType: S
                - AttributeName: id
                  KeyType: HASH
                ReadCapacityUnits: 1
                WriteCapacityUnits: 1
      # provision terraform modules
        type: 'Hashicorp:terraform'
            description: the AMI to use
              ami: "${var.ami}"
              count: 2
              source_dest_check: false
                user: root

    A working example that provisions GH webhoojs can be seen and deployed from here

    Composable Services

    (Needs real world validation)

    See nested composed example in examples.

    app: my-real-application # or `service` key
    services: # or `components` or under `resources` key
        type: ./user-service
        version: 0.0.1
          USER_TABLE_NAME: my-app-table-name
        type: ./email-service
        version: 0.0.1
          SENDGRID_API_KEY: 12311dasdwwqdaww
        type: ./sms-service
        version: 0.0.1
          TWILIO_ACCOUNT_SID: 121312331
          TWILIO_AUTH_TOKEN: 9827271711
          TWILIO_PHONE_NUMBER: 1-900-324-1312
        type: ./service-with-db
        version: 0.0.1

    Service Manifest

    It's common practice to require stack outputs like api URLs, ARNs, and other custom values after a service is deployed.

    After the deployment of a service, the service creates a manifest.json file for easy consumption.

    This file can be referenced by front end applications or piped into service discovery tools.

    Example of a manifest file with stage specific values. (final shape of manifest output TBD)

      "dev": {
        "urls": {
          "base": "",
          "byPath": {
            "handle-entry": {
              "url": "",
              "method": ["POST"],
          "byFunction": {
            "handleFormEntry": {
              "url": "",
              "method": ["POST"],
        "functions": {
          "handleFormEntry": {
            "name": "site-form-service-prod-handleFormEntry",
            "arn": "xyxyxyxyx"
        "resources": {
          "MyCloudformationStack": {
            "myDynamoTable": {
              "TableName": "xyz-lol"
          "GitHubWebhook": {
            "repository": "davidwells/components"
      "prod": {
        ... prod stage resources

    Configurable plugins

    (Note: not implemented yet)

    In serverless v1, plugins often needed to specify their configuration in the custom block of serverless.yml

    # Before
      valueNeededForPlugin: 'xyz'
      - my-serverless-plugin

    By turning the plugins array into a keyed object, configuration can live directly on the plugin declaration like so:

        valueNeededForPlugin: 'xyz'
        config: ./webpack.js

    Custom Scripts

    Extending functionality can now easily be accomplished inline in serverless.yml without needing to author a custom plugin.

    See basic example in examples.

      beforeDeploy: node ./tests.js
      deploy: node ./sms-boss.js
      afterDeploy: "npm run integration"

    Multi region support

    (Note: not implemented yet)

    In serverless v1, you are constrained to a single region per deployment, but by altering the region key to accept an array, we can deploy to multiple regions simultaneously

    # Service provider
      name: aws
      runtime: nodejs6.10
        - us-west-1
        - us-east-2

    Other Feature Ideas/Requests

    IAM role support on function level

    "Would be cool if you could define iamRoleStatements at the function level."

    Feedback / Feature Requests

    After completing the steps, please fill out the quick 3 question survey!

    Leave your feedback ❤️

    If you would like to see additional features added don't hesitate to request them!


    Is this backwards compatible with version 1 of the framework?


    Does it work with serverless variables?


    Do additional CloudFormation resources work?


    Can I run this on-prem?


    How many resources can I leverage today?

    254 (all of cloudformation + github webhook resource (sls IP)). There is no limit on the amount of resources we (or the community could add)


    Thanks to Phillip Muens, Eslam λ Hefnawy, and serverless community for their hard work on v1 and Austen for starting it all with v0.




    npm i proto-jojo

    DownloadsWeekly Downloads






    Last publish


    • davidwells