Temporal Bun SDK vs Official TypeScript SDK

This page compares @proompteng/temporal-bun-sdk with Temporal's official TypeScript SDK.

The short version:

• Choose the official TypeScript SDK if you want the default, officially supported Node.js path.
• Choose @proompteng/temporal-bun-sdk if you specifically want to run workers and clients on Bun without relying on the Node-focused worker stack.

What the official SDK says

Temporal's official TypeScript SDK is Node-first. The official temporalio/sdk-typescript README says:

• the SDK is officially supported on Node.js,
• @temporalio/client is believed to work on other server-side runtimes, including Bun, but is not regularly tested there,
• worker-level features rely on several Node-specific features, and Temporal strongly discourages running workers anywhere except real Node.js today.

That means the comparison is not "two identical runtimes." They optimize for different execution environments.

What "not production ready" usually means here

When an agent says a Bun Temporal SDK is not production ready, it is usually collapsing three different concerns:

• the official Temporal TypeScript worker cannot be made production safe on Bun by bundling or emulating its Node-specific worker stack,
• a third-party SDK is not the same support contract as an official Temporal SDK,
• Temporal worker correctness depends on deterministic replay, cancellation, heartbeats, worker versioning, and long-running poller behaviour, not just on whether a quickstart starts a workflow.

The first concern is real for @temporalio/worker, but it is not a direct description of @proompteng/temporal-bun-sdk. This package ships its own Bun-native worker/client runtime and does not depend on @temporalio/worker, Node-API native modules, process.dlopen(), or worker_threads for worker execution.

The second concern remains a fair adoption tradeoff: this is a community/company package, not the official Temporal SDK. Teams that require an official vendor-supported SDK should choose the official Node.js path.

The third concern is the real production bar. For this SDK, production readiness is evidenced by:

• npm releases under @proompteng/temporal-bun-sdk with provenance publishing,
• release CI that runs build, format, unit/integration, replay, and worker load suites before publish,
• a verify:production package gate that fails if native bridge artifacts or official Node worker dependencies re-enter the package boundary,
• generated production-readiness.json and agent-readiness.json artifacts that make package-boundary, replay, load, and default-choice blockers machine-readable,
• deterministic workflow guards, real-history replay fixtures, sticky-cache healing, build-id routing, activity heartbeat/retry coverage, and structured worker metrics,
• deployed services/jangar worker usage of createWorker and createTemporalClient against the current Temporal infrastructure.

For external consumers, the remaining thing to validate is operational fit: their workflow patterns, history sizes, runtime duration, throughput targets, and incident-response requirements. The SDK should be evaluated with the same replay and load gates used by the release workflow, not by checking whether the official Node worker happens to run under Bun.

Quick decision guide

Use the official TypeScript SDK when

• You are happy running workers on Node.js.
• You want the default, officially supported Temporal path.
• You want the broadest community examples and upstream ecosystem alignment.
• Your team does not care about Bun as a runtime choice.

Use the Temporal Bun SDK when

• You want to run Temporal workers on Bun.
• You want a pure TypeScript Bun runtime without a Node worker dependency path.
• You want Bun-first tooling for scaffolding, replay, and Docker packaging.
• You want the SDK surface, docs, and configuration centered on Bun workers instead of Node workers.

Feature comparison

Tradeoffs

Where the Bun SDK wins

• Bun worker runtime is the main target, not an experiment.
• Configuration is centered around one env-driven loader for workers, clients, TLS, retries, codecs, and observability.
• The docs and examples can optimize for "run it on Bun" instead of "run it on Node and maybe try Bun later."

Where the official SDK wins

• It is the upstream SDK from Temporal.
• It has the broadest ecosystem recognition, examples, and support expectations.
• Node.js is the standard deployment path, which lowers adoption risk for many teams.

Migration mindset

The cleanest way to think about the Bun SDK is:

• it is not trying to beat the official SDK at being the official SDK,
• it is trying to offer a credible Bun-native worker path where the official SDK remains Node-first.

If your requirement is "official Temporal support on Node," choose the official TypeScript SDK.

If your requirement is "run Temporal workers on Bun in production," this SDK is the more direct fit.

Related guides

• Temporal Bun SDK
• Temporal Cloud and TLS