Serverless-next.js: how to use existing cloudfront distribution

Created on 16 Oct 2019  路  11Comments  路  Source: serverless-nextjs/serverless-next.js

While doing the deployment, how can we make sure that we use existing CloudFront distribution?

next component

Most helpful comment

I have found that if we change id and arn in Template.myNextApp.CloudFront.json file inside .serverless folder then we can do distribution on existing cloudfront.

But can we control this somehow from .env for from yml file?

All 11 comments

I have found that if we change id and arn in Template.myNextApp.CloudFront.json file inside .serverless folder then we can do distribution on existing cloudfront.

But can we control this somehow from .env for from yml file?

@kartikag01 This is a good idea, thanks for raising the issue.

To support this we'll have to do most of the work in https://github.com/serverless-components/aws-cloudfront to allow passing a distribution id. The rest, as in work to do in the next component is easy.

Any workarounds at this moment?

Being able to specify what distribution to use in serverless.yml sounds nice. I also have two different cloudfrount distributions and S3 buckets for a development environment and a production environment, and I don't see a straightforward solution for me to handle deployments to different distributions.

As @danielcondemarin mentioned, it would probably take changing the underlying component to do this. The good news is that I would guess it would be quite easy to do (components are simple that way). The bad news is that the maintainers take forever to merge their PR's

We've just moved to next 9 and this project worked like a charm!
The downside is that it's creating each day a new Cloudfront dist. We've tried @kartikag01 workaround and works well, even with domains and subdomains in yaml file.

Is it possible to set the lambda@edge origin-request aswell?

This has become a really big pain! I share the staging link with team & then there's a new one next day! committing .serverless is not an option in prod environment!

Are there any updates regarding this issue? I sadly believe this makes the whole component unusable at the current state :(.

To avoid creating multiple CD we store the .serverless folder in an S3 bucket

I think Serveless-next.js can do something like that too, pull cache fom S3 -> build and deploy -> push cache back to S3

@danielcondemarin would it be possible to work around this issue with setting up a custom domain? I'm running serverless deploy in a CI/CD context.

@SarKurd that's brilliant. Hacky, but brilliant. I might try that.

@SarKurd that's brilliant. Hacky, but brilliant. I might try that.

Works great for us, we use plugins/s3-cache for Drone CI, pretty easy to set it up

We tried to store the state in version control but never worked properly as we couldn't keep the state up to date, now we restricted everyone from deploying locally and let our pipeline handle that.

Hopefully we see a proper solution Daniel, with the release AWS CDK, it will be much easier as Serverless components is maintained by one guy and it's very difficult to contribute to and get PRs merged

Was this page helpful?
0 / 5 - 0 ratings