Advanced features and detailed information for using Serverless Framework with Runway.
Disabling NPM CI
At the start of each module execution, Runway will execute
npm ci to ensure Serverless Framework is installed in the project (so Runway can execute it via
This can be disabled (e.g. for use when the
node_modules directory is pre-compiled) via the
skip_npm_ci module option.
deployments: - modules: - path: myslsproject.sls options: skip_npm_ci: true
Extending a Serverless Configuration File
Runway has the ability to extend the contents of a serverless.yml file using the value of the
The value of this option is recursively merged into a resolved clone of the module’s Serverless configuration.
To create this resolved clone, Runway uses “serverless print” (including args) to resolve the module’s Serverless configuration file and output the contents to a temporary file.
The temporary file is deleted after each execution of Runway.
This functionality can be especially useful when used alongside remote module paths such as a module from a git repository to change values on the fly without needing to modify the source for small differences in each environment.
deployments: - modules: - path: git::git://github.com/onicagroup/example.git//sampleapp?tag=v1.0.0 options: extend_serverless_yml: custom: env: memorySize: 512 regions: - us-east-1
The two data sources are merged by iterating over their content and combining the lowest level nodes possible.
functions: example: handler: handler.example runtime: python3.8 memorySize: 512
deployments: - modules: - path: sampleapp.sls options: extend_serverless_yml: functions: example: memorySize: 1024 resources: Resources: ExampleResource: Type: AWS::CloudFormation::WaitConditionHandle regions: - us-east-1
functions: example: handler: handler.example runtime: python3.8 memorySize: 1024 resources: Resources: ExampleResource: Type: AWS::CloudFormation::WaitConditionHandle
Promoting Builds Through Environments
.zips can be used between environments by setting the
promotezip module option and providing a bucket name in which to cache the builds.
The first time the Serverless module is deployed using this option, it will build/deploy as normal and cache the artifact on S3. On subsequent deploys, Runway will use the cached artifact (finding it by comparing the module source code).
This enables a common build account to deploy new builds in a dev/test environment, and then promote that same zip through other environments. Any of these environments can be in the same or different AWS accounts.
The CloudFormation Stack deploying the zip will be re-generated on each deployment so environment-specific values/lookups will work as normal.
deployments: - modules: - path: myslsproject.sls options: promotezip: bucketname: my-build-account-bucket-name
Specifying Serverless CLI Arguments/Options
Runway can pass custom arguments/options to the Serverless CLI by using the
These will always be placed after the default arguments/options.
The value of
args must be a list of arguments/options to pass to the CLI.
Each element of the argument/option should be it’s own list item (e.g.
--config sls.yml would be
Do not provide
--region <region> or
--stage <stage> here, these will be provided by Runway.
Runway will also provide
--no-color if stdout is not a TTY.
deployments: - modules: - path: sampleapp.sls options: args: - '--config' - sls.yml regions: - us-east-2 environments: example: true
$ serverless deploy -r us-east-1 --stage example --config sls.yml