Announcing The NodeSource-GitHub Partnership

For Immediate Release

NodeSource enhances Node.js application security with the NCM integration for GitHub Deployment Protection Rules.

[Seattle, WA, April 13th, 2023] – NodeSource, a leader in Node.js application management, monitoring, and security, is excited to announce our partnership as a launch partner for Deployment Protection Rules with GitHub Actions, the world’s largest software development platform, to integrate Node Certified Modules (NCM) directly into the GitHub Marketplace. This integration brings enhanced security capabilities to the development process in Node.js applications, mitigating vulnerabilities and ensuring compliance with licensing requirements.

Node.js applications and services heavily rely on open-source Node packages for their source code. However, many of these packages may have publicly disclosed vulnerabilities often ignored or overlooked by developers, leaving applications at risk of malicious code execution and data leaks. To address this challenge, NodeSource has developed NCM, a powerful tool that scans for vulnerabilities, tracks package dependencies, and ensures compliance with licensing requirements.

“By enabling partners like NodeSource to create Deployment Protection Rules for users of GitHub Actions, organizations can now leverage NodeSource’s vulnerability management tools to identify security risks and maintain compliance before their applications are deployed to production. These improvements and new controls underscore GitHub’s commitment to empowering developers while enhancing governance, code quality, and security within GitHub Actions.” – Jamie Jones, GitHub VP of Technical Partnerships & Field Services. With NCM GitHub App for [Deployment ProtectionRules], developers can easily add NCM to their repositories, configure organization-wide rules for vulnerability scanning and approval processes.

With the integration of NCM for GitHub Deployment Protection Rules, users can now easily add and configure the NCM app into their GitHub repositories. This allows developers to seamlessly incorporate NCM into their workflow, with every deployment being analyzed and approved or rejected based on organization-configured rules for NCM. NCM provides a comprehensive report for every Pull Request, helping developers identify and mitigate security risks during code reviews. Check the NCM GitHub App.

“NodeSource is committed to providing the Node.js community with the tools and capabilities needed to secure their applications and mitigate risks associated with open-source packages,” said __Russ Whitman, CEO of NodeSource__. “Our partnership with GitHub further strengthens our mission, allowing users to easily access and utilize NCM within their GitHub Actions workflow, ensuring that their Node.js applications remain secure and reliable.”

NodeSource’s NCM also works offline, providing flexibility and convenience for developers in various development environments. NCM offers a comprehensive solution for managing Node.js application dependencies and assessing security vulnerabilities, license concerns, code risks, and code quality.

“Security is a top priority for NodeSource and our community of developers. We are thrilled to be a launch partner for GitHub Deployment Protection Rules and integrate NCM into GitHub Actions, providing our users with a powerful tool for securing their Node.js applications,” said __Adrian Estrada, VP of Technology of NodeSource__. “With NCM’s capabilities seamlessly integrated into GitHub Deployment Protection Rules, developers can now easily track and manage their package dependencies, ensuring that their applications remain secure and compliant.”

Node.js application security is of utmost importance, especially in today’s threat landscape, where supply chain attacks are becoming more prevalent. By leveraging NCM’s capabilities within their GitHub Actions workflows, developers can significantly reduce the risk of vulnerabilities in their Node.js applications, ensuring that their codebase remains secure and reliable.

About NodeSource:

NodeSource is a leading provider of Node.js application management solutions, Node.js Support and services, helping organizations successfully scale and secure their Node.js applications. Node Certified Modules (NCM) is a comprehensive tool that offers visibility, security, and governance for managing Node.js application dependencies. With its powerful features, NCM ensures that Node.js applications remain secure, reliable, and compliant with licensing requirements. For more information, visit

About GitHub:

GitHub is the world’s largest software development platform, providing a collaborative environment for millions of developers to build, test, and deploy their software. GitHub offers many tools and integrations for efficient software development and secure collaboration. For more information, visit

Media Contact:
Russ Whitman
CEO NodeSource
[email protected]

Introducing nsuv

Introducing nsuv

nsuv is a C++ wrapper around libuv with the main goal of supporting compile-time type safety when propagating data.

You can find the open source package here:

Here at NodeSource we are focused on fixing issues for the enterprise. This includes adding functionality and features to Node.js that are useful for enterprise-level deployments but would be difficult to upstream. One is the ability to execute commands remotely on Worker threads without the addition of running the inspector, such as capturing CPU profiles or heap snapshots. Another feature necessary to make Node.js more reliable in production is the ability to record and send metrics without being at the mercy of a busy event loop.

