Tracked
- NPM Downloads Last Month
- 3586
- Issues
- 0
- Stars
- 0
- Forks
- 0
- Watchers
- 0
This is a plugin for Serverless that injects a CloudFormation Custom Resource in your deployed stack that sets up a base path mapping between the ApiGateway::Deployment
that Serverless creates, and an API Gateway Custom Domain.
A bug in 1.x caused an extra, unused LogGroup to be created, called /aws/lambdaservice-stage-CustomBasePathMa--
instead of /aws/lambda/service-stage-CustomBasePathMa--
. However, AWS automatically creates a LogGroup for your functions with the correct name. This means that any deployments using 1.x have two LogGroups. After upgrading to 2.x+, deployments may fail due to a CloudFormation error that “the log group already exists”. Sorry about this! It doesn’t always happen, but thankfully, the fix is pretty straightforward if it does and it should only happen the one time.
/aws/lambda/service-stage-CustomBasePathMa--
)
service: my-service
plugins:
- serverless-plugin-custom-domain
custom:
domain: "${opt:region}.myservice.foo.com"
custom.domain
can also be an object, with the following propeties:
name
: the domain name, same as the above string e.g. ${opt:region}.myservice.foo.com
basePath:
a custom base path, instead of the default (none)
- a base path is a prefix e.g. /v1
CloudFormation supports ApiGateway::BasePathMapping
resources but I found they frequently fail to update correctly. Implementing the (relatively simple) logic to get-and-update-or-create combined with a remove
hook for cleanup has proven to be more reliable.
These take a long time to provision and are long-lived persistent resources that have Route53 entires pointing at them as well as ACM certificates that have to be requested and approved. You should manage these outside of Serverless, either via CloudFormation or something like Terraform.