Update April 2023: We are not dropping Serverless-AWS deploy — we will be deprecating it in version 5.0. This means:
- both the associated
deploycommands will remain in the framework as is; when
setupis run, there will be a “deprecation” message
- we will no longer run CI/CD on the Serverless-AWS deployments, which means we are no longer guaranteeing this deploy works with each new version
- we are exploring better options to deploy directly to AWS Lambdas; the current deploy commands will not be removed until we find a replacement
The core CORS problem might be isolated to dbAuth and cookies. Using other Auth providers might be an adequate workaround.
In the coming release of Redwood v5, we will be completely dropping built-in deployment support for the Serverless Framework (which deploys to AWS Lambdas). Here are the related Redwood Docs.
In reality, this deploy provider hasn’t worked with Redwood since v4 — we just now diagnosed an issue related to Serverless Framework AWS Lambdas runtime support.
The Serverless Framework only supports deploying to AWS Lambdas using Node.js version 14. (See this guide.) In Redwood v4, we bumped Node.js support to v16-18. And we bumped the API build target to Node.js v16.9
We should have seen this when we were preparing v4 — we’ve diagnosed the miss and patched a CI/CD hole (where we could). Regardless, we cannot resolve this incompatibility. Thus, we are dropping support.
Frankly, one of our ongoing frustrations with AWS Lambdas (and providers deploying to Lambdas) is the lengthy delay between Node.js LTS releases and runtime support for those releases. Given the transparency and incredible organization of the Node.js Release Schedule, this 6-month to year+ lag time just feels like a miss.
My project is affected! Now, what should I do?
First off, please reply to this thread or get in touch by sending me or anyone on the Core Team a message. We’re already bummed on your behalf — we’d like to help if we can.
More importantly, what’s amazing about Redwood is that you can deploy using another provider without making any architectural changes to your codebase. So, yes, you can deploy directly to AWS Lamdbas and simply drop the Serverless Framework as a middleman provider. We’d recommend you take a look at any of these other providers, many of which provide better support for Redwood applications.
Redwood Built-in Deployment Providers
You can deploy Redwood anywhere you can run a Fastify server or build + deploy an AWS Lambda function. Just BYO DevOps and get to it!
If you’re looking for something with a little less DevOps overhead, below is our list of fantastic providers that are the “built-in” deployment choices we optimize and run CI/CD checks for with every release.
Redwood Deployment Documentation
Traditional Servers (aka Fastify-first or “Serverful”)
Flightcontrol is a provider that orchestrates Jamstack-like deployment to AWS, using Fargate serverless containers and the database of your choice. You get serverless + containers without the hassle of DevOps.
You’ll still need to do some DevOps yourself, but Baremetal makes it a snap to deploy directly to an EC2 server that uses PM2 to manage Node.
Render is a unified cloud to build and run all your apps and websites with free SSL, a global CDN, private networks, and auto-deploys from Git — database included!
The OG Jamstack deployment for Redwood. Lots of add-on bells and whistles like long-running jobs and analytics.
The home of Next.js and a snappy hosting experience.
Edgio (formerly Layer0)
Edgio extends the capabilities of a traditional CDN by not only hosting your static content but also providing server-side rendering for progressive web applications as well as caching both your APIs and HTML at the network edge to provide your users with the fastest browsing experience.