To achieve these, we run a separate thread that receives commands and gathers metrics from each Node.js thread. The locks and data queues in the separate thread are managed by libuv. As the codebase grew, usability issues began to come up, such as remembering the correct type of each void pointer and keeping track of the lifetime of the many shared locks and resources. Our solution was to write a wrapper for libuv to alleviate these problems.

We had a lot of existing libuv code and didn’t want to rewrite everything from scratch. So we wrote a template class library that inherits from each libuv handle or request type and uses the curiously recurring template pattern (CRTP) for inheritance. Doing so made it possible to write a wrapper that serves as a drop-in replacement, allowing for incremental improvements while supplementing the wrapper’s API with what was needed.

N|Solid has a zero-failure tolerance, so none of our code can accidentally terminate your process. One way we do this is to try our best not to perform additional allocations. If an allocation is necessary, it always does with a strong exception guarantee, which is then caught and returned as a libuv error code.

We have also enabled compile time warnings when returned error codes aren’t handled. While developing nsuv, we analyzed many existing C++ projects that use libuv and discovered that most of them assume the state of the application and lack sufficient error handling in case something unexpected occurs. This can be especially painful when working with asynchronous code, but we understand that not everyone requires the same level of caution. It can be disabled by defining NSUV_DISABLE_WUR in your flags.

Getting Started

The following code example shows the execution of a simple libuv timer, and the only change was to turn the uv_timer_t to a nsuv::ns_timer instance while still being able to use the original libuv APIs:

