Run and Debug SQS Workflows Locally with Zero AWS Cost

Thrubit continues to close the gap between local development and real AWS execution. With the latest release (Thrubit 1.3.3), Amazon SQS is now fully supported inside local Step Functions execution, giving developers the ability to build, test, and debug queue-driven workflows without deploying to AWS.

This is a meaningful upgrade for teams building event-driven systems, asynchronous pipelines, and distributed architectures that rely on SQS as a backbone.

Why SQS Support Matters

SQS is one of the most commonly used services in AWS Step Functions workflows. It powers:

Decoupled microservices
Event buffering and retry strategies
Batch processing pipelines
Fan-out and async task distribution

Until now, testing these patterns locally has been difficult or incomplete. Developers often had to:

Deploy to AWS just to validate queue interactions
Stub or fake SQS logic manually
Accept slow feedback loops and unpredictable costs

With this release, that friction is gone.

What’s New in Thrubit

Local Execution of `sqs:sendMessage`

You can now run Step Functions that include:

arn:aws:states:::sqs:sendMessage

directly inside Thrubit.

Messages are sent locally during execution
A valid MessageId is returned
Works seamlessly with ResultPath and downstream states

This means your workflows behave the same way locally as they do in AWS, without needing to deploy or configure infrastructure.

waitForTaskToken Support (Non-Blocking)

Thrubit now supports:

.waitForTaskToken

for SQS integrations.

In local execution:

These states complete immediately
They do not block execution
Behavior is consistent with other task token integrations in Thrubit

This design keeps your workflows moving during development while still allowing you to validate structure and logic.

Mock SQS Mode (Default)

A new setting is available under:

Settings → AWS → Mock SQS

Start free. No AWS account needed.
ZERO AWS costs.

Download Thrubit and run your first state machine locally in under five minutes. No cloud setup, no IAM policies, no waiting.

Download for Free Book a Demo

Enabled by default
No AWS credentials required
No queues need to exist
No costs incurred

When mock mode is active:

Messages are simulated
MessageIds are generated automatically
Execution logs still capture full request/response structure

When disabled:

Thrubit will send real messages to AWS SQS

This flexibility allows you to switch between fast local testing and real integration validation instantly.

SQS Visualization in Graph View

SQS states now appear visually in the execution graph with the official service icon.

This enhances:

Workflow readability
Debugging clarity
Execution tracing

You can quickly identify where messages are sent within your state machine and how they impact downstream states.

For complex workflows, this becomes a major usability improvement, especially when combined with Thrubit’s execution history and input/output inspection.

Auto Region Detection from QueueUrl

One subtle but powerful addition:

Thrubit now reads the region directly from the QueueUrl

This means:

Cross-region queues work automatically
No dependency on your global AWS region setting
Fewer configuration errors

This mirrors real AWS behavior more closely and removes a common source of bugs during development.

What This Means for Developers

Build Real Event-Driven Workflows Locally

You can now fully model:

Producer → SQS → consumer pipelines
Fan-out messaging patterns
Retry and dead-letter scenarios
Async orchestration flows

All without touching AWS.

Eliminate Deployment Loops

Before:

Write workflow
Deploy to AWS
Run execution
Inspect logs
Repeat

Now:

Write workflow
Run instantly in Thrubit
Debug visually
Iterate immediately

This dramatically reduces development time and friction.

Reduce AWS Costs During Development

SQS calls, Step Functions transitions, and Lambda invocations add up quickly during testing.

With mock mode:

No SQS charges
No Step Functions execution charges
No Lambda execution costs

You can iterate as much as needed without worrying about unexpected bills.

Debug with Full Visibility

Because SQS is now part of the local execution engine:

You see exactly what message payload is sent
You can inspect MessageIds and outputs
You can trace how data flows through the system

This level of visibility is difficult to achieve in AWS without stitching together logs across multiple services.

Real-World Use Cases

This release unlocks local development for workflows such as:

Payment processing pipelines with async settlement queues
Order fulfillment systems using SQS buffering
Data ingestion pipelines with queue-based batching
AI/ML pipelines triggering downstream processing jobs
Microservice orchestration using message passing

If your architecture uses SQS anywhere in Step Functions, you can now develop it entirely locally.

Thrubit Continues to Close the Gap

With SQS support, Thrubit moves even closer to a complete local execution environment for AWS Step Functions.

Combined with existing support for:

Lambda invocation
Nested state machines
Map and Parallel states
Bedrock integrations

You now have a powerful way to:

Run Step Functions locally with real execution behavior, debug visually, and iterate instantly without AWS costs.

Final Thoughts

SQS is a foundational piece of modern serverless architecture. Bringing it into local execution is not just a convenience, it is a major productivity unlock.

This release gives developers:

Faster feedback loops
Lower development costs
More confidence before deploying to AWS

If you are building event-driven systems with Step Functions, this update removes one of the last major barriers to fully local development.

And once you experience debugging SQS workflows visually, it is very hard to go back.