AWS Lambda Now Supports Node.js Version 8.10!

With the state of serverless growing at an exponential rate during the last year, it’s no surprise developers across the globe have flocked to use AWS Lambda as their main serverless compute engine. AWS has a steady track record of covering all the main needs of developers, DevOps engineers and even C-level tech executives. Hell, I’ve been using it for a couple of years, and still haven’t come close to check out even half of their offering.

Disappointment turned to joy

So, after all that, tell me, why haven’t we had the joy of using the newest version of Node.js on AWS Lambda? Strange indeed. The de facto go-to compute service for serverless has limited Node.js developers to use outdated versions of their favorite language *sad face*. All that changes now, with the public release of a new supported version of Node.js. To be more precise, it’s version 8.10. We now finally have beloved features at our disposal running natively in the AWS Lambda runtime. Praise all things holy!

Out with the old, in with the new

Remember that clunky callback parameter every lambda function has? Here’s some pseudo code showing a generic login function.

Note: Examples are written in Node.js using the Serverless Framework.

// Node.js v.6.10
module.exports.login = (event, context, callback) => {
connectToDatabase() // promise
.then(() =>
login(JSON.parse(event.body)) // promise
.then(session => callback(null, { // stupid callback 🙁
statusCode: 200,
body: JSON.stringify(session)
.catch(err => callback(null, { // stupid callback 🙁
statusCode: 500,
body: JSON.stringify(err)

Yeah, well now you don’t need callbacks anymore! With this new Node.js version the Gods of AWS have given us the possibility to leverage Promise chains for lambda handlers. Remember those wrappers you used to write to handle promises? Yes, those… Well, you can throw them out and just return a Promise chain now. Don’t believe me? Check it!

// Node.js v.8.10
module.exports.login = (event, context) => {
return connectToDatabase() // returning promise! 🙂
.then(() =>
login(JSON.parse(event.body)) // promise
.then(session => ({ // resolving the promise to an object
statusCode: 200,
body: JSON.stringify(session)
.catch(err => ({ // or rejecting with an error
statusCode: 500,
body: JSON.stringify(err)

How amazing is this!? No more fiddling with annoying callbacks. Using Promises natively and chaining them in the same way you’re already used to in your day-to-day life is just a breath of fresh air for serverless developers worldwide.

My life has just become 40% more joyful, just by starting to use Promises in my lambda functions. If you want to know why exactly 40%, hit me with a comment below. I may be joking, just a bit. *wink* *wink*

What about the fancy new ES6+ syntax?

Okay, so using Promises is amazing, but that’s not all. You know about my good friend async and his twin brother await? Yeah, I had a chat with them a while back and to be honest, they’re thrilled to finally be invited aboard the serverless hype train. *crowd cheers*

Now you can make your lambda function async and await every particular asynchronous piece of code within the lambda itself! Have a look below.

module.exports.login = async (event, context) => { // Lambda is async!
try {
const db = await connectToDatabase();
const session = await login(JSON.parse(event.body));
return {
statusCode: 200,
body: JSON.stringify(session)
} catch (error) {
return {
statusCode: 500,
body: JSON.stringify(error.message)

That is so sexy! Finally a reason to use try/catch blocks in JavaScript! I haven’t seen one of those since 2015 when I last tortured myself with C#. Good times. Hope to forget them as soon as possible.

With synchronous-looking code you get much better error handling and general visibility. The code is flat without any excessive indents. Using the try/catch block inside an async function will make sure all errors are handled even if the scope of the function is awaiting asynchronous operations.

Porting your existing functions from Version 6.10 to 8.10 can cause some issues, but for the most generic use cases you’ll be just fine. But to be safe, make sure to test your ported functions first, before you start routing production traffic to them. It also helps to write tests cases and even test things locally. Once you’re confident, and deploy it all, Dashbird will help you get a bird’s eye perspective of all your functions. You can rest assured we’ve got your back.

Make sure to specify the new version

While configuring the Serverless Framework for local development, like every other sane human being, you need to specify the runtime underneath the provider section. Like this.

# serverless.yml
name: aws
runtime: nodejs8.10
stage: dev

Or if you like torture, and create your lambda function through the AWS Console, specify the version during the actual creation.

Having an overview of your Node.js versions

We at Dashbird have done our best to give you the ability to see which language and runtime is running inside your lambda functions.

With a clear overview of all your functions you can see key info including the runtime.

Another cool thing you can do is to deploy the same functions but with different runtimes. This will let you monitor their execution (even in real-time) and see where they fail because of differences in the runtime! Call me a nerd, but this is so cool.

Why would you want the new runtime?

The key reasons are simple. New things are shiny and better. That would be the layman’s explanation. But in all honesty, it often is the case. Compared to the previous Node.js LTS version, Version 6.x, performance has been boosted by ~20%. Even AWS themselves claim the new V8 6.0 engine will lower memory consumption and guarantee a faster startup time across Node.js lambda functions!

Apart from the engine itself, HTTP/2 has been introduced, making the web as a whole so much better. The new protocol fixes a vast number of workarounds and issues HTTP/1.1 had. We can now be confident our apps running on AWS Lambda will be simpler, and much faster! Unfortunately we still have to wait for AWS to provide us with HTTP/2 support for AWS API Gateway to fully leverage this feature.

I can’t wait to start building with Node.js Version 8.10! My gut tells me you’re eager too.

We aim to improve Dashbird every day and user feedback is extremely important for that, so please let us know if you have any feedback about these improvements and new features! We would really appreciate it!


Read our blog

Introducing easy custom event monitoring for serverless applications.

Today we are excited to announce scheduled searches – a new feature on Dashbird that allows you to track any log event across your stack, turn it into time-series metric and also configure alert notifications based on it.

Why and How to Monitor Amazon OpenSearch Service

One of the most vital aspects to monitor is the metrics. You should know how your cluster performs and if it can keep up with the traffic. Learn more about monitoring Amazon OpenSearch Service.

Why and How to Monitor AWS Elastic Load Balancing

Dashbird recently added support for ELB, so now you can keep track of your load balancers in one central place. It comes with all the information you expect from AWS monitoring services and more!

More articles

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.