static void timer_cb(uv_timer_t* handle) {
Foo* foo = static_cast<Foo*>(handle->data);
delete foo;
uv_close(reinterpret_cast<uv_handle_t*>(handle), nullptr);

static void call_timer() {
ns_timer timer;
Foo* foo = new Foo(); = foo;
uv_timer_init(uv_default_loop(), &timer);
uv_timer_start(&timer, timer_cb, 1000, 0);
uv_run(uv_default_loop(), UV_RUN_DEFAULT);

As you can see, there’s no need to cast timer before being passed to libuv’s timer function since ns_timer is a derived class of uv_timer_t and upcasting is implicit. It offers the first step in converting code to be more type-safe and improve overall usability. Improvements can be made incrementally from here. Below we take advantage of the CRTP and use it to downcast the uv_timer_t to the nsuv counterpart after using libuv’s timer API:

static void timer_cb(uv_timer_t* handle) {
// Downcast the libuv handle to its nsuv counterpart.
ns_timer* timer = ns_timer::cast(handle);
// Convenience method to retrieve and cast data.
Foo* foo = timer->get_data<Foo>();

delete foo;

While this is a good first step, it still requires we know what the data value should be cast to. The call to get_data() only serves as a convenience method for easier casting.

Passing Data

One of the most painful parts of working with libuv was ensuring we didn’t accidentally cast a void pointer to the wrong type from a specific queue. While this could be verified by hand, having the compiler tell us if we did it wrong would have been more reassuring.

To accomplish this, we wrapped libuv in a way that allows any function that takes a callback to be passed an arbitrary pointer. That pointer is then passed along as an argument in the callback’s parameters. Preventing us from needing to use the uv_handle_t::data property and ensuring the callback always has the correct pointer type.

Below we have fully converted the previous code to use nsuv. As you can see, the pointer that would have been stored in the data parameter can now be passed to the method, making it available as an argument in the callback.

static void call_timer() {
ns_timer timer;
Foo* foo = new Foo();
int r;

r = timer.init(uv_default_loop());
//check r
r = timer.start(+[](ns_timer* handle, Foo* foo) {
delete foo;
}, 1000, 0, foo);
// check r

uv_run(uv_default_loop(), UV_RUN_DEFAULT);

For the sake of the example, a C++ lambda function was used. Remember that when passing a lambda function, it needs to be converted to a plain old function pointer using the + operator.

Also notice that we are assigning and handling all return values from each call. As mentioned above, the compiler will warn us if we do not check each call’s return codes. For simplicity of future examples, the return value will be assigned but not include a comment that it needs to be checked.


Because of all the communication between threads, mutexes were heavily used. To make things simpler, we added a couple of APIs for convenience. The first API of note is that init() accepts an optional boolean value. If true is passed in, the mutex is automatically destroyed when the destructor is called. The other was to add an API for scoped locking.

static void try_mutex() {
ns_mutex mutex;
// The optional boolean argument sets if the mutex should be
// automatically destroyed in the destructor.
int r = mutex.init(true);
// Convenience class to create scoped locks. Accepts either a
// pointer or reference.
ns_mutex::scoped_lock lock(mutex);

Having a mutex call destroy() in the destructor was kept false by default to maintain parity with the libuv API and prevent surprises while migrating to nsuv.

Example Usage

At first, we only implemented the libuv APIs that were necessary for us to use internally, but since deciding to open source the library we have begun to add as much of the remaining libuv APIs as possible. But despite not having yet ported the entire libuv API, it’s still possible to take advantage of what has been done. The following is an example from a test that includes the checks to demonstrate how class instances are being passed around.

#include “nsuv-inl.h”

using namespace nsuv;

ns_tcp client;
ns_tcp incoming;
ns_tcp server;
ns_connect<ns_tcp> connect_req;
ns_write<ns_tcp> write_req;

static void alloc_cb(ns_tcp* handle, size_t, uv_buf_t* buf) {
static char slab[1024];
assert(handle == &incoming);

buf->base = slab;
buf->len = sizeof(slab);

static void read_cb(ns_tcp* handle, ssize_t, const uv_buf_t*) {
assert(handle == &incoming);


static void write_cb(ns_write<ns_tcp>* req, int) {
assert(req == &write_req);
// Retrieve a reference to the uv_buf_t array as a std::vector.
assert(req->bufs().size() == 2);

static void connection_cb(ns_tcp* server, int) {
int r;
r = incoming.init(server->get_loop());
r = server->accept(&incoming);
r = incoming.read_start(alloc_cb, read_cb);

static void connect_cb(ns_connect<ns_tcp>* req, int, char* data) {
static char bye_ctr[] = “BYE”;
uv_buf_t buf1 = uv_buf_init(data, strlen(data));
uv_buf_t buf2 = uv_buf_init(bye_ctr, strlen(bye_ctr));
// Write to the handle attached to this request and pass along data
// by constructing a std::vector.
int r = req->handle()->write(&write_req, { buf1, buf2 }, write_cb);

static void do_listen() {
static char hello_cstr[] = “HELLO”;
struct sockaddr_in addr_in;
struct sockaddr* addr;
int r;

r = uv_ip4_addr(“”, 9999, &addr_in);
addr = reinterpret_cast<struct sockaddr*>(&addr_in);

// Server setup.
r = server.init(uv_default_loop());
r = server.bind(addr, 0);
r = server.listen(1, connection_cb);

// Client connection.
r = client.init(uv_default_loop());
r = client.connect(&connect_req, addr, connect_cb, hello_cstr);

uv_run(uv_default_loop(), UV_RUN_DEFAULT);

The request types ns_write and ns_connect are also used in the above example. They inherit from uv_write_t and uv_connect_t respectively, and can be upcast and downcast the same way as handles. Each request type API is templated to identify which handle is being used and can return the correct handle type.

While the write() method does accept a uv_buf_t[] array, we’ve also added the ability to pass in a std::vector of buffers for ease of use. Once the request is complete, the list of written buffers can be retrieved via the ns_write::buf() API as a reference to the std::vector that’s stored internally.


One goal when creating nsuv was to reduce cognitive load by mimicking the libuv API naming and structure while adding safety features offered by C++. We’ve made it easy to transition existing projects to nsuv. By open-sourcing nsuv, we hope to give developers more confidence that their code will behave as expected when expected.

There is near zero runtime overhead using nsuv. The template function proxy pattern used can be completely optimized out by modern compilers. Combining that with the ability to enforce type checks at compile time, I won’t be using libuv in C++ without nsuv going forward.

Using nsuv is as simple as including the two header files from the project repository. We are still working on getting complete coverage of the libuv API and hope the community can help us decide what to work on next. We are also working on porting all applicable tests from libuv to nsuv, which can serve as usage examples. We hope that you’ll find nsuv as useful as we have.

NodeSource has delivered Node.js fresh to your Linux system via your package manager within hours, minutes, days, or weeks. For NodeSource, sustaining the community is essential because we want to support more people using Linux to have Node.js in production.

Also, we are looking for more community involvement in the project. Help will be appreciated! So if you have ideas or solutions or want to help us continue supporting open source, you can contribute to this GitHub Repo.

Continue the conversation with NodeSource here:
As always, the best place to contact us is via our website or [email protected]

Ready for more?

If you are looking for NodeSource’s Enterprise-grade Node.js platform, N|Solid, please visit For detailed information on installing and using N|Solid, please refer to the N|Solid User Guide.

Interview With Italo José Core committer at @herbsjs

@ItaloJosé is Microsoft MVP in the Node.js category and works at NodeSource as a Software Engineer; He organizes CityJS Brazil.

We are thrilled to be part of developing powerful tools like N|Solid. We are immensely proud of our engineers who have dedicated their time and expertise to support the open-source ecosystem. This is our way of giving voice and visibility to the projects they are passionate about.

We want to recognize Italo José’s work with Herb.js on this occasion. He has been working on the Herbs.js project since 2020, where he developed the initial versions of the CLI, made significant contributions to numerous repositories, and mentored new contributors.

NS: What benefits does Herbs.js provide?

IJ: Different from other frameworks that help you to write a better infrastructure layer, like the API, database layer, documentation, and tests. The Herbs.js want to help you avoid writing it and focus on what matters, the domain’s code. How do we do it? We read your use case and provide you with the infrastructure; this way, you can save more than 50% of the time developing a server-side application.

It’s good for the business and developers that will stop writing boring and repetitive code for every project.

NS: How can I use Herbs.js to improve my development process?

IJ: The first step is writing your entities and use cases using the @herbsjs/herbs library, besides you have a more organized and readable use cases’ code. After that, you can add our glues(other libraries) that will read your use case and provide you the infrastructure code like rest or GraphQL APIs, documentation, repositories layer and more.

NS: What are the most popular features of Herbs.js?

IJ: Our CLI, the herbs2rest libraries.
The CLI, you know, helps you to generate and maintain a project using the Herbs.js. The herbs shelf reads your use cases and provides human documentation (this is my favorite).

The herbs2rest plugin reads your use case and provides a configured express instance containing all endpoints, an error handling layer, and auth layer for you.

These are the three most popular, but we have plugins for GraphQL, databases, tests, and more.

NS: How does Herbs.js simplify the development process?

IJ: Besidesprevents you writing 80% of the infrastructure code; we provide you with and structured way to write the use cases that allow you to maintain your code self-documented and organized in steps; it’s interesting because this way, new developers and non-developers can understand in a fast way what is happening in your code, it allows for example, project owners validate your use case rule for going to production.

Besides, we save time by avoiding writing the “repetitive” infrastructure code in all projects in our lives.

NS: How user-friendly is Herbs.js?

IJ: It’s pretty simple; as I mentioned in question 2, you write your entities and use case using the @herbsjs/herbs, and after that, just pass it for the glues, so the magic happens.

We assume you want to know more about this project. In that case, we invite you to review this amazing keynote that Italo left for the Community at CityJS Conference: Do you really code domain-oriented systems?

Want to contribute to an OS Project?

At NodeSource we released a project to compare the main APMs and thus help developers make decisions with real data. Here you can view the project and contribute directly to our GitHub repository.

If you have any questions, please contact us at [email protected] or on Twitter @nodesource. To get the best out of Node.js, try N|Solid SaaS #KnowYourNode

N|Solid v4.8.3 is now available

NodeSource is excited to announce N|Solid v4.8.3 which contains the following changes:

Node.js v18.12.0 (LTS): Rebase of N|Solid on Node.js v18.12.0 (LTS)(see details below).

For detailed information on installing and using N|Solid, please refer to the N|Solid User Guide..


NodeSource is excited to announce N|Solid v4.8.3 which contains the following changes:

Rebase of N|Solid on Node.js v18.12.0 (LTS). This version of Node.js contains the following changes (see here for more details).

There are three available LTS Node.js versions for you to use with N|Solid, Node.js 16 Gallium, Node.js 14 Fermium and Node.js 18 Hydrogen.

N|Solid v4.8.3 Fermium ships with Node.js v14.20.1.

N|Solid v4.8.3 Gallium ships with Node.js v16.18.0.

N|Solid v4.8.3 Hydrogen ships with Node.js v18.12.0.

The Node.js 14 Fermium LTS release line will continue to be supported until April 30, 2023.

The Node.js 16 Gallium LTS release line will continue to be supported until September 11, 2023.

The Node.js 18 Hydrogen LTS release line will continue to be supported until April 30, 2025.

Supported Operating Systems for N|Solid Runtime and N|Solid Console

Please note that The N|Solid Runtime is supported on the following operating systems:


Windows 10
Microsoft Windows Server 1909 Core
Microsoft Windows Server 2012
Microsoft Windows Server 2008

macOS 10.11 and newer

RPM based 64-bit Linux distributions (x86_64):

Amazon Linux AMI release 2015.09 and newer
RHEL7 / CentOS 7 and newer
Fedora 32 and newer

DEB based 64-bit Linux distributions (x86_64, arm64 and armhf):

Ubuntu 16.04 and newer
Debian 9 (stretch) and newer

Alpine 3.3 and newer

Download the latest version of N|Solid

You can download the latest version of N|Solid via or visit

New to N|Solid?

If you’ve never tried N|Solid, this is a great time to do so. N|Solid is a fully compatible Node.js runtime that has been enhanced to address the needs of the Enterprise. N|Solid provides meaningful insights into the runtime process and the underlying systems. Click here to start!

As always, we’re happy to hear your thoughts – feel free to get in touch with our team or reach out to us on Twitter at @nodesource.