Deprecating support for Serverless Framework Deployments to AWS Lambdas

Announcements
1

Update April 2023: We are not dropping Serverless-AWS deploy — we will be deprecating it in version 5.0. This means:

  • both the associated setup and deploy commands will remain in the framework as is; when setup is 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.

What happened?

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
Flightcontrol Docs
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.

Baremetal
Baremetal Docs
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
Render Docs
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!

Serverless

Netlify
Netlify Docs
The OG Jamstack deployment for Redwood. Lots of add-on bells and whistles like long-running jobs and analytics.

Vercel
Vercel Docs
The home of Next.js and a snappy hosting experience.

Edgio (formerly Layer0)
Edg.io Docs
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.

1 Like
2

Hi David,

As you may know, I’m heavily dependent on the Serverless Framework, so this comes as a huge blow.

I’d like to understand better exactly what the issue is. I haven’t experienced any issue in using RedwoodJS with Serverless on NodeJS 16. Literally just change the ‘runtime’ key in the serverless.yml file and that’s it. Serverless just incorporates that into the CloudFormation stack it creates and Serverless doesn’t seem to really have anything to do with the version of Node. Of course, there may be some corner of Serverless that I’m not exercising in my usage so perhaps there’s something I’m missing.

But before I consider what the options are here, exactly what is the issue? The Serverless docs you link to in your announcement don’t say anything about being restricted to a particular version of Node, so I’m still unclear on this.

Regards,

– Jay

3

Ah, thank you for letting me know, Jay, However we navigate this, I promise we won’t leave you out to dry.

This is going to be a long, mutli-week RC process. We have time.

Issues

First some context, for all our supported providers, we run automated CI/CD on every next version. (Deploy Target CI Repo, Removed Serverless here) This also includes uptime monitoring of both the API and Web. Our deploys looked successful, but when manually ran deploy locally we saw an error during rw deploy serverless that the runtime value (Node16) was not valid. The error provided a list of valid values and Node 14 is the latest. (You’re right. The docs were completely unhelpful.) Deploy didn’t fail, but we’re having trouble determining if it actually succeeded. On the front-end, our browser monitoring service, Pingdom, has been down for 2 months (it’s been a frustrating back and forth) — API uptime was working so I assumed things were ok. I finally switched over to Checkly and realized our serverless deployment was throwing CORS errors. After chasing my tail a bit, the best I could determine is that our functions weren’t deploying correctly. I discovered the error during rw deploy serverless when I was debugging CORS.

I was moving quickly and all this is likely fixable. But the reality is that our CI/CD for Serverless has been flaky + challenging since day 1. Admittedly, even the individuals at Serverless who worked with us at the time said it wasn’t designed for SPAs and they were working on a better solution (does that option exist yet?). This is why you can’t use the Serverless Dashboard CI/CD with Redwood, for example; we had to roll our own.

Ways Forward

I don’t have much data about usage, so one thing I’m trying to determine here is community dependency. Also, are people interested + available in taking lead on supporting Redwood + Serverless.

Regardless, there are plenty of ways forward:

  1. fix it or, better yet, make it better
  2. deprecate and/or make it clear the setup and deploy commands work but it’s no longer tested with every release (i.e. no longer “official”)
  3. create a stand-alone package containing the deploy script (or show people how to copy/paste code and use via yarn script)
  4. migrate projects to another provider (Flightcontrol deploys to Fargate, which is AWS serverless containers and we’re hearing great things from startups)

What did I miss anything?

Your Project

@joconor can you tell me more about your project?

  • why Serverless: is it about cost or design requirement or …?
  • what version of Redwood?
  • did you add any complexity to your Serverless deploy config?
  • what is your DB provider? (e.g. AWS RDS…)
  • do you have Auth? If so what’s your setup?
  • anything else that might be helpful?

Huge thank you for addressing this so quickly. Let’s continue the conversation and find a way forward!

4

Hi @thedavid

We as well use Serverless for our deployments.

  • why Serverless:
    Since we use AWS and wanted to keep costs down we opted for serverless
  • what version of Redwood?
    4.1.4
  • did you add any complexity to your Serverless deploy config?
    • Yes, all AWS services except Parameter Store are included in the serverless files
    • We also have an additional side for python-related backend tasks which has an additional serverless file
    • We use a plugin “serverless-local-schedule” which creates cron jobs with a localized time
  • what is your DB provider? Postgres
  • anything else that might be helpful?
    We use yarn redwood deploy serverless --pack-only and then yarn serverless deploy --stage production because we have some additional steps in between. So if it’s possible to keep the first part somehow, that would be enough for us.

Best,
Michael

