node-opcua: OPC UA Client and Server Stack for TypeScript

What node-opcua solves for industrial TypeScript applications

node-opcua targets applications that need to communicate with OPC UA systems rather than simply exchange application-specific HTTP messages. It is intended for developers building industrial automation, instrumentation, manufacturing, energy, machine-to-machine, and other OPC UA integrations. The project combines client, server, discovery, and aggregation capabilities in one toolkit. That scope is useful when a service must connect to controllers, expose data to clients, discover endpoints, or combine OPC UA information in a larger application.

The primary language is TypeScript, and the README says the stack runs on Node.js and in the browser. It is therefore relevant to teams that want typed APIs, shared code between server and browser contexts, and OPC UA protocol handling without building the complete stack from lower-level components. The package is published for npm, while the repository uses a monorepo layout with multiple packages under `packages`, `packages_extra`, and related directories.

The project is not limited to a client library. Its documented scope includes server construction, secure communication, certificate management, reverse connect, and role-based security. That breadth also creates a choice: an application can use only the client portion, or it can adopt the full stack when it needs to host an OPC UA server. The README does not document a lightweight alternative package name or a fixed subset of supported features, so the appropriate package boundary should be confirmed against the API documentation before selecting modules.

How node-opcua connects clients, servers, and secure channels

The documented architecture has a client side, a server side, discovery, and aggregation. Client and server construction are exposed through `OPCUAClient`, `OPCUAServer`, and `OPCUACertificateManager` options. These are the supported configuration surfaces for security and keys. The README specifically directs applications to configure security and keys through those objects rather than through internal construction symbols.

The repository identifies secure-channel plumbing such as `MessageBuilder`, `ClientSecureChannelLayer`, `ServerSecureChannelLayer`, and `OPCUAServerEndPoint` construction options as internal. They may be reachable through re-exports for historical reasons, but the project warns that they can change in a minor release. This is an important distinction for maintainers and integrators. A small application-level change should be based on the supported API documentation, not on an internal class discovered through source browsing.

The protocol behavior includes encrypted communication, OPC UA security policies, certificate management, discovery, and reverse connect. The repository also documents role-based security and user management based on OPC 10000-18. Those features indicate that node-opcua is intended to cover the connection and security lifecycle rather than only a basic read operation.

Installing node-opcua and running the sample server

The README requires Node.js 22.13 or above. For a new npm project, create a directory, initialize npm, and install the published package. The documented sequence is:

$ mkdir myproject
$ cd myproject
$ npm init
$ npm install node-opcua

The dollar signs are shell prompts shown in the README, not commands that need to be copied. After installation, the README directs users to install the sample package separately. The sample server command starts the server executable installed by that package.

$ npm install node-opcua-samples
$ ./node_modules/.bin/simple_server

The README does not specify the server's listening address, endpoint URL, or a required client configuration for this first command. Consequently, the first practical result should be the sample process starting successfully and remaining available for the client command. The sample package is separate from `node-opcua`, which is worth noting when interpreting the installation instructions: the runtime package and the tutorial samples are not installed through the same command.

Connecting a sample client to an OPC UA endpoint

The documented first client operation connects to a public demo endpoint:

$ ./node_modules/.bin/simple_client -e "opc.tcp://opcuademo.sterfive.com:26543"

Here, `-e` supplies the OPC UA endpoint URL to the sample client. The endpoint uses the `opc.tcp` scheme, which is the network form used by the example. The README does not describe the sample client's output, authentication prompts, or security settings, so those details should not be assumed. A developer should compare the process behavior with the sample package's own documentation if it differs.

For a real application, the README links to a TypeScript client tutorial and the generated API documentation. Those sources are the appropriate place to learn how to construct an `OPCUAClient`, establish a session, browse nodes, read values, and create subscriptions. The public endpoint in the quick-start command is a demonstration target, not evidence that the same endpoint represents a production server or its security configuration.

Security configuration and certificate responsibilities

Security is a first-class part of node-opcua's documented scope. The README says the stack supports all OPC UA security policies, encrypted communication, and certificate management out of the box. Applications should use `OPCUAClient`, `OPCUAServer`, and `OPCUACertificateManager` for security and key configuration. That restriction matters because internal secure-channel symbols are outside the semver-protected API described by the generated documentation.

The repository contains a `SECURITY.md` file, security-related package topics, and a professional support section that distinguishes public GitHub issue handling from private support and early access to CVE security advisories. These entries confirm that security handling is part of the project's operating context. They do not, however, provide a certificate rotation policy, a complete endpoint compatibility matrix, or deployment instructions for a specific operating system.

The practical limitation is that OPC UA security depends on agreement between client, server, endpoint, trust anchors, credentials, and network configuration. node-opcua can supply the protocol implementation and certificate management facilities, but the README does not say that every industrial device accepts every policy or user configuration. Operators must verify device-specific compatibility before deployment. MIT licensing covers the project code, but the README does not state how that license interacts with separate vendor SDKs, certificates, or server software.

Maintenance, release changes, and the API boundary

The repository is not archived, and its last push was on 2026-10-15. Recent releases include `v2.187.3` on 2026-10-11, `v2.186.0` on 2026-09-20, and `v2.185.0` on 2026-09-19. These dates indicate recent release activity, but they do not establish compatibility for any particular OPC UA server or client.

The repository is a monorepo managed with Lerna and includes a root `package.json`, workspace files, generated code, packages, tests, documentation, and release tooling. The root package is private and is named `node-opcua-mono-repo`, while the README's installation instructions install the public `node-opcua` npm package. That distinction prevents a contributor workflow from being mistaken for the end-user install path.

The README also distinguishes the supported, semver-protected API from internal symbols. That gives maintainers an explicit compatibility boundary, but it means applications should avoid depending directly on implementation classes. The linked `RELEASE_NOTES.md`, `supported_features.md`, tutorials, and API reference are the places to check for feature-specific upgrade changes.

Editorial conclusion

Adopt node-opcua when an application needs OPC UA client or server functionality in TypeScript across Node.js or browser environments. Do not choose it when a minimal protocol-specific library or a preconfigured industrial gateway is required. Verify first that your target devices, security policies, certificate workflow, and Node.js version fit the documented setup.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. node-opcua/node-opcua on GitHub
4. README
5. Releases