OpenWorkflow is an open-source TypeScript framework for building durable, resumable workflows on Node.js and Bun, aimed at developers who need long-running background work to survive crashes and deploys without operating extra servers.

What it is

OpenWorkflow is a workflow engine distributed as the npm package openworkflow under the Apache-2.0 licence. Developers declare a workflow with defineWorkflow, passing a name and a handler that receives input and step, and then break the work into named units with calls such as step.run({ name: "fetch-user" }, async () => ...). Those steps can pause for seconds or months, survive crashes and deploys, and resume exactly where they left off. The framework targets the Node.js and Bun runtimes, and the repository carries topics for durable execution, durable functions, background jobs, workflow engines, PostgreSQL, and SQLite.

The concrete problem it solves is the plumbing that TypeScript teams usually hand-roll around background jobs: persistence of intermediate state, resumption after a process restart or a mid-deploy crash, and retry structure that does not lose track of where a job stopped. Instead of assembling that machinery around a queue, the developer expresses the workflow directly in application code and lets the engine hold durable state, with no extra servers to manage. It sits in the Node.js and Bun ecosystem, in the Infrastructure and Operations / Orchestration and Scheduling category, and it replaces the bespoke durable-execution layer a team would otherwise maintain alongside its application database.

Key capabilities

• defineWorkflow from the openworkflow package declares a workflow by name, with the handler receiving input and step.
• step.run({ name: "..." }, async () => ...) wraps each unit of work so it is durable and resumable.
• Durable execution: workflows pause for seconds or months, survive crashes and deploys, and resume where they left off.
• Runtime support for both Node.js and Bun.
• Persistence through the storage backends covered by the project topics, PostgreSQL and SQLite.
• Project scaffolding from @openworkflow/cli init, invoked through npx, pnpx, or bunx.
• OpenTelemetry instrumentation documented, alongside an OpenWorkflow dashboard asset in the repository.

Who uses it and how

• TypeScript teams on Node.js or Bun that need background jobs, durable functions, or durable workflows inside an existing service rather than a separate stack.
• Workflows that wait on human-scale or deployment-scale gaps, such as the documented welcome-email example that fetches a user, sends mail through Resend, and marks the flag set.
• Small deployments that prefer SQLite as the backing store, and larger ones that run PostgreSQL.
• Teams already instrumenting services with OpenTelemetry that want workflow execution covered by the same telemetry.
• Adopters who want a dashboard plus the documented paths through quickstart, core concepts, advanced patterns, and the production checklist.

Getting started

Run npx @openworkflow/cli init (or the pnpx / bunx equivalents), which guides setup and generates what is needed to begin; the framework itself installs as the npm package openworkflow, with documentation at openworkflow.dev.

How it compares

The facts supplied for this listing name no competing or comparable products, so OpenWorkflow stands alone in this registry. Its stated position is that it delivers durable workflows without extra servers to manage, leaving the comparison to the adopter's own stack.

When to use it — and when not to

Adopters take on the operational responsibilities the README does not outsource: running the engine in their own infrastructure against a PostgreSQL or SQLite backing store, and handling whatever else their deployment requires. Teams not working in TypeScript on Node.js or Bun should look elsewhere, since the framework targets those runtimes specifically. This is also a young project with a short README, no documented hosted or managed option, and a modest issue count, so anyone wanting a vendor-operated service or a very long operational track record should weigh that before committing.

import { defineWorkflow } from "openworkflow";

export const sendWelcomeEmail = defineWorkflow(
  { name: "send-welcome-email" },
  async ({ input, step }) => {
    const user = await step.run({ name: "fetch-user" }, async () => {
      return await db.users.findOne({ id: input.userId });
    });

    await step.run({ name: "send-email" }, async () => {
      return await resend.emails.send({
        from: "[email protected]",
        to: user.email,
        replyTo: "[email protected]",
        subject: "Welcome!",
        html: "<h1>Welcome to our app!</h1>",
      });
    });

    await step.run({ name: "mark-welcome-email-sent" }, async () => {
      await db.users.update(input.userId, { welcomeEmailSent: true });
    });

    return { user };
  },
);

# npm
npx @openworkflow/cli init

# pnpm
pnpx @openworkflow/cli init

# bun
bunx @openworkflow/cli init