Modular · Interoperable · TypeScript-native

Built on xSync.WTF

Define actions, services, and flows once. Run them anywhere.

xFlow is the modular, interoperable workflow layer for TypeScript codebases. Mix- and-match registries (local fs, S3-compatible bucket, HTTPS) and substrates (in-memory, disk, Postgres) so the same flow definition runs in a CLI, a Next.js route, a browser tab, or a Docker worker — without rewriting it.

Modular

Pick a registry · pick a substrate

Interoperable

fs · http · s3worm · postgres · xsync

Drop-in

pnpm add @decoperations/xflow-cli

Workflow definition

Typed graph, explicit claims, explicit placement.

v0.1 shape
const workflow = defineWorkflow({
  id: "campaign.publish",
  version: "1.0.0",
  steps: {
    draft: defineStep({
      id: "draft",
      type: "llm.generate",
      sideEffects: { kind: "idempotent", idempotencyRequired: true },
    }),
    approve: defineStep({
      id: "approve",
      type: "human.approve",
      placement: { allowed: ["browser-tab"] },
      sideEffects: { kind: "pure", idempotencyRequired: false },
    }),
    publish: defineStep({
      id: "publish",
      type: "social.post",
      claim: { mode: "authority", authorityActorId: "server" },
      placement: { forbidden: ["browser-tab"] },
      sideEffects: { kind: "irreversible", idempotencyRequired: true },
    }),
  },
  links: [
    link("draft", "approve", { when: { type: "step.succeeded" } }),
    link("approve", "publish", { when: { type: "step.succeeded" } }),
  ],
})

Architecture

xFlow stays small by standing on xSync instead of competing with it.

The Buckets.WTF and xSync.WTF sites work because the message is sharp and the layers are obvious. xFlow needs the same treatment: workflow semantics on top, sync fabric underneath, and swappable storage and transport below that.

Workflow semantics

Define typed steps, links, retries, claim policies, and placement rules without rebuilding durable execution from scratch.

defineWorkflow()
defineStep()
link()
flowRunView

Signed actor logs

Every run is one xSync actor. Step lifecycle changes become signed events in a multi-writer causal log.

Ed25519 events
causal DAG
materialized views
replication

Durability and transport

Keep cold state on S3WORM and replicate with browser, worker, SSE, HTTP, or WebSocket transports as needed.

S3WORM
IndexedDB
FS / SQLite
WS / SSE / HTTP

Capabilities

The workflow engine is opinionated where it matters and neutral where it should be.

Start with the quick start

One definition, many runtimes

The same workflow can advance in a browser tab, continue in a Next.js route, and finish on a worker without changing the workflow shape.

Claims match blast radius

Use `authority` for irreversible work, `lease` for external APIs, or optimistic modes when duplicate execution is acceptable.

Replayable run history

Outages are recovery events, not data loss events. Rebuild flow state by replaying signed events from storage.

Placement is explicit

Attach capability requirements to each step and let the runtime decide where a step is allowed to execute.

Packages stay focused

Core, runtime, local provider, React hooks, Next handlers, XState bridge, and S3 helpers all stay small and composable.

Docs-first API surface

The landing page sells the idea; the docs page explains the workflow model, runtime primitives, and package map without hand-wavy claims.

Related systems

Adjacent to durable-function stacks, but optimizing for a different core model.

Workflow SDK and Vercel Workflow are useful comparison points. xFlow is closer to a replicated workflow state machine built on signed actor logs, not just a durable server-side function runner.

Workflow SDK

Open-source durable TypeScript functions using `"use workflow"` and `"use step"` directives. Strong fit for resumable server-side async logic and AI agents.

Vercel Workflow

Managed hosting layer for the Workflow Development Kit on Vercel Functions, Queues, and managed persistence.

workflow-builder-starter

A Next.js starter for building Zapier-style visual automation products on top of Vercel's workflow stack.

Claim policies

Different work deserves different guarantees.

xFlow should not pretend draft generation, email send, and card charge are the same kind of execution. Claim strategy is part of the step contract.

authority

Irreversible side effects like email, billing, and publish steps.

deterministic-election

Pure or duplicate-tolerant compute where peers can resolve a winner.

optimistic-idempotent

Work where the first valid result wins and duplicates are harmless.

lease

External calls that need ownership, heartbeats, and retryable timeouts.

Runtime rail

Same workflow, three natural execution environments.

xFlow is strongest when the UI, the API surface, and the background worker are all first-class peers instead of awkward adapters bolted onto a central service.

Browser tab

Human approval, local-first UX, and safe compute with live step state.

Next.js API

Trusted server authority, signed heads/events routes, and S3 proxy boundaries.

Node worker

Always-on executors, artifact handling, and long-running background jobs.