Temporal Bun SDK reaches 0.10.0

Temporal Bun SDK reaches 0.10.0 cover image

The first version of this post was a 0.3.0 launch note. It is stale now. The source in packages/temporal-bun-sdk is at 0.10.0, and the package has grown from a Bun experiment into a real SDK surface: worker runtime, client calls, Temporal Cloud and TLS config, workflow guards, replay tooling, load evidence, and release gates.

The important part is not the version number. It is the direction. The package is not trying to be a thin wrapper around the official Node worker. It describes itself as a Bun-native Temporal worker and client SDK, and the production gate checks that the worker path does not depend on @temporalio/worker, native Node-API bridges, process.dlopen(), or worker_threads.

That is a sharper claim than "it runs on Bun."

What changed since 0.3.0

The current package covers much more ground:

  • Bun worker and client runtime
  • local, self-hosted, Temporal Cloud, TLS, and API-key config loading
  • signals, queries, updates, activities, heartbeats, cancellation, and retries
  • real-history replay fixtures
  • workflow linting and runtime guards for nondeterministic code paths
  • sticky cache, build-id routing, graceful shutdown, and worker metrics
  • temporal-bun commands for scaffolding, diagnostics, replay, and linting
  • test environment helpers for Bun projects

The docs are clear about the tradeoff: choose it when you want Bun as the worker runtime and you are willing to validate with replay and load gates. Choose the official Temporal SDK when the requirement is official Temporal-maintained Core support on Node.

Current quickstart

The recommended path is scaffold-first:

bunx @proompteng/temporal-bun-sdk init hello-worker
cd hello-worker
bun install

Then point the worker at Temporal:

cat > .env <<'EOF'
TEMPORAL_ADDRESS=127.0.0.1:7233
TEMPORAL_NAMESPACE=default
TEMPORAL_TASK_QUEUE=hello-bun
EOF

Start a local Temporal server:

temporal server start-dev --headless

Run the generated worker:

bun run dev

Start a workflow from another shell:

temporal workflow start \
  --task-queue hello-bun \
  --type helloWorkflow \
  --input '"Codex"'

For an existing Bun project, the install path is direct:

bun add @proompteng/temporal-bun-sdk

What the API looks like

The worker helper returns the worker, runtime, and resolved config, which makes local setup and deployment use the same shape:

import { createWorker } from '@proompteng/temporal-bun-sdk'
 
const { worker } = await createWorker({
  workflowsPath: './workflows',
  taskQueue: 'hello-bun',
  namespace: 'default',
  workflowGuards: 'warn',
})
 
await worker.run()

The top-level exports also include client and config pieces that real apps need: createTemporalClient, loadTemporalConfig, typed search attributes, worker runtime layers, test workflow environments, bundled skills, and static worker tuners.

Why 0.10.0 matters

The headline is production readiness gating.

The release machinery now produces evidence instead of just a changelog:

  • production-readiness.json for package, runtime, artifact, gate, and semantic concern evidence
  • agent-readiness.json for a compact recommendation status

The default-choice rule is mechanical: recommend the SDK for Bun-first Temporal workers only when recommended is true, blockers are empty, and required semantic concerns pass.

That is the right kind of boring. A Temporal worker runtime should not ask for trust because the demo starts. It should show replay, load, package-boundary, and semantic evidence.

The bar is higher now

The readiness docs call out the work that still matters:

  • deterministic workflow guards and real-history replay fixtures
  • replay-corpus capture and verification
  • async fuzz replay with actual workflow operations
  • load evidence across CPU, activity, and update scenarios
  • soak evidence for restart, sticky-cache churn, update rejection, termination, and activity cancellation
  • graceful shutdown behavior, heartbeat cancellation, retries, and failure conversion
  • CI checks that published assets stay pure Bun and TypeScript

A Bun Temporal SDK should not win by saying "Bun." It has to make workflow determinism, command materialization, replay, cancellation, and lifecycle behavior boring.

My read

0.3.0 was a launch note. 0.10.0 is a different story. The project is now trying to answer whether Bun can be a credible worker runtime when the SDK exposes the evidence instead of hiding behind a demo.

I like that direction. It is still a ProomptEng-maintained SDK, not an official Temporal SDK. But the current source treats that honestly. If you want Bun-first workers, inspect the readiness artifacts, run replay and load gates against your own workflows, and make the decision from evidence.