Skip to main content

workflowd (Python SDK)

Write durable workflows in plain Python and run them on workflowd, a single-binary durable workflow engine. Zero dependencies: the standard library only.

from workflowd import ActivityFailure, Worker, WorkflowFailure

worker = Worker(address="http://localhost:8233")

@worker.workflow("Order")
def order(ctx):
    reserved = ctx.activity("reserve", ctx.input)
    ctx.sleep("settle", 2.0)  # durable: survives an engine restart
    try:
        ctx.activity("charge", reserved)
    except ActivityFailure as err:
        ctx.activity("release", reserved)  # compensate
        raise WorkflowFailure(f"charge failed: {err}")
    return ctx.activity("ship", reserved)

@worker.activity("reserve")
def reserve(payload):
    return f"reserved({payload})"

worker.run()

More of the API:

# Run activities in parallel; race a signal against a deadline.
stock, price = ctx.wait_all(ctx.activity_async("stock", sku), ctx.activity_async("price", sku))
late = ctx.wait_any(ctx.wait_for_signal_async("reply", "approved"), ctx.sleep_async("sla", 3600), cancel_rest=True) == 1

# Retry a failed attempt before the workflow sees the error; JSON and bytes payloads.
receipt = ctx.activity("charge", {"amount": 42}, retry=RetryPolicy(max_attempts=3, initial_backoff=0.5), decode="json")

# Some failures are not worth retrying: raise NonRetryableError in the activity, or name
# exception classes in the policy: RetryPolicy(max_attempts=5, non_retryable_error_types=("ValueError",)).

# Bound one attempt and the whole step (seconds); bound a whole run when you start it.
ctx.activity("render", doc, start_to_close_timeout=30, schedule_to_close_timeout=300)
worker.start_workflow("Order", order, f"order-{order['id']}", execution_timeout=86400)
# Idempotent start: the run already holding the id comes back instead of a 409.
run = worker.start("Order", order, f"order-{order['id']}", id_conflict_policy="USE_EXISTING")

# Change code safely while executions are in flight; record a non-deterministic value once.
if ctx.get_version("fraud-check", DEFAULT_VERSION, 1) == 1:
    ctx.activity("fraud-check", receipt)
order_id = ctx.side_effect("id", lambda: str(uuid.uuid4()))

# A loop that runs forever keeps its history small: a fresh run, same workflow id.
if ctx.continue_as_new_suggested():
    return ctx.continue_as_new(state)

# A deterministic clock and random numbers (the same on every replay); wait with a timeout.
deadline = ctx.now() + timedelta(days=2)
ctx.sleep_until("reminder", deadline)
jitter = ctx.random()
reply = ctx.wait_for_signal("reply", "approved", timeout=3600)  # None if none arrives in time

Cancel gracefully with worker.cancel(id, reason, graceful=True): the step the workflow waits on raises CancelledFailure, steps it starts afterwards run normally (compensate there), and re-raising it ends the workflow CANCELLED; ctx.cancel_requested says it was told.

A cluster: Worker(addresses=["http://n1:8233", "http://n2:8233", "http://n3:8233"]) follows the leader. Activities longer than the lease heartbeat automatically; an activity taking a second info argument can check info["lease_lost"].

For an engine with auth and TLS: Worker(address="https://…:8233", token=..., ca_file=...) (ca_file only for a private CA). With a namespace's token the worker works in that namespace; with the engine's token, pick one with namespace="acme" (engine 0.4.0+).

Tracing (engine 0.5.0+): worker.start("Order", order, traceparent=headers["traceparent"]) makes the run a child span of the caller's (W3C Trace Context). The code reads the run's span as ctx.traceparent; an activity taking info gets its attempt's span as info["traceparent"] to put on the requests it makes, so they join the trace.

Task queues (engine 0.4.0+): Worker(task_queue="billing") polls only the billing queue, and its start() calls run workflows there; their activities run there too unless a call says ctx.activity("send", payload, task_queue="email"). Without one, everything uses the default queue.

Workflow code must be deterministic: no clocks, randomness or I/O except through ctx (ctx.now(), ctx.random()). How replay works, and the protocol, are in the SDK guide. Pre-alpha: the API may change. Apache-2.0.

Metadata

Release files for workflowd 0.5.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for workflowd 0.5.0
File Size Uploaded Provenance
workflowd-0.5.0.tar.gz 21.2 kB With provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for workflowd 0.5.0
File Interpreter ABI Platform
workflowd-0.5.0-py3-none-any.whl Python 3 none any Details

Total release size: 43.5 kB

Release files / workflowd-0.5.0.tar.gz

Download URL workflowd-0.5.0.tar.gz
Size 21.2 kB
Tags Source
SHA-256 checksum
How to use checksums
4bca0a596dd886d2a3eb2f72e784270a1242191979a2fb52d064911c5a277ead
BLAKE2b-256 checksum
How to use checksums
873ea4f7931be36d08f78da61128e68c2948023e8878309c29df3bbafe88df1e
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 25, 2026.

Transparency log

Release files / workflowd-0.5.0-py3-none-any.whl

Download URL workflowd-0.5.0-py3-none-any.whl
Size 22.3 kB
Tags Python 3
SHA-256 checksum
How to use checksums
950d5dd6b16feca59cbe720ac8c3e441999c9d681872c5534ece4174d0d577a7
BLAKE2b-256 checksum
How to use checksums
16874a98b4a4f8806af8c1c838357e16b3645594eb473eecc9f0f21ec3aae819
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 25, 2026.

Transparency log

Security for workflowd 0.5.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for workflowd-0.5.0.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 25, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page