Read and write Amazon S3 from your local workflows
Run your state machines and Lambda functions locally while accessing real S3 buckets — no deployment, no stack updates, no waiting.
Local S3 mock support coming soon for fully offline development.
You shouldn't have to deploy your stack just to test an S3 read
Before Thrubit, testing a workflow that touched S3 meant pushing code, waiting for CloudFormation, configuring execution roles, and hoping the IAM policy was right — all just to see if your GetObject selector was correct.
Deploy. Wait. Check CloudWatch. Repeat.
Every iteration on an S3-integrated workflow required a full deploy cycle — SAM build, CloudFormation update, execution role sync — just to verify your ResultSelector mapped the right keys from a GetObject response.
Run locally. Hit real S3. Iterate instantly.
Open your state machine in Thrubit and run it. Your workflow executes locally while S3 calls go directly to your real buckets using your configured AWS profile. No deployment, no role sync, no CloudWatch waiting.
Your local execution reaches real S3 — automatically
When you run a state machine or invoke a Lambda in Thrubit, S3 calls are passed through to the real AWS API using the profile and region configured in your settings. No changes to your workflow definition, no environment variable overrides, no code modifications needed.
- Works for both Step Functions native S3 integrations (
arn:aws:states:::s3:getObject,s3:putObject) and direct SDK calls inside Lambda - Uses the same AWS profile and region as the rest of your Thrubit configuration
- IAM permissions on your local profile apply — so you catch access issues before they reach production
- No queue setup, no mock configuration — it works with real S3 out of the box
"Bucket":
"my-documents-prod",
"Key":
"templates/invoice.json"
}
"ContentType":
"application/json",
"ContentLength":
2048,
"ETag":
"\"d41d8…\"",
"Body":
"eyJ0eXBl…"
}
Actual S3 API responses — not stubs
Because Thrubit passes S3 calls through to real AWS, you get real responses — actual object content, real ETags, correct ContentType headers, and accurate error messages when permissions or keys are wrong. Your ResultSelector mappings work against real data from the start.
GetObjectreturns the realBody,ETag,ContentType,ContentLength, and user metadata from your bucketPutObjectreturns the actualETagandVersionIdafter the object is written to your bucket- Permission errors reflect your real IAM policies — so you catch access issues before they reach production
- No translation between mock and real formats — what you test locally is exactly what runs in production
S3 in state machines and Lambda — both work locally
S3 shows up in two places in Step Functions architectures: as a native service integration in the ASL, and as direct SDK calls inside Lambda functions. Thrubit handles both, passing requests through to your real buckets in either case.
- ASL-level integrations like
arn:aws:states:::s3:getObjectands3:putObjectare handled natively by the Thrubit execution engine - Lambda-side
AWS.S3.getObject(),putObject(), and other SDK calls reach real S3 through your configured profile - S3 Event payloads used as workflow inputs can be simulated by passing an S3 event object directly in the execution input
- Presigned URL generation works locally — your profile's credentials sign the URL, which remains valid for the configured expiry window
ASL Native Integrations
s3:getObjects3:putObjects3:deleteObjects3:listObjectsV2s3:copyObjects3:headObject
Direct SDK Calls
S3.getObject()S3.putObject()S3.deleteObject()S3.listObjectsV2()S3.copyObject()S3.getSignedUrl()
The S3 operations your workflows actually use
Thrubit supports the full range of S3 operations used in production Step Functions architectures — from simple reads and writes to presigned URL generation and bucket listing for Map state fan-outs.
Body, ETag, ContentType, ContentLength, and user metadata. The most common S3 operation in document processing workflows.ETag and — if versioning is enabled — the VersionId. Server-side encryption and storage class settings pass through correctly.Contents, IsTruncated, and NextContinuationToken — essential for fan-out patterns that process multiple objects using Map states.ContentType, ETag, LastModified, custom metadata — without fetching the body. Common in existence-check Choice states before processing.Local S3 mock — fully offline development
The next evolution for S3 in Thrubit: toggle S3 to local mock mode and run your entire workflow with zero AWS access. Instant responses. Full schema compatibility. Per-execution in-memory bucket state for object reads, writes, listings, and deletes — all without touching a real bucket.
ResultSelector mappings and Lambda parsing just work
Access real S3 from your first local run
No additional setup required beyond a configured AWS profile. Your local executions read and write real S3 buckets automatically.
In Thrubit's Settings, select the AWS profile and region you use for development. Any IAM permissions your profile has are available to your local executions — including S3 read and write access to your buckets.
Load your state machine from your local SAM template.yaml. Thrubit reads your ASL definition and resolves Lambda functions locally — including those that make S3 SDK calls inside their handlers.
Start an execution with your input. S3 task states execute against real AWS using your configured profile. Each state's inputs, outputs, and S3 response fields are visible in the real-time execution panel.
Update your ASL definition or Lambda handler and run again immediately — no SAM build, no CloudFormation update, no execution role sync. Your changes take effect on the next run.
Stop deploying just to test your S3 integration.
Download Thrubit and run your first S3-integrated state machine locally in under five minutes — real S3 reads and writes, zero deployment required.
What teams are saying
Real feedback from engineers, trainers and decision makers.
“Thrubit cut our Step Functions debugging cycle from 15 minutes per iteration down to seconds. The visual trace is worth the price alone. It’s become an essential part of our development workflow.”
“I was looking for ways to make Step Functions and Lambdas more tangible for students. Thrubit makes it significantly easier to visualize workflows and experiment locally, accelerating real understanding.”
“Thrubit saves us over $24k a year & protects us from surprise AWS bills. One rogue state machine once cost us 10x our typical month. With Thrubit, that risk is gone and our developers iterate faster.”