1 Like
5

Thanks @sladomic Very helpful.

FYI: I updated my questions:

  • what is your DB provider? (e.g. AWS RDS…)
  • do you have Auth? If so what’s your setup?

Our CI/CD deploys using dbAuth. Which may by adding to the complexity for this deployment provider.

6

updated :slight_smile:

  • why Serverless:
    Since we use AWS and wanted to keep costs down we opted for serverless
  • what version of Redwood?
    4.1.4
  • did you add any complexity to your Serverless deploy config?
    • Yes, all AWS services except Parameter Store are included in the serverless files
    • We also have an additional side for python-related backend tasks which has an additional serverless file
    • We use a plugin “serverless-local-schedule” which creates cron jobs with a localized time
  • what is your DB provider? AWS RDS Postgres (not serverless at the moment because it isn’t supported yet in our region)
  • do you have Auth? If so what’s your setup?
    Azure Active Directory (the only thing not on AWS)
  • anything else that might be helpful?
    We use yarn redwood deploy serverless --pack-only and then yarn serverless deploy --stage production because we have some additional steps in between. So if it’s possible to keep the first part somehow, that would be enough for us.
1 Like
7

Hi @thedavid,
Thanks for continuing this conversation.

  • why Serverless: is it about cost or design requirement or …?
    • Both cost requirement as well as ability to scale without having to switch providers (and by scale, I’m including the ability to include other AWS services in our deploy). We can start with zero cost while in development due to the generous AWS allowance on Lambda & related services
  • what version of Redwood?
    • RedwoodJS version 4.4.2 (will do the 4.4.3 update shortly)
  • did you add any complexity to your Serverless deploy config?
    • Updated NodeJS version without any problem (not seeing the error you report)
    • Working on CORS now, don’t have that working yet.
    • Have a function defined to receive Google PubSub messages in addition to graphql and auth
    • I anticipate that eventually we will put the Lambda functions as well as an AWS hosted PostgreSQL db within a VPC, but we’re not there yet. The fact that this direction is open to us with Serverless Framework is a big appeal.
  • what is your DB provider? (e.g. AWS RDS…)
    • Currently PostgreSQL on Railway.
    • Need to do our eval of the best approach to AWS hosted PostgreSQL but will be doing some flavor of AWS PostgreSQL
  • do you have Auth? If so what’s your setup?
    • Yes. dbAuth. Banging my head against the CORS issue right now.
  • anything else that might be helpful?
    • AWS is definitely the 800lb gorilla in the serverless space. Given Redwood’s mission to enable startups, there’s a natural fit here even despite some technical hurdles. Serverless Framework has made it easier to deploy to AWS, but I’m not completely wedded to Serverless Framework. I’m comfortable with Serverless Framework, in that I’ve worked with it in the past (and that was a huge factor in choosing RedwoodJS). If something like Serverless Stack or directly using the AWS CloudFormation SDK were to work better, I think we could manage that. But deploying directly to AWS without additional cost is a must.
    • Our workflow makes heavy use of the stage feature of AWS & Serverless
8

Redwood deploy via Serverless Framework has had numerous rough edges since day 1. I’m not in a position to fix those issues myself, but I would very much like to work with other Redwood users who are currently (or interested in) deploying using Serverless.
There are some issues that go beyond just the deploy, but do impact the deploy, such as Redwood’s use of dotenv and dotenv-defaults that play funny with other things that use those packages.
And clearly, the Serverless deploy hasn’t been touched in some time, as evidenced by the deprecation warnings that deploying via serverless currently gives.
I think if a few of us put our heads together we can likely make serverless deploys work smoothly for rwjs

9

I’m going to venture a guess that dbAuth and CORS may be the major issues in making a Serverless deploy go smoothly (i.e., not the supported version of NodeJS). I haven’t solved the CORS issue for my application yet, but I’m confident I will. But I do expect it will be a bit janky. Because of our use of multiple stages, we typically work with both the AWS assigned API Gateway URL and the Cloudfront URL. Since the Cloudfront URL will be assigned on first deploy, there’s a circular dependency where the front-end needs the API Gateway URL baked in, but the back-end needs the Cloudfront URL set up for CORS. Yes, a bit messy, but doable.

10

Our Project

Hello David,

