HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
CodeGenieApp
serverless-express
JavaScript2016–2026
CodeGenieApp / serverless-express

serverless-express

Run Express and other Node.js frameworks on AWS Serverless technologies such as Lambda, API Gateway, Lambda@Edge, and more.

8Distinct people
20Mentions
2Explicit recommenders
5.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Run Express and other Node.js frameworks on AWS Serverless technologies such as Lambda, API Gateway, Lambda@Edge, and more.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

In addition to the answers posted already lets clear up what seems to be a bit of confusion in the question. if you google serverless you'll find 2 seperate things. 1. a…

wh-uws used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year20 dated mentions

Observed mentions: 2016-10-11 14:12:11 UTC to 2026-10-13 19:24:32 UTC.

02462016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC202
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC716
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC707
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

20 sources
Something very similar to this was already possible via serverless-express for node: https://github.com/CodeGenieApp/serverless-express This wraps Lambda's 'handler' function and allows express to run on top of it, essentially you get a node web server with no persistence between requests which usually isn't a good thing to rely on, but you can also kinda have that with persistent tcp connections. Of course since this is not real HTTP, things like WebSocket aren't available, but it's good enough to build a CRUD backend or two. Similar libs exist for other runtimes as well.
In AWS Lambda Web Functions
wh-uws·Jul 31, 2020Recommendation phrase
In addition to the answers posted already lets clear up what seems to be a bit of confusion in the question. if you google serverless you'll find 2 seperate things. 1. a general name and concept for a user only having to worry about the services they deploy at the application layer (without having to worry about setting up servers and such behind it) 2. a framework for generalizing how to package up serverless functions. (the name overload is super confusing took me a while when I wanted to setup 1) So you question is comparing apples to oranges. In that you can use serverless framework to deploy Django,Flask,ExpressJS and etc applications to serverless systems i.e. AWS Lambda. for instance I have 2 services I use basically every day that are built on this https://github.com/awslabs/aws-serverless-express so I use serverless framework to
Read the rest
deploy nodejs/express applications
In Ask HN: Why use Serverless to build webapps
scarface74·Jun 28, 2020Recommendation phrase
Disclaimer: I work for AWS Professional Services but I just started. All of my experience comes from working at outside companies. From the perspective of an outside, boots on the ground Developer/architect, I’ve never worried about “vendor lock in”, I believe you should choose your infrastructure wisely and go all in. But, I do worry about “Lambda lock-in” for APIs. I like the optionality of being able to deploy my APIs anywhere just by changing the CI/CD pipeline. That’s why I recommend using proxy integration. Every language supported by Lambda has a method to just throw your standard API in lambda without tying yourself to it. Here is an example for Node/Express https://github.com/awslabs/aws-serverless-express Python/Flask (ignore the DDB part): https://www.serverless.com/blog/flask-python-rest-api-server... C#/Web API https://aws.am
Read the rest
In How we got our AWS bill to around 2% of revenue
What about writing CF to begin with for all your Lambda functions and setting up all their permissions to work alongside whatever other resources you have? There are no “all of your lambda functions” with the proxy integration. You write your standard Node/Express, C#/WebAPI, Python/Flask API as you normally would and add two or three lines of code that translates the lambda event to the form your framework expects. I’ve seen similar proxy handlers for PHP, and Ruby. I am sure there is one for Java. As far as setting up your permissions, you would have to create the same roles regardless and attach them to your EC2 instance or Fargate definition. But as far the CF template. Here you go: https://github.com/awslabs/aws-serverless-express/blob/maste... Just make sure your build artifacts end up in the path specified by the CodeUri and chang
Read the rest
e your runtime to match your language. I’ve used this same template for JS, C#, and Python. Nobody said anything about Docker or Fargate. This has nothing to do with the topic. My problems had no need for using Docker. Do you randomly pick a tool kit and just hope it works out? I suspect you're not really working at scale and costs aren't a concern. You’re using your standard framework that you would usually use. You can use whatever deployment pipeline just as easily to deploy to EC2 with no code changes. Great job. We are all proud of you I guess, but this is not how engineering works, especially when you're building at scale. Actually it is. Since you are using a standard framework choose whatever deployment target you want.... Have you looked into Express and what dependencies it has, or do you just randomly pick the new framework of the week? I don't mean this as an attack, but I'm more than slightly annoyed that you keep referring to Node and Express, when that has nothing to do with the problems I'm trying to solve. I also mentioned C# and Python. But as far as Java/Spring. Here you go. https://github.com/awslabs/aws-serverless-java-container/wik... The funny thing is you've written out all these lengthy posts but never stopped to ask about whatever constraints the system has. You started with the solution and are basically now looking at one of my constraints (JVM ecosystem) and are saying it's not a good choice. I’ve also just posted a Java solution. The constraints of Lambda are well known and separate from Java - 15 minute runtime, limited CPU/Memory options and a 512MB limit of local TMP storage. In the real world, we often don't have the ability to randomly swap out a language. There's enough properly tested code that already exists or a massive code base that entire teams are supporting. They're not going to drop that just so they can go pick up a shiny new framework or product offering. LOL. My suggestion didn’t require “switching out the language”. Proxy integration works with every supported language - including Java. It also works with languages like PHP that are not supported via custom runtimes and third party open source solutions.
In What a typical serverless architecture looks like in AWS
I agree completely. We have APIs that are both used by our website and our external customers (we sell our API for our customers to integrate with their websites and mobile apps) and for batch loads for internal use. We deploy our APIs to Fargate for low, predictable latency for our customers and to Lambda [1] which handles scaling up like crazy and scaling down to 0 for internal use but where latency isn’t a concern. Our pipeline deploys to both. [1] As far as being “locked into lambda”, that’s not a concern. With API Gateway “proxy integration” you just add three or four lines of code to your Node/Express, C#/WebAPI, Python/Flask code and you can deploy your code as is to lambda. It’s just a separate entry point. https://github.com/awslabs/aws-serverless-express https://aws.amazon.com/blogs/developer/deploy-an-existing-as...
In The DynamoDB Book: Data Modeling with NoSQL and DynamoDB
So now what happens when you need to migrate a massive amount of data while keeping everything online? Let’s say you want to trigger some code to run when a file gets dropped on S3. Are you going to spend Developer time trying to come up with a bespoke solution or are you just going to trigger a lambda on S3? Are you going to host your own highly available queueing and messaging system and have to run them on EC2? Sure it’s “easy” to replace your entire networking infrastructure and run it on another provider, but how many man hours is that going to take? Have you actually costed out how much a large migration would take? As far as using Lambda for an API, you can literally add three or four lines of code and use “proxy integration” to deploy your entire Node/Express, Python/Flask/Django, C#/WebAPI app on lambda and without changing any c
Read the rest
ode, deploy it anywhere else as you would any other API. Here is a Node Express example. https://github.com/awslabs/aws-serverless-express
In Principles for Building New SaaS Products on AWS
Let me give you another example. We have a Jenkins server for builds. Most of the time, you push code and the build starts immediately. However, at times we have 10 builds in the queue and you’re sitting there waiting for your small build behind larger builds. On the other hand, we’ve started moving to CodeBuild “Serverless builds”. When we aren’t running builds, we aren’t paying for it. However when crunch time comes, we can run up to 50 builds simultaneously (you can request a larger limit). How much would it cost to have build servers that could handle peak demand and how much of a waste would it be to have that server sitting idle? And if you’re worried about the difference in cost between $100 and $10, you’re not running a business. Will that $10 a month server scale up with demand? As far as it taking “two or three weeks” - “its a
Read the rest
poor craftsmen who blames his tools”. Don’t blame AWS for the missing skillset of your developers. There is no reason that it should take your developers any longer to build an API with lambda instead of a server. In fact, you can host the same APIs with lambda by only adding two or three lines of code and using proxy integration. For instance in Node: https://github.com/awslabs/aws-serverless-express
In A serverless email server on AWS using S3 and SES
Not only is it sort of sneering (if you're that small) Lambdas always free tier is 1 million requests per month and 400Gb/seconds per month. https://aws.amazon.com/lambda/pricing/ It takes a lot to have any meaningful lambda bill. That in no way is meant to be an insult. If you’re spending even $100/month on lambda, you’re running a successful website. It's hard enough starting a business without learning a whole new tech stack. If you know how to write a program and create a function that takes two parameters - a payload and context argument - you know lambda. You can write it in the console if you’re using Python or Node and just run it from there. Even if you don’t want to learn that, you can host your standard C#/WebAPI, Python/Django/Flask, Node/Express API on lambda just by adding code and changing your endpoint. Several comments f
Read the rest
ocused on it'd just be better to start off with a Rails app, it's quick, it's easy and it's understood. There is also code to wrap a Rails app and run it on lambda.... And really, is lambda appropriate for anything more than a very focused niche app? I mean, try writing all the usual things you need to slot into a SaaS on it, billing, user management, signup, admin reports, admin functionality, emails, multi-tenancy, custom domains, etc. etc. Even a 20 user, internal, enterprise app needs most of that functionality Yes. Especially in today’s world of client side frameworks and microservices, you host your static assets like Javascript, css, and HTML in S3 and call server side APIs hosted on lambda. Put on top of that, you're forced to use a particular, proprietary tech stack and lock yourself into something that might very well die in a couple of years. Well, two things. What’s more likely to die in two years / your startup or AWS? Second, you can host your standard API just by adding four lines of code and you don’t have to make any changes to host it in Docker or on a VM. There is a way to do this in every language that lambda natively supports. For instance for Node: https://github.com/awslabs/aws-serverless-express I have a Node/Express app that gets deployed to both lambda and Fargate (Serverless Docker) when I push it. The only difference is that lambda uses one entry point and Docker uses another. I’ve done something similar with C# https://aws.amazon.com/blogs/developer/deploy-an-existing-as... Where it is deployed to both lambda and a Windows server running IIS. I can be a lot more productive with all the resources that AWS has to offer when all I have to do is provision resources with a CloudFormation template and instead of doing the grunt work of infrastructure administration I can concentrate on writing software.
In The Amazon Premium
No. I’m of the belief that when you choose a platform, go all in. Given a choice between the Serverless platform and AWS’s Serverless Application Model, I would choose SAM. I also work for a company that pays for the business support plan, they will help you to an extent with any weirdness in their own platform - but not with third party utilities. Another advantage with using SAM, is that you can create and configure your lambda/API Gateway from the web console and then export your SAM/CloudFormation template. All that being said, for APIs, I don’t use either. I would recommend using standard frameworks like C#/WebAPI, JS/Node, Python/Flask/Django instead and using the proxy integration libraries that AWS provides. It lets you develop/debug locally like you are accustom to and it gives you the optionality to move your APIs to Fargate (Se
Read the rest
rverless Docker) or EC2 instances without any code changes: C#/Web API https://aws.amazon.com/blogs/developer/deploy-an-existing-as... Node: https://github.com/awslabs/aws-serverless-express Python/Flask https://dev.to/apcelent/deploying-flask-on-aws-lambda-4k42 I’ve been told that there are similar frameworks for other languages but those are the three that I use. If you have any other questions, feel free to email me. My address is in my profile. I’m not a consultant trying to sell anything....
In Ask HN: How do you make sure your servers are up as a single founder?
Study for the developer cert and do some hands on work. Again, it’s not because I believe in the importance of “getting the certification”, it’s about the guided learning path. I was able to get experience through my job, but if that isn’t an option for you, just build something. There are some really good, cheap, thorough Udemy course (no affiliation, not affilliate links): This course goes over API Gateway, lambda, DynamoDB and a quick overview of how to create a NodeJS Serverless app: https://www.udemy.com/share/1010qKBUQdeF5TQn4=/ That is the “right way” to create a Serverless API, but if you want to take a regular old Node/Express API and run through lambda you can use the lambda proxy integration: https://github.com/awslabs/aws-serverless-express There are similar frameworks for Python/Django and C#/WebAPI And for the love of all t
Read the rest
hat is holy, learn CloudFormation and don’t create resources manually. https://www.udemy.com/share/1011JEBUQdeF5TQn4=/ If you have any questions, an email address is in my profile.
In Changes to the Red Hat Certified Engineer program
https://github.com/awslabs/aws-serverless-express With no code changes, you can deploy a standard Node/Express app as either a lambda service or a standard Express app. There are a frameworks like this from AWS for all supported languages. It’s well documented how to use the API Gateway lambda proxy feature. For non API lambdas. The only thing you have to do is add an entry point method that takes has two arguments - a JSON event object and a lambda context. I have another app that can be deployed as a Windows .Net Core service or lambda based on the CI/CD pipeline.
In Cloud Programming Simplified: A Berkeley View on Serverless Computing
This is not true. For example: Using this template. https://github.com/awslabs/aws-serverless-express I’ve been able to deploy the same code as a regular Node/Express app and a lambda with no code changes just by changing my CI/CD Pipeline slightly. You can do the same with any supported language. With all of the AWS services we depend on, our APIs are the easiest to transition. And despite the dreams of techies more than likely after awhile, you aren’t going to change your underlying infrastructure. You are always locked into your infrastructure choices.
In “Lambda and serverless is one of the worst forms of proprietary lock-in” (2017)

Showing the 15 most recent of 20 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.