Simplex Is Now Available as an npm Library

I was reading Hyperbridge's release notes the other morning when I hit the line that stopped me: "Simplex is now available as an npm library." Not another Docker image, not another dashboard — a library you embed directly in your Node.js app. As someone who has watched cross-chain infrastructure teams burn weeks standing up separate solver services, that one sentence changes the math on how you ship intent-based settlement. On September 3, 2026, Hyperbridge published the announcement, and it is worth unpacking because the choice between running Simplex as a standalone binary, a Docker container, or now embedded code is really a choice about how much infrastructure responsibility your team wants to own.

Key Metrics at a Glance

Three Ways to Run Simplex — and When Each Wins

Hyperbridge frames the library as the third option between "separate service" and "write a solver from scratch." That framing is accurate, and the decision hinges on integration depth:

• Docker image — deploy a container in your existing cloud infrastructure when you want Simplex as an isolated, ops-managed service.
• Standalone binary — the complete application with its own config, dashboard, and HTTP API. Best when you want to operate Simplex without building those surfaces yourself.
• npm library — embed the same solving engine and pricing logic inside your existing Node.js application and control it entirely through code.

The library is not a replacement for the binary; it exists for sophisticated teams that already run a database, a pricing feed, an alerting pipeline, and an application tying them together. Adding Simplex as yet another service means another process to deploy, another API to integrate, and — as solver instances multiply — more infrastructure to pay for.

What Embedding Actually Buys You

Three capabilities stand out. First, shared infrastructure: multiple Simplex instances can run side by side in one Node.js app and share a single RPC connection. RPC costs grow with usage, but sharing one connection avoids maintaining a separate provider setup per solver instance. Second, code-level control: every dashboard control — reprice a pair, add a chain, pause fills, trigger a rebalance — is a method on the running solver. A live price feed can push updates via simplex.pairs.setCurve("bid"/"ask", ...) on each tick, with no restart, no config reload, and no window running on a stale price. Third, your own data and wallet rails: the library exposes a SimplexDataStore storage interface (SQLite ships as a default, but Postgres, Redis, or hosted services slot in) and a Signer interface, with built-in support for Turnkey, MPCVault, and private keys — so adopting the library does not require moving funds into a new wallet system. Solver activity also arrives as a typed event stream (e.g., order:filled with orderId and profitUsd), so you can wire dashboards and alerts the way your ops already work. Importantly, importing the package writes no logs and opens no ports until you tell it to.

Competitive Context: Solver Deployment Models Across Cross-Chain Infra

Hyperbridge's library play is differentiated precisely at the "sophisticated team with shared infrastructure" segment: where competitors typically force a separate service, Simplex can run in-process and share RPC, storage, and signing with the host application.

A Decision Framework for Teams Evaluating Simplex

Use this when picking a deployment mode: (1) Do you already have a Node.js application with a database, pricing feed, and alerting? If yes, the library usually wins on total cost and ops load. (2) Do you need a dashboard and HTTP API out of the box with minimal integration work? Use the standalone binary. (3) Is a container the most convenient deployment unit in your cloud setup? Use the Docker image. (4) Are you running many solver instances that can safely share one RPC connection and one data store? The library's multi-instance support is the key advantage. (5) Do you need a wallet/approval system you already trust (Turnkey, MPCVault, internal signers)? The Signer interface means Simplex fits into it rather than forcing a move. Caveats: embedding gives your application more responsibility — you own how controls are exposed, data stored, activity displayed, and the process monitored. Teams wanting a complete application rather than a component should still prefer the binary.

TL;DR

• What: Hyperbridge released Simplex as an npm library (@hyperbridge/simplex, Node.js 22+) on September 3, 2026, adding embedded deployment alongside the Docker image and standalone binary.
• Why: Lets sophisticated teams run the solver inside their existing Node.js app, share one RPC connection and data store across instances, plug in their own SimplexDataStore and Signer (Turnkey/MPCVault/private key), and drive everything through code and typed events.
• Trade-off: The library is not a replacement for the binary — embedding means your team owns controls, storage, monitoring, and exposure. Binary for a complete app; Docker for containerized ops; library for deep integration.
• Watch: Adoption of the SDK monorepo (@hyperbridge/sdk, @hyperbridge/core, simplex) and docs updates at docs.hyperbridge.network/developers/sdk/simplex.

Sources

• Hyperbridge Blog: Simplex Is Now Available as an npm Library (Sept 3, 2026)
• Hyperbridge SDK docs: Simplex
• npm: @hyperbridge/simplex
• Hyperbridge SDK monorepo (GitHub)

Gemma Nguyen is Content Lead & Journalist at Totestek, covering cryptocurrency, Web3, DeFi, and blockchain technology. She blends an independent journalistic voice with Totestek's editorial standards to explain complex on-chain and infrastructure developments clearly.