Serverless Framework V4 Generally Available

Serverless Framework V.4 is now generally available. With Serverless Framework V.4, we've significantly accelerated innovation while avoiding breaking changes. Get it now via Github, or "npm i serverless -g".

‍

‍

Here are the highlights of Serverless Framework V.4 so far…

Native Typescript & Build Support

The Framework now includes native support for bundling JavaScript and TypeScript AWS Lambda functions, powered by EsBuild. No plug-ins necessary.

If your AWS Lambda handler uses TypeScript, the Framework will automatically build your code upon deployment with no configuration required.

If you do need to customize, a new build config is optional, allowing easy bundling and minification, control over build concurrency across many AWS Lambda functions, and sourcemap support out of the box.

# serverless.yml

service: my-service

build:  
  esbuild:    
  # Enable or Disable bundling the function code and dependencies. (Default: true)    
  bundle: true    
  # Enable minifying function code. (Default: false)    
  minify: false    
  # NPM packages to not be bundled    
  external:      
    - @aws-sdk/client-s3    
  # NPM packages to not be bundled, as well as not included in node_modules    
  # in the zip file uploaded to Lambda. By default this will be set to aws-sdk    
  # if the runtime is set to nodejs16.x or lower or set to @aws-sdk/* if set to nodejs18.x or higher.    
  exclude:      
    - @aws-sdk/*    
  # The packages config, this can be set to override the behavior of external    
  # If this is set then all dependencies will be treated as external and not bundled.
  packages: external
  # By default Framework will attempt to build and package all functions concurrently.
  # This property can bet set to a different number if you wish to limit the
  # concurrency of those operations.
  buildConcurrency: 3
  # Enable or configure sourcemaps, can be set to true or to an object with further configuration.    
  sourcemap:
    # The sourcemap type to use, options are (inline, linked, or external)
    type: linked
    # Whether to set the NODE_OPTIONS on functions to enable sourcemaps on Lambda
    setNodeOptions: true

Read the docs for more information.

Revamped Dev Mode

When building serverless apps on AWS Lambda, you face a choice: emulate AWS locally or deploy every change to AWS. But, local emulation is complex and differs from the production environment, while deploying every change is slow.

Enter the new Dev Mode in Serverless Framework V4, a hybrid approach combining the best of both worlds. Start a Dev Mode session with serverless dev, and your live AWS Lambda functions will redirect events to your local code for processing. The response from your local code is then sent back to the live Lambda function.

Benefits:

• Faster development – make changes instantly in your local code without a deployment
• Instant logs & feedback – logs, errors and more come directly from your local code.
• More accuracy – only your custom code is emulated; events and the rest of your serverless architecture remain on AWS

Dev Mode works for all AWS Lambda functions in your service. Each invocation gets a unique color for easy log identification, and important event details like HTTP paths and methods are automatically logged. 

This is intended for development environments. Redeploy after finishing to restore your code within AWS Lambda functions.

Read the docs for more information.

Stages Property

One of the key benefits of Serverless Framework is its ability to help teams create separate stacks of their serverless infrastructure on AWS for different environments, known as Stages, across one or several AWS accounts.

To enhance this capability, V.4 introduces a new stages property for configuration specific to Stages, such as Parameters, observability settings, and integrations mentioned in the following sections. The stages property allows you to specify Stage-specific information as well as defaults that act as fallback options for all Stages.

# serverless.yml

service: my-service

stages:
  prod:
    params:
      stripe_api_key: ${env:PROD_STRIPE_API_KEY}
  default:
    params:
      stripe_api_key: ${env:DEV_STRIPE_API_KEY}

‍

While parameters is still supported, we will be unveiling several features for the new stages block and are focused on making it the preferred way to specify all Stage-specific information going forward.

Read the docs for more information.

Terraform Integration

Serverless Framework Variables have been redesigned in V.4 to support integrating and retrieving data and secrets from several new sources, starting with Hashicorp’s Terraform.

It's common to use Terraform and Serverless Framework together, with Terraform provisioning shared infrastructure and Serverless Framework handling app-specific infrastructure. For example, you might use Terraform to provision resources like an RDS database or an SQS queue, while Serverless Framework provisions Lambda functions and event configurations for your service.

The Framework now supports fetching Terraform state outputs from AWS S3, remote, http, or cloud backends. Accessing Terraform state outputs within your serverless.yml file is crucial for retrieving details about shared infrastructure, such as RDS connection strings or SQS queue ARNs. The AWS S3 backend is used when the Terraform state is stored in an AWS S3 bucket, while the remote backend is for state stored in services like Terraform HCP or JFrog Artifactory Terraform Backend Repository. The HTTP backend is used for other 3rd party services, like GitLab. 

All of this is made simple via the ${terraform} Variable (this name can also be customized).

To use the ${terraform} Variable, configure the Variable Resolver. The Variable Resolver is a new concept in Serverless Framework V.4 that allows you to use different sources for your variables. In this case, we use the terraform resolver to reference the Terraform state outputs, and take advantage of the new stages configuration to specify different state options for Stages.

# serverless.yml

service: my-service

stages:
  default:
    resolvers:
      terraform:
        type: terraform
        backend: s3
        bucket: terraform-state
        key: terraform.tfstate

functions:
  helloWorld:
  handler: handler.hello
  environment:
    TERRAFORM_VARIABLE: ${terraform:outputs:users_table_arn}

Read the docs for more information.

Vault Integration

In Serverless Framework V.4, we’re introducing the ${vault} variable, providing seamless integration with HashiCorp Vault, a popular secret management tool. This feature allows you to securely retrieve secrets from HashiCorp Vault at deployment time, enhancing the security and flexibility of your serverless service. Additionally, it leverages our new stages configuration to specify different Vault instances for each stage.

# serverless.yml

service: my-service

stages:
  default:
    resolvers:
      vault:
        type: vault
        address: http://127.0.0.1:8200
        token: ${env:VAULT_TOKEN}
        version: v1

functions:
  helloWorld:
  handler: handler.hello
  environment:
    VAULT_VARIABLE: ${vault:secret/data/mongo/credentials.password}

The example above fetches the secret at the path secret/data/mongo from the Vault server.

Read the docs for more information.

Support Command

Support is included with a License for Serverless Framework V.4, which is especially useful if you are running into critical deployment errors.

Additionally, we’ve built a new support command within V.4, which runs an interactive prompt to generate reports on errors or file a ticket with our support team all via the CLI. This command automatically collects and prints context about your last CLI command while omitting sensitive details like secrets and account information.

Use it to generate a report that’s easy to share with teammates or post to our GitHub repository.

Use the –AI flag to optimize the context for inclusion with a prompt to an AI service (e.g., ChatGPT) to help you debug.

Open a support ticket directly in the CLI, and context will be sent along with your support question, making it easy to get help when you need it most, such as when a critical deployment is failing.

Read the docs for more information.

CI/CD & Many Dashboard Features Included

When purchasing a V.4 License, most Serverless Framework Dashboard features are included at no additional cost. This includes sharing Service inventory, deployment history, Parameters (secrets), and AWS Access Credentials across your team. CI/CD is also included out-of-the-box with every V.4 License.

These features come at no extra cost for teammates and are not priced based on the number of invocations your AWS Lambda functions perform.

The Dashboard also offers powerful AWS Lambda observability features, available as an optional add-on for Traces and Metrics at a separate cost.

Sign into the Serverless Framework Dashboard.

New AWS Features

We are rapidly adding support for new AWS serverless services and features within V.4. 

So far, we’ve added support for new AWS Lambda runtimes like "python3.12", "dotnet8", and "java21". 

We’ve also added support for advanced logging controls for AWS Lambda, such as the ability to capture Logs in JSON, increase log granularity, and set a custom Log Group.

# serverless.yml

service: my-service

provider:
  name: aws
  logs:
    # Optional Configuration of Lambda Logging Configuration
    lambda:
    # The Log Format to be used for all lambda functions (default: Text)
    logFormat: JSON
    # The Application Log Level to be used, This can only be set if `logFormat` is set to `JSON`      
    applicationLogLevel: ERROR
    # The System Log Level to be used, This can only be set if `logFormat` is set to `JSON`      
    systemLogLevel: INFO
    # The LogGroup that will be used by default. If this is set the Framework will not create LogGroups for any functions
    logGroup: /aws/lambda/global-log-group

‍Read the docs for more information.

More

At Serverless Inc, we're all in on the Serverless Framework. Since 2015, we've championed serverless infrastructure and the incredible power it offers developers. We're excited to keep pushing the boundaries and uncovering new possibilities within the serverless movement. 

Stay tuned for what's next… or simply run serverless update .