My company uses the Serverless Framework deploy for RedwoodJS, and we will be sad to have to see it go. We would love to see if we can help support in the future.

  • why Serverless:
  • We use Serverless because it allowed us to easily get into AWS (our provider) for scaling. Similar to another reply, we also have other services that we deploy using Serverless including AWS Fargate containers. We wanted the ability to tweak the underlying Lambdas, and loved Serverless’ claim that we could deploy to other providers including Azure.
  • what version of Redwood?
  • Currently, 4.0.1
  • did you add any complexity to your Serverless deploy config?
  • Web: no.
  • API: yes, we have an AWS S3 bucket which holds some certs we use to connect to a Temporal instance. Also, envs + cors.
  • what is your DB provider? (e.g. AWS RDS…)
  • AWS Postgres RDS
  • do you have Auth? If so what’s your setup?
  • Yes, we use Azure SSO. No problems here.
  • anything else that might be helpful?
  • We like the flexibility of Serverless to tweak the underlying Lambda.
11

Take a look at what we had to do in the CI/CD deploy project:

^^ You can explore that commit but might be better off cloning and reverting to explore.

There is config you need to add in the Serverless config file. As well as Redwood API (Auth function, GraphQL, etc).

Tricky indeed.

12

Keep the use-cases coming, everyone! Very helpful.

Worst case, we will not remove Serverless deploy but instead deprecate it. In practicality this will mean:

  • we won’t be running CI/CD; so no guarantees
  • we’ll indicate rw setup aws-serverless is deprecated
  • we’ll keep the rw deploy ... intact

I think the future here is using AWS CDK. @peterp has explored this and is very optimistic. And Serverless (company) has support although they don’t advertise it very well — “Serverless Lift”:

Note the “Single page app” section further down the page.

Still just processing and reacting as we go. Any thoughts or comments to the above?

1 Like
13

I’ve been lurking in this thread for a while now. I just switched to writing a new project in Redwood and the Lambda possibility was one of the selling points. Vercel and Netlify are great tools but when building for clients it’s often easiest to just hand them over a single AWS or GCP account where all resources are hosted. AWS Fargate is an option but it’s preferable to run serverless for some services that have high usage during the limited time during the day and it also makes branch previews very easy to set up.

As you and @peterp are looking into AWS CDK, I suggest looking at Pulumi at the same time if you haven’t already. That way it might be possible to have some shared code/plugins for running on GCP or Azure too. With Pulumi I don’t think there is any need to use the Serverless platform at all.

Adding Pulumi could be an infra extension to Redwood allowing an opinionated way to handle your resources and build it into the deploy step. Essentially allowing users to handle resources such as crons, queues, db setup and more as part of existing CI flows.

14

Hi @thedavid,

I would definitely suggest a deprecation period. And I would recommend to the RedwoodJS team that you consider adopting some sort of official policy of deprecation. I think this would go a long way toward giving adopters confidence that Redwood is a stable platform to build on.

Regarding adopting AWS CDK as the way forward, that does sound promising. AWS CDK didn’t exist when I first used Serverless, and Serverless has served my limited needs to date so I haven’t had reason to get my hands dirty with AWS CDK. I’m certainly willing to!

The RedwoodJS Serverless deploy is already using “Serverless Lift” for the frontend deploy. If Serverless Lift makes sense as the path to adopting AWS CDK, I think that makes a deprecation period for the current Serverless implementation even more compelling.

I think it would be helpful (and I’d like to participate in this) to better identify the issues involved in doing a deploy to AWS with dbAuth support. I don’t think there’s any issue with NodeJS versions – @thedavid how can we nail down why you’re seeing a warning/error, but I’m not?.

15

If we’re going to start recommending CDK we should also consider taking a look at SST, it’s an extension of CDK that makes the DX much nicer.

3 Likes
16

Hello, @thedavid

We are using serverless deployment here for our api side.

When we decided to bump to Node18, I thought it was straightforward and changed the runtime in the serverless.yml file to nodejs18.x. I also couldn’t find in the serverless docs any reference about supported runtimes.

Now, our tests env already run Node 18. Seems ok.

  • why Serverless: is it about cost or design requirement or …?
    Cost was important but we decided to have the most control and flexibility as possible. So we choose AWS.
  • what version of Redwood?
    4.2.2
  • did you add any complexity to your Serverless deploy config?
    Yes. We have a Redis instance for graphql caching. Because of using Redis, we had to create a VPC to put our lambdas. And because of using a VPC, we had to create an Internet Gateway to access the Internet inside a VPC. All this infrastructure is in CloudFormation templates included as resources in the serverless file
  • what is your DB provider? (e.g. AWS RDS…)
    AWS RDS
  • do you have Auth? If so what’s your setup?
    DB Auth
  • anything else that might be helpful?
    We only use for api side. We host our frontend using AWS Amplify.

Update: Now we got production env running Node 18 too.

Update 2: We also use Node 18 in our deployment Github Action

2 Likes
17

