My component doesn't deploy
Make sure your
serverless.yml uses the
serverless-components format. serverless components differ from the original serverless framework, even though they are both accessible via the same CLI.
Note how the correct yaml doesn't declare a
For deploying, don't run
serverless deploy. Simply run
serverless and that deploys your components declared in the
For more information about serverless components go here.
serverless-plugin or this component?Should I use the
Users are encouraged to use this component instead of the
serverless-plugin. This component was built and designed using lessons learned from the serverless plugin.
How do I interact with other AWS Services within my app?
examples/dynamodb-crud for an example Todo application that interacts with DynamoDB. You can find a full list of examples here
[CI/CD] A new CloudFront distribution is created on every CI build. I wasn't expecting that
You need to commit your application state in source control. That is the files under the
.serverless directory. Alternatively you could use S3 to store the
.serverless files, see an example here
The serverless team is currently working on remote state storage so this won't be necessary in the future.
My lambda is deployed to
us-east-1. How can I deploy it to another region?
Serverless next.js is regionless. By design,
serverless-next.js applications will be deployed across the globe to every CloudFront edge location. The lambda might look like is only deployed to
us-east-1 but behind the scenes, it is replicated to every other region.
I require passing additional information into my build
See the sample below for an advanced
build setup that includes passing additional arguments and environment variables to the build.
I was expecting for automatic subdomain redirection when using the domainType: www/apex input
The redirection is not currently implemented, but there is a manual workaround outlined here. In summary, you will have to create a new S3 bucket and set it up with static website hosting to redirect requests to your supported subdomain type (ex. "www.example.com" or "example.com"). To be able to support HTTPS redirects, you'll need to set up a CloudFront distribution with the S3 redirect bucket as the origin. Finally, you'll need to create an "A" record in Route 53 with your newly created CloudFront distribution as the alias target.