Feature request: Official AWS adapter: @tanstack/workflow-aws

[ataylorme]

Feature request: Official AWS adapter — @tanstack/workflow-aws

I'd like to propose an official @tanstack/workflow-aws package for running TanStack Workflow on AWS, with DynamoDB backed durable execution and documented Lambda deployment patterns.

Motivation

For applications already deployed on AWS, it would be useful to adopt TanStack Workflow while keeping workflow state and execution within their existing infrastructure.

The goal is to preserve TanStack Workflow’s programming model while providing an AWS-specific persistence and coordination layer.

Proposed scope

• A DynamoDB implementation of the workflow execution-store contract.
• Durable state and history supporting signals, approvals, retries, and timers.
• Safe coordination between concurrent workers.
• Lambda and EventBridge examples for executing and resuming workflows.
• Documentation covering IAM, consistency requirements, retention, operational limits, and idempotent side effects.

Multi-region operation could be an advanced deployment option rather than a requirement for every user.

Experimental implementation

I built an experimental implementation here:

ataylorme/tanstack-workflow-aws

It provides a DynamoDB execution store and AWS deployment examples, including active/active execution using DynamoDB Global Tables with multi-region strong consistency (MRSC).

The prototype currently includes a matching TanStack Workflow engine snapshot. An official package should instead align with the upstream runtime and supported adapter interfaces.

This is a starting point for discussion and review, not a claim that the current implementation is ready for adoption unchanged.

Validation in a real AWS deployment

I integrated the adapter into a separate TanStack Start application

The documented validation covers:

• Starting a workflow in one region and reading or continuing it from another.
• Cross-region signal delivery and approvals.
• Retry behavior and duplicate-signal suppression.
• Concurrent start/signal requests and approval rejection.
• Durable timers completed by scheduled EventBridge workers.
• Matching workflow state and committed event history across regions.
• Controlled worker recovery by disabling one region’s schedule and verifying completion in the other.

That historical report concerns the earlier Git-pinned implementation. I also subsequently deployed the published @ataylorme/tanstack-workflow-aws@0.1.0 package and reran the cross-region workflow acceptance checks successfully.

These are bounded integration tests, not production certification, load testing, or proof of resilience to an actual AWS regional outage.

Important design boundaries

The prototype’s active/active coordination relies on MRSC, not ordinary eventually consistent Global Tables. External side effects still require application-level idempotency, and loss of quorum prevents safe writes. Retention, payload limits, and high-throughput behavior also need further work and review.

Questions for maintainers

1. Would you welcome an AWS contribution following this existing host/store split, and is anyone already working on one?
2. Should an initial contribution focus on the Lambda/EventBridge host adapter, the DynamoDB store, or both as separate packages?
3. For the DynamoDB store, should the initial supported scope be single-region, with MRSC active/active support introduced after additional review and testing?

The existing packages and contract suite provide a concrete starting point. I'd appreciate feedback on contribution scope and AWS-specific acceptance criteria, especially for multi-region coordination.