Wow, this is disappointing to hear.

  • why Serverless: is it about cost or design requirement or …?
    • I want to deploy to AWS. I have many years of experience with it and want to leverage that instead of learning an entirely new platform. Honestly I didn’t think deploying to AWS was some controversial opinion, so it surprises me that Redwood is deprecating the one pathway to do that (afaik?). If AWS wasn’t an option, there is a good chance I would have skipped RedwoodJS.
  • what version of Redwood?
    • 4.4.3
  • did you add any complexity to your Serverless deploy config?
    • Yes, quite a bit on the API side. I create VPCs, gateways, and the database using serverless.yml.
    • I also have a custom deploy process that does assorted setup, then yarn rw deploy sls --stage "$STAGE", then cleanup
  • what is your DB provider? (e.g. AWS RDS…)
    • AWS RDS Postgres
  • do you have Auth? If so what’s your setup?
    • Not yet, I planned on doing custom auth

If you decide to go through with deprecating it, then I will either not upgrade, or patch your code so that I can continue using my current deploy process.

18

Hello fellow Redwood Users deploying with Serverless:

I’m hoping to get some clarity from @thedavid on the actual problems eventually. I believe the NodeJS version thing is a red herring. From what I’ve observed, it looks more like the AWS two-part deploy, with front-end and back-end each living in their own domain (CloudFront assigned URL & API Gateway assigned URL, respectively) causes a lot of pain for their CI/CD workflow with dbAuth.

Front-end & back-end being in separate domains introduces CORS issues, as well as third-party cookie issues for dbAuth. Addressing the CORS issue is akin to resolving a circular dependency. Already, the front-end needs to know the back-end URL, but for CORS, the back-end also needs to be configured with the domain of the front-end. The Serverless deploy already has the --first-run flag to handle connecting the front-end to the back-end, but configuring CORS means, at a minimum, doing a deploy, finding out the CloudFront URL, editing code and serverless.yml with the front-end origin then doing another deploy with the code & configuration fixes.

IMO, the third-party cookie issue is worse. I don’t know about the RWJS CI/CD pipeline, but in real-world usage, it’s not practical to require browsers to accept third party cookies. Of course, for production, one would almost certainly put both front & back ends in the same domain. The Serverless Framework doesn’t “just do” this.

Using the Serverless ‘stage’ concept to spin up new environments with minimal fuss is a huge advantage, but the current state of the Serverless deploy configuration leaves too much ‘fuss’ to deal with manually.

I’ve seen a lot of people suggest alternate approaches (Serverless Stack, AWS CDK, etc), but (IMO) until the issues with the Serverless deploy are correctly identified it doesn’t make sense to look at other solutions. If I’ve correctly identified the issues as being CORS & third-party cookie complications arising from front-end & back-end living in separate domains, I don’t believe solutions like SST or CDK will “just do” the necessary work to resolve that. But I do think the issue of putting both front-end & back-end under a single domain is solvable, hopefully with minimal fuss, with any of the AWS deploy solutions, including Serverless Framework.

19
  • do you have Auth? If so what’s your setup?
    DB Auth

I’m curious how, and if, you are handling Auth + CORS for your setup. I’m imagining you are using the dbAuth-specific API function and implemented your own integration for the AWS Amplify app.

Because we’ve been having challenges navigating CORS with dbAuth, could you share snippets and how/where you had to manage CORS? (e.g. serverless config file, dbAuth function, GraphQL, etc.)

20

Thank you @sean-ac Very helpful. But let me clarify a few things:

I want to deploy to AWS. I have many years of experience with it and want to leverage that instead of learning an entirely new platform. Honestly I didn’t think deploying to AWS was some controversial opinion, so it surprises me that Redwood is deprecating the one pathway to do that (afaik?). If AWS wasn’t an option, there is a good chance I would have skipped RedwoodJS.

^^ Most startups (and they are many) deploy to AWS directly. They just set it up themselves. I (we) think AWS is a great option. I just don’t think Serverless Framework is the best option for Redwood. And, admittedly, neither did the people we worked with at Serverless when we created it over a year ago — there just weren’t other/better deploy-to-lambdas orchestration services availabe so we gave it a go.

Frankly, my favorite deploy-to-AWS service right now is Flightcontrol, which deploys to Fargate. But there are others in the hopper.

Not yet, I planned on doing custom auth

^^ Keep us posted as this is where you might run into challenges with CORS

If you decide to go through with deprecating it, then I will either not upgrade, or patch your code so that I can continue using my current deploy process.

^^ Deprecation != dropping. (See above dialogue about no longer dropping and what Deprecation would mean.) Nothing would change on your end being able to run yarn rw deploy serverless.