Next 13 - future plans - Is serverless-next.js dead? #2497
Comments
|
I'd advise moving to another method of deployment. |
|
We have the same problem here. Our Back-end is based on AWS serverless (C#) and our Front-end is based on Next and deployed on AWS too . We are eager to cooperate and teamwork for migration of our front-end with Anyone or any team who has the same problem so we can achieve a better result together and troubleshoot together along the way |
|
BANG, you cannot even deploy with next13 because of some errors that target is not supported anymore and invalid root options in
|
|
#2439 Doesn't seem that project goes forward. Any other approaches to deploy NextJS to AWS? |
|
seems to be dead 💀 |
Docker on EC2. |
|
Dead is a strong statement. IMO It still is a very solid way to deploy v11/10 next.js , that is compatible up to current next version (have not checked recent v13, but it came out like couple of days ago), minus deployment sensitive features. You lose on some features, but you get self managed serverless way to deploy next app. I for one manage a project where these pros still outweigh the cons and the architecture provided here is perfect for my project - I am ready to embrace its quirks, so to speak. If you need any of the deployment sensitive features from next, you can still add them here (provided they are compatible with architecture offered here), maintainer has been very open to contributions. Thing is, Vercel is doing amazing work and only way to be truly up to speed with all they do is to either use architecture they provide or just do a server deployment (That is an easy backup plan if things truly go weird the js way). |
|
Next.js v13 have introduced React (v18) Server Components, and making it default for |
|
Next.js 13, Does it work on other platforms a part from Vercel? Maybe Netlify? Having it in running as a server on an EC2 is not the best scenario. |
|
@fnavarrodev this is the problem when falling into the open-source trap. Next.js - A great open-source project that heavily relies on a commercial product to actually use most of the features... |
|
You can easily deploy Next.js with a Docker Container to AWS Apprunner, AWS ECS / Fargate or Google Cloud Run. For AWS just try: https://aws.github.io/copilot-cli/ You need a shared storage if you want to use ISR: |
|
@cmaerz as far as I know those technologies are on not on the edge, but I could be wrong. I supose you can use cloudfront with a proper cache policy to minigate the latency to your AWS region |
|
@fnavarrodev We use Cloudflare. On all this services you can deploy your Origin on multiple Regions. So this shouldn't be a problem. |
|
For those looking for a simple fix, I can confirm decrementing Obviously there are tradeoffs to downgrading, but I was able to get this package to deploy my build as expected afterward. |
|
I just came here to post that. We've been playing around with it and it looks promising.
|
|
Just to note seems like serverless-components themselves are no longer directly supported by serverless 🤔 https://github.com/serverless/components |
|
Does not support ISR yet, even though they say it does. |
|
Hi, if anyone else is interested in deploying on AWS (a lot more flexible/cost-effective than Vercel), consider using SST. The SST team is implementing its own version that's up to date w/ the latest NextJS version. You can find them on discord https://discord.com/invite/sst in the nextjs channel. Drop on by and asks questions. As of now, most nextjs features are supported/in development. |
A few links to:
|
|
To add to those resources, if you'd like to get something up and running now, you can use this Construct: https://github.com/jetbridge/cdk-nextjs. |
|
Amplify build takes few minutes , I even optimised it shorter ... don't like the fact they provide expensive machine for the build process , you can always ship the .next directory pre-built |
|
With Amplify and nx-cloud the build is quiet fast, I think now is faster that it was before with next.js 12 and serverless, but still slow compare with Vercel. |
|
Update: But for the most part, it works great. |
didn't see V2 in NextjsSuite documentation. could u share a link? |
|
@suil The doc for v2 isn't ready yet, but you can reference it on the example: https://github.com/serverless-stack/sst/tree/sst2/examples/nextjs-app |
|
so you mean still use `npx create-sst@latest my-project' to create a ss1 project. but import { NextjsSuite } from https://github.com/serverless-stack/sst/tree/sst2/packages/sst/src/constructs right? |
import { NextjsSite } from "sst/constructs"
export default {
config: () => ({
name: "my-app",
region: "us-east-1",
}),
stacks: async (app) => {
app.stack(function Web(ctx) {
new NextjsSite(ctx.stack, "MySite")
});
},
}
|
|
ok, I copied the project and used node16 as a template, now getting an error: The content of the sst.config.js Already followed the instructions to setup awscli and also node version 16.18.1 nextjs 13 (this might be the reason) |
|
I'm using this instead: https://www.reddit.com/r/nextjs/comments/yps1zh/deploying_nextjs_v13_to_aws/ Seems to deploy, now resolving some dep issues with build since it is using standalone output |
|
Hmm looks like you're using brew for your node installation? Try using nvm. I've had node issues with brew in the past. Also humor me and use node 18 |
I use nvm, and I switched to 18, still the same error |
I haven't had this issue, nor some folks above. Can you remove |
|
ok, just uninstalled pnpm and install from npm instead. Trying out from node 16 then node 18 again. Node 16 failed the same way Node 18 also fail the same way (I made sure to uninstall pnpm from previous node version and switch and install again using nvm of course) Perhaps the new sst@rc is broken? Actually, looks like pnpx isn't working with sst. I switched to use This is weird... |
|
Hmm... I haven't ran into this. I'm doing |
|
yea, pnpx error out, while npx worked. On the slightly different topic, is there any tutorial or blog that talked about how to use this deploy? I saw tons of lambda functions and not sure how I can access the api routes for this deployment. I found the server handler URL but it doesn't work (it said server failed to respond) |
|
assuming you're using |
thanks for your reply. i'm very new to this so I don't know what you mean by cloudfront url. I used |
|
No problem, happy to help. When you deploy, it uses CloudFront to distribute your app. If you go to your AWS console and navigate to CloudFront, you should see your distribution. Under the "Domain Name" column, you should see something like this: |
|
I see. I found the url in cloudfront, but unfortunately it still said server failed to respond. not sure why. i wonder where I can see the server log for the cloudfront access nvm, I think I found them in cloudwatch |
|
👋 was pointed to this discussion. There seems to be zero support and communication from creators of this package, so I took it and implemented more flexible and leaner version :) feel free to give it a shot: https://github.com/sladg/nextjs-lambda Used on production for past 6 month, works like a charm 💙 hope it helps someone |
What's the migration process like for users of |
|
@mattbbc just delete everything There are some limitations, coming mainly from NextJS's standalone option. Primarily: you must use So depends on your application really. But 90% of projects and users should be fine. |
|
I guess what I'm wondering is how to manage a project with serverless.yml configs for different deployment environments that co-ordinate S3 buckets and Cloudfront configuration - region, domains, aliases, ACLs, certificates, header forwarding and so on. Can you configure that with this, or is it something that should just be handled in the AWS console? |
You can extends CDK constructs provided or alter resources created via CLI in Serverless, the options are really unlimited I would say 😁 PS. Cloudfront, Route53, routing, headers are all managed by default so you don't need to tweak it if you don't need to. |
Here's how we do it. First run in a new environment:
Subsequent runs in an environment:
Once you let serverless create the cloudfront, edge lambdas, etc. - you can add certs, custom cloudfront settings and the like. The serverless job won't overwrite them unless you run serverless remove. Just don't change the names of anything. This is our serverless.yml: This our buildspec.yml for AWS codebuild: And the npm command in package.json: |
|
there's a nice article here: https://dev.to/kumo/deploying-nextjs-13-with-amplify-cdk-1dgd on how to deploy next 13 with cdk and amplify, you can also check out swarmion with you wanna use a monorepo https://github.com/swarmion/swarmion/tree/main/examples/swarmion-with-next |
|
New project for Next.js 13 I've been using: https://github.com/serverless-stack/open-next It packages the .next folder in two Lambdas (server and image optimization), on Edge Lambda (middleware), and assets, just like this does, with the big difference that image optimization and the default Lambda are no longer edge, but that is not a big problem, considering that you should be caching using CloudFront anyways. This begs the question though, is edge Next.js really worth the pain in AWS if it requires weeks of research and implementation that has the potential of becoming stale due to relying on open-source projects that can be easily abandoned? I've been thinking a lot about that lately. For context, I've used this in a large production application for about a year now, adding ISR on our own when we needed it. But as a developer and a devops engineer, I think I'd sleep better at night if I was deploying to Vercel or to Docker, because I know that version changes won't completely lock me to a lower version of Next.js. |
|
@juliocorzo I'd recommend using |
|
This might be useful for people looking to deploy next-js on serverless: https://github.com/awslabs/aws-lambda-web-adapter |
|
Hi everyone. With my team, we created a terraform module to deploy next.js apps on AWS. Feel free to try it |
|
Seems like SST -- specifically, using NestjsSite (which uses their open-next) -- is the smart choice. Thanks to all for testing, going to give it a try. Only question so far: Has anyone actually moved their prod site/domain over? Are there any gotchas, or is it just a matter of pointing your A record to the new Cloudfront URL? |
|
@patricktyndall If you're moving from this solution to SST, it won't be as simple, because, as far as I know, SST assumes you're going to be using Next.js 13. The transition from 12 to 13 is not as straightforward. Additionally, your deployment infrastructure will also change, while the general idea will be the same. It depends on how you plan to deploy prod changes (via SST CLI or via CodePipeline, or both.) I'd like to echo what I said in February (despite it sounding like a defeatist stance.) If you want to adopt the latest and greatest in Next.js, do not go for a serverless solution. Go for ECS or Vercel. Next.js 14 just got announced and I worry that serverless solutions will not give you all the functionality that was added soon. |
|
it is possible to use aws-lambda-adapter as a general solution for webservers within lambdas: https://github.com/awslabs/aws-lambda-web-adapter But one needs to package nextjs as docker image to lambda service. At least it works with nextjs 13 but most likely will also work for 14 since it is just running nextjs within a docker container basically. For low budget hobby projects I find it great where longer cold starts are not a deal breaker. |
|
At that point you might as well use fly.io which can scale your containers to 0 unlike AWS. |
|
@juliocorzo thanks for flagging the Next >=13 requirement with SST (though I haven't found concrete docs on this requirement and am tempted to try it with 12). Deploying via SST CLI from our own CI setup seems best -- I see no reason to directly integrate source control tools with deployment tools. Either way, in our case, the benefits of a serverless deployment to our own AWS cloud are hard to beat. We're happy to remain a few months behind Next.js for new features (we usually wait anyways), as long as we know that the project is well-supported and will get there eventually. You're probably right that deploying using vercel or our own containers is probably the more "mature" solution though. I just think that the full benefits of next.js (which is OSS) -- specifically the ability to leverage serverless/CDNs for static pages -- shouldn't be coupled to a single company (and shouldn't cost you control of your own architecture). I also don't think non-edge lambda is a real contender for webserver if latency is a concern |
|
You can still use next12 w/ SST, but there might be some gotchas. |
and others
I just wanted to open this issue as a feature request. This project appears to be dead, and I need to migrate my current application to something new that is active and supports new NEXT JS features such as middleware, possibly Vercel! But I'd really like to know the status of this project. I know that the maintainers are very busy and don't have time to work on this project. Any plans for the future? Also, it would be nice to let us know If anyone has already migrated to something else, share your thoughts!
The text was updated successfully, but these errors were encountered: