Forem: Twisted-Code'r

Free for PUBLIC REPOS in Github

Twisted-Code'r — Tue, 12 May 2026 16:27:43 +0000

Twisted-Code'r

May 8

I Built a GitHub App That Catches AI and Cloud Security Mistakes Automatically — In 4 Days, Zero Budget

#github #ai #security #cloud

Comments

3 min read

I Built a GitHub App That Catches AI and Cloud Security Mistakes Automatically — In 4 Days, Zero Budget

Twisted-Code'r — Fri, 08 May 2026 08:00:04 +0000

Four days ago I had an idea. Today it's live, catching real security issues in real pull requests.

This is the story of how I built VrothSec — a GitHub App that automatically reviews every PR for AI and cloud security mistakes — with no money, no team, and no prior experience shipping a SaaS.

The Problem

Most security tools were built before AI apps existed.

They don't know what an exposed OpenAI key looks like. They don't flag overpermissioned IAM roles. They don't catch unprotected model endpoints or prompt injection risks through retrieval chains.

A developer in the comments of my build-in-public post put it better than I could:

"The real risk usually is not just leaked keys. It is model endpoints with no auth or rate limits, overly broad IAM on storage and inference paths, prompt injection exposure through retrieval and tool use, logging sensitive prompts into places they should never land."

That's exactly what existing tools miss. That's the gap VrothSec fills.

What VrothSec Catches

Install it on your repo. It runs automatically on every PR and flags:

🔴 Hardcoded API keys — OpenAI, Anthropic, AWS, GCP credentials committed in code
🔴 Unsafe S3 configs — buckets set to public-read
🟠 Missing rate limiting on AI inference endpoints
🟠 Overpermissioned IAM roles on storage and inference paths
🟡 Prompt injection risks through retrieval chains and tool use
🟡 Sensitive prompt logging — outputs written to places they should never land

Here's a real example of what it posted on one of my test PRs:

🔒 Cloud Security Review

🔴 Critical — cloud_config.py, Line 5
Hardcoded AWS Access Key detected.
Fix: Use environment variables or AWS IAM roles.

🔴 Critical — cloud_config.py, Line 9
Hardcoded OpenAI API key detected.
Fix: Use environment variables or a secrets manager.

🟠 High — cloud_config.py, Line 13
S3 bucket set to public-read.
Fix: Remove ACL='public-read' and restrict with IAM policies.

🟡 Medium — cloud_config.py, Line 18
No rate limiting on AI inference endpoint.
Fix: Add rate limiting to prevent abuse.

File. Line number. Issue. Fix. No manual review needed.

The Stack

Probot — GitHub App framework (Node.js)
Google Gemini 2.5 Flash Lite — free tier, 1500 requests/day
Render — free hosting
GitHub API — stores subscriber data in a private repo (no database needed)
Paddle — handles subscriptions and billing

Total cost to build and run: $0

The Hardest Part

Not the code.

The hardest part was figuring out the payment logic. Specifically: how do you gate a GitHub App by subscription without a database, without a backend, without any infrastructure?

My solution: store paying customers as installation IDs in a subscribers.json file in a private GitHub repo. When a PR opens, the app checks the file. If the installation ID is there — scan. If not — post a subscription prompt.

No database. No server. No maintenance. Just a JSON file and the GitHub API.

When someone pays, the Paddle webhook fires and writes their installation ID to the file automatically. Zero manual intervention.

The Business Model

Free for public repos. Open source projects get full security scanning at no cost.

$15/month for private repos. That's the founding member price — locked in forever for the first 10 subscribers.

The logic: developers building commercial AI products on private repos are the ones with the most to lose from a security breach. One exposed key can cost thousands. $15/month is nothing compared to that.

What I Learned

Ship before you're ready. I posted about this on Indie Hackers on Day 1 before writing a single line of code. The comments I got shaped what I built. The positioning feedback, the security failure modes I hadn't thought of — all came from sharing early.

The wedge matters. "GitHub bot" is a distribution frame, not a product frame. VrothSec is security infrastructure for AI shipping workflows. The name and positioning need to reflect that as it grows.

Free tools are enough. Gemini free tier, Render free tier, GitHub free tier. You don't need money to build and launch a real product in 2026.

What's Next

GitHub Marketplace submission
Paddle webhook integration for automated activation
More detection rules — model endpoint exposure, insecure deserialization in ML pipelines, secrets in Dockerfiles

Try It

VrothSec is free for public repos. Install it in 30 seconds:

👉 github.com/apps/vrothsec

For private repos: vrothsec.com

Founding member spots: 10 available at $15/month, locked in forever.

If you build on AWS or use AI APIs in your stack — this is built for you.

Questions, feedback, or roasting welcome in the comments.

I built a free open-source LocalStack alternative in Go — v0.7.0 is out

Twisted-Code'r — Thu, 07 May 2026 09:48:36 +0000

CloudDev v0.7.0 is live 🚀

CloudDev is a free, open-source local AWS emulator built in Go — a self-hosted alternative to LocalStack. No Docker, no Python, no Java. Just a single binary.

Today I'm releasing v0.7.0 with 6 new AWS services, bringing the total to 43 emulated services.

👉 github.com/Jeffrin-dev/CloudDev

Why I built this

LocalStack is great — but the free tier is limited and the pro tier is expensive. I wanted something that:

Works completely offline
Has zero runtime dependencies
Is free forever, for everyone
Is open source and hackable

So I built CloudDev.

What's new in v0.7.0

This release focuses on compute infrastructure, managed data services, and developer tooling — the services that make CloudDev viable for real-world application stacks beyond serverless.

EC2 (port 4600)

Instance lifecycle, AMIs, key pairs, and security groups.

aws --endpoint-url=http://localhost:4600 ec2 run-instances \
    --image-id ami-00000001 --instance-type t2.micro --key-name mykey

RDS (port 4601)

DB instances, snapshots, and parameter groups. PostgreSQL and MySQL supported.

aws --endpoint-url=http://localhost:4601 rds create-db-instance \
    --db-instance-identifier mydb --db-instance-class db.t3.micro \
    --engine postgres --master-username admin --db-name mydb

OpenSearch (port 4602)

Domain management and tag support.

aws opensearch create-domain --domain-name mydomain \
    --engine-version OpenSearch_2.3 \
    --endpoint-url http://localhost:4602

MSK — Managed Kafka (port 4603)

Cluster management with realistic bootstrap broker endpoints.

aws kafka create-cluster --cluster-name mycluster \
    --number-of-broker-nodes 2 --kafka-version 3.4.0 \
    --broker-node-group-info InstanceType=kafka.m5.large,ClientSubnets=subnet-1 \
    --endpoint-url http://localhost:4603

CodePipeline (port 4604)

Full pipeline lifecycle with execution tracking.

aws codepipeline start-pipeline-execution \
    --name mypipeline --endpoint-url http://localhost:4604

WAF (port 4605)

Web ACLs, rule groups, and resource associations.

aws wafv2 create-web-acl --name myacl --scope REGIONAL \
    --default-action Allow={} \
    --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=myacl \
    --endpoint-url http://localhost:4605

Quick start

git clone https://github.com/Jeffrin-dev/CloudDev.git
cd CloudDev
go build -o clouddev .
./clouddev init my-app
cd my-app
../clouddev up

That's it. All 43 services start instantly.

Full service list

43 services: S3, DynamoDB, DynamoDB Streams, Lambda, Lambda Layers, Lambda Function URLs, SQS (+ FIFO), SNS, API Gateway, API Gateway v2, IAM, STS, KMS, CloudFormation, Step Functions, EventBridge, CloudWatch Events, Secrets Manager, CloudWatch Logs, CloudWatch Metrics, ElastiCache, Cognito, X-Ray, Route53, SSM Parameter Store, Rekognition, SES, Bedrock, Kinesis Data Streams, Kinesis Firehose, ECS, ECR, CloudFront, AppSync, Athena, ACM, EC2, RDS, OpenSearch, MSK, CodePipeline, WAF, and Dashboard.

What's next

I'm focused on stability and community feedback for now. If there's a service you need, open an issue on GitHub!

⭐ If CloudDev saves you time or money, a star on GitHub goes a long way.

👉 github.com/Jeffrin-dev/CloudDev

Built for Devs · Apache 2.0

I built a free LocalStack alternative in Go — v0.6.0 is out with 37 AWS services

Twisted-Code'r — Wed, 06 May 2026 05:35:48 +0000

So I've been working on this project called CloudDev for a while now. It's basically a local AWS emulator — think LocalStack but free, open source, and a single Go binary with zero dependencies.

I just shipped v0.6.0 and wanted to share what's new.

Why I built this

Honestly? LocalStack's free tier kept getting more and more limited. Every time I needed a service it was "pro only". I just wanted to test my AWS code locally without spinning up real infrastructure or paying for a subscription.

So I started building CloudDev. The goal was simple — emulate the AWS services I actually use, make it work with the existing AWS CLI and SDKs without any config changes, and keep it as a single binary I can just run anywhere.

What's new in v0.6.0

This release was focused on infrastructure completeness. I added 8 new services:

Kinesis Data Streams — shards, records, iterators, the whole thing
Kinesis Firehose — delivery streams, PutRecord, PutRecordBatch
ECS — clusters, task definitions, run/stop tasks
ECR — repositories, image push/pull, auth token
CloudFront — distributions, origins, invalidations
AppSync — GraphQL APIs, data sources, schema upload
Athena — query execution, results, named queries
ACM — certificates, tags, mock PEM output

That brings the total to 37 AWS services across 47 modules.

Quick start

git clone https://github.com/Jeffrin-dev/CloudDev.git
cd CloudDev
go build -o clouddev .

./clouddev init my-app
cd my-app
../clouddev up

That's it. All 37 services start up immediately.

Some examples

# Kinesis
aws --endpoint-url=http://localhost:4568 kinesis create-stream \
  --stream-name my-stream --shard-count 2

aws --endpoint-url=http://localhost:4568 kinesis put-record \
  --stream-name my-stream --data "hello" --partition-key "pk1"

# ECS
aws --endpoint-url=http://localhost:4561 ecs create-cluster \
  --cluster-name my-cluster

aws --endpoint-url=http://localhost:4561 ecs register-task-definition \
  --family my-task \
  --container-definitions '[{"name":"app","image":"nginx","memory":128}]'

# ECR
aws --endpoint-url=http://localhost:4562 ecr create-repository \
  --repository-name my-repo

aws --endpoint-url=http://localhost:4562 ecr get-authorization-token

# Athena
aws --endpoint-url=http://localhost:4564 athena start-query-execution \
  --query-string "SELECT * FROM my_table" \
  --query-execution-context Database=mydb

# ACM
aws --endpoint-url=http://localhost:4560 acm request-certificate \
  --domain-name example.com

No endpoint configuration files, no fake credentials setup beyond the usual AWS_ACCESS_KEY_ID=test — just point the CLI at localhost and it works.

Full service list

Service	Port
ACM	4560
ECS	4561
ECR	4562
CloudFront	4563
Athena	4564
S3	4566
AppSync	4567
Kinesis Data Streams	4568
DynamoDB	4569
DynamoDB Streams	4570
Kinesis Firehose	4571
API Gateway	4572
API Gateway v2	4573
Lambda	4574
SNS	4575
SQS	4576
Lambda Layers	4578
SES	4579
Dashboard	4580
CloudFormation	4581
CloudWatch Metrics	4582
SSM Parameter Store	4583
Secrets Manager	4584
Step Functions	4585
CloudWatch Logs	4586
EventBridge	4587
X-Ray	4588
Route53	4589
CloudWatch Events	4590
Bedrock	4591
STS	4592
IAM	4593
Rekognition	4594
Lambda Function URLs	4595
Cognito	4596
ElastiCache	4597/4598
KMS	4599

Web dashboard

There's also a web dashboard at localhost:4580 that shows all running services in real time. It flips red when the server goes down which is a small thing but honestly pretty useful when you're running tests.

How it's built

It's pure Go 1.22, no external runtime dependencies. Each AWS service is its own HTTP server listening on its port, routing requests by the X-Amz-Target header or REST path depending on the service protocol.

One thing I learned the hard way — AWS CLI doesn't always use the protocol the docs say it does. KMS, Kinesis, ECS, ECR all use JSON + X-Amz-Target. CloudFront uses REST + XML. AppSync uses REST + JSON. I had to sniff actual requests with nc a few times to figure out what the CLI was actually sending.

What's next

Not sure yet honestly. Maybe RDS, SQS dead letter queues, or better Lambda container support. Open to suggestions.

If you try it out let me know what breaks. There's definitely rough edges still.

GitHub:github.com/Jeffrin-dev/CloudDev

BUILD FOR DEVS

I wasted 45 minutes debugging a GitHub Actions failure that turned out to be a one-line fix

Twisted-Code'r — Wed, 29 Apr 2026 12:01:03 +0000

The logs were 800 lines long. Nothing obvious. I compared two runs manually, checked Stack Overflow, and eventually found it.

This happens to me every week. I'm a solo dev — I don't have an SRE team to hand this off to.

The existing tools don't solve this. GitHub's UI shows you logs but doesn't explain them. Writing custom scripts to analyze runs works but takes time I don't have.

So I'm building a GitHub App that does one thing:
Tells you exactly why your GitHub Actions pipeline failed or slowed down — in plain English.

No more log archaeology
Spots flaky steps across runs automatically
Works instantly on any repo

$15/month. 2-click install like any GitHub App.

Question for fellow devs: how much time do you lose weekly to CI failures or slow pipelines? Would plain-English explanations actually help?

Validating before building — honest feedback appreciated.

I spent 2 hours manually checking Dev.to, IH, and GitHub for mentions of my product. There has to be a better way.

Twisted-Code'r — Mon, 27 Apr 2026 09:30:32 +0000

Update: Changed pricing to freemium based on feedback — Free for 1 product, $5/month for unlimited.

I launched a small dev tool recently. My entire distribution strategy is:

Reply to relevant threads fast
Show up where people are already asking questions

The problem? I manually check Dev.to, Indie Hackers, and GitHub Discussions every single day. By the time I find a relevant thread it's already 2 days old and buried.

F5Bot solves this for Reddit. Nothing solves it for Dev.to, IH, and GitHub.

So I'm building it.

Simple concept:

Enter your product name + keywords
Get alerted when someone mentions it on Dev.to, IH, or GitHub Discussions
Reply fast, while the thread is still warm

Free for 1 product. $5/month for unlimited.

No dashboards. No fluff. Just alerts.

Quick question: do you manually check these platforms for mentions? Would instant alerts actually save you time?

Honest yes/no — validating before building.

AUTO WRITES PR FOR YOU - PRDRAFT

Twisted-Code'r — Sat, 18 Apr 2026 07:17:35 +0000

Twisted-Code'r

Apr 11

I got tired of PRs that just said "fix" — so I built a GitHub App that writes the description for you

#showdev #automation #github #productivity

Comments

3 min read

I got tired of PRs that just said "fix" — so I built a GitHub App that writes the description for you

Twisted-Code'r — Sat, 11 Apr 2026 10:54:30 +0000

We've all seen it.

You open a pull request from a teammate — or your past self — and the description says:

"fix bug"

That's it. No context. No what changed. No why. You're now a code archaeologist trying to reverse-engineer intent from a diff.

I've been that person. I've also been on the reviewing end, nudging people repeatedly for context that should've been in the description from the start. It's death by a thousand tiny frustrations.

The real problem isn't laziness

Developers don't skip PR descriptions because they don't care. They skip them because by the time the code is done, switching context to write documentation feels like starting a second job. You've been deep in the problem for hours. Writing "what changed and why" in plain English requires a different gear entirely.

So most people don't. Or they write something just good enough to pass review, which ends up useless to anyone reading it six months later.

What I built

I'm a solo developer in Kerala, India, building PRDraft — a GitHub App that reads your PR diff and auto-writes a structured description. Two-click install, zero config.

When you open a PR, it:

Fetches the diff
Sends it to an LLM (Groq / llama-3.3-70b)
Posts a structured description directly to your PR body

The output looks like this:

## What changed
Refactored the auth middleware to use JWT validation instead of session cookies.
Removed the legacy session store dependency.

## Why
Session-based auth was causing intermittent failures in the load-balanced setup.
JWT tokens eliminate the shared state problem entirely.

## How to test
- Log in with an existing account — confirm token is returned in response header
- Test expired token path — confirm 401 is returned correctly

Not perfect every time. But dramatically better than "fix auth" — and it takes zero effort from the developer.

Stack (all free)

Next.js on Vercel
Supabase (PostgreSQL)
Groq API (free tier — 14,400 req/day)
Paddle for payments
GitHub App webhooks via Octokit

Total infra cost: $0/month. Built this in evenings over 4 weeks while learning most of it as I went.

The thing nobody tells you about building GitHub Apps

The hardest part wasn't the AI integration. It was webhook deduplication.

GitHub retries webhooks aggressively if your endpoint doesn't respond in time. I once had a single PR trigger 38 webhook calls. My PR count was wildly inflated, users were hitting the free tier cap immediately, and I had no idea why.

Fix: unique constraint on (installation_id, pr_number) in Supabase, plus a dedup guard before processing. The webhook still fires 38 times — but only the first one does anything.

If you're building on GitHub webhooks, add this early. Don't find out the hard way like I did.

Where it is now

Live at github.com/apps/prdraft
Free for first 5 PRs, then $9/month
2 installs so far (one of which is me)
GitHub Marketplace listing submitted, waiting on review

No paid users yet. That's the next problem to solve.

Try it

If you're tired of writing PR descriptions — or tired of reviewing PRs with no context — install it and let me know what the output looks like on your actual diffs.

Feedback at this stage means everything. I read every reply.

Install PRDraft — free for 5 PRs

Review

Building in public. Day 10 of however long this takes.

I built a GitHub App that auto-writes PR descriptions — here's what happened in 8 days

Twisted-Code'r — Mon, 06 Apr 2026 17:30:22 +0000

I hate writing PR descriptions.

Not because I'm lazy — I know what I changed. Articulating it clearly, in a format that helps reviewers, takes 10 extra minutes of context switching. Every. Single. Time.

So I built PRDraft — a GitHub App that reads your diff when you open a PR and posts a structured description automatically. 2-click install, zero config, no CLI.

Here's what 8 days of building looks like from scratch, solo, from Kerala, India.

Day 1–2: Does anyone actually care?

Before writing a single line of code I posted in GitHub Discussions and dropped a question on Dev.to:

"Who actually writes good PR descriptions consistently?"

Got real responses. Two that stuck:

"Yes, real pain point especially on fast-moving teams"
"I'd trust it if it accurately reflects the diff and I can edit before submitting"

That was enough. Building justified.

Day 3–5: Building the thing

Tech stack I landed on:

Next.js (App Router) + Tailwind
Supabase (PostgreSQL) for installs and PR event tracking
Groq API (llama-3.3-70b-versatile) for AI generation — genuinely free, 14,400 requests/day, works in India
Octokit for GitHub App integration
Vercel for hosting

Why Groq instead of Claude or Gemini:

Anthropic API costs money, no free tier
Google Gemini free tier has limit:0 quota for India region — confirmed bug
Groq is genuinely free and fast

Total infra cost: $0/month

The core flow:

User opens PR → GitHub sends webhook → verify signature → 
fetch diff → send to Groq → post structured description back to PR

The generated description looks like this:

## What changed
- Added webhook signature verification using Octokit
- Introduced free tier cap logic (5 PRs/month) checked before incrementing

## Why
Prevents unauthorized webhook calls and limits free usage before billing is set up.

## How to test
- Open a PR on a repo where PRDraft is installed
- Check that the description is auto-populated within seconds

## Notes
Free tier cap is checked BEFORE incrementing pr_count to avoid off-by-one errors

Day 5: First external user

roshhellwett installed it, opened a PR, got a description within seconds.

Their feedback: "Works as expected — the structure is solid and actually saves time. Groq is noticeably fast. For complex PRs with scattered changes it can feel a bit generic — but as a starting point to edit from? Definitely useful."

That was the moment this stopped being a side project and started being a product.

Day 6–7: Bug fixes and distribution

Bugs I fixed:

Free tier cap was incrementing BEFORE the check — off-by-one error meant users got 6 PRs, not 5
account_login was being overwritten as 'unknown' on every PR event — upsert was hitting the wrong fields
GitHub retries webhooks every 15s on timeout — PR #15 fired 38 times. Fixed with a unique constraint on (installation_id, pr_number)

Distribution channels I tried:

Dev.to — fully open, post live ✅
Indie Hackers — post live, daily updates ✅
GitHub Marketplace — submitted for review ✅
Reddit — karma 3, blocked until Day 9
Hacker News — karma -8, commenting daily to recover

Painful lesson: Every platform blocks new accounts. Don't assume channels are open.

Day 7: Dashboard

Built a full dashboard at /dashboard:

Plan badge (Free / Pro)
PRs used vs cap with a colour-coded progress bar
Recent PR activity — repo, PR number, timestamp
Upgrade CTA
Installation info

GitHub automatically redirects users to the dashboard after install via the Setup URL — no OAuth needed.

Day 8: More dashboard improvements

Shipped today:

Recent activity now shows PR titles alongside repo and PR number
Every generated PR description now has a dashboard link in the footer — so anyone on the team can check usage without hunting for the URL
Free tier cap now posts a comment directly on the PR when the limit is hit, instead of silently doing nothing

The payment provider saga

This is the part nobody talks about.

Building the product took days. Setting up payments is taking longer.

Stripe — invite-only in India since 2024
Lemon Squeezy — international payments blocked for individuals in India
Gumroad — payout setup issues for Indian bank accounts
Paddle — working on it

The product is ready to charge. The money pipe is the blocker.

Update Apr 18: Automated outreach system now running daily. 57+ emails sent to team leads.

Current numbers (Day 8)

Metric	Value
Installs	2
Paid users	0
MRR	$0
PRs described	13
Infra cost	$0/month

What's next

Get payment provider working (Paddle)
Invite more beta users
Reddit posts unlock ~Day 9
HN karma grind back to positive
Month 2: first paid conversion push

Try it

2-click install, no config, free for 5 PRs/month:

github.com/apps/prdraft

Landing page: prdraft.carrd.co

Related: I stopped writing PR descriptions — here's what I did instead

Building in public from Kerala, India. Following along on Indie Hackers → search PRDraft.

I stopped writing PR descriptions. Here's what I did instead.

Twisted-Code'r — Thu, 02 Apr 2026 15:58:14 +0000

I opened 6 PRs last week.
I wrote a good description for exactly one of them.

The rest looked like this:

"fix bug"
"update styles"
"wip"
"changes" (my personal low point)

And I'm not even ashamed — I've seen senior engineers with
10 years of experience do the same thing.

Here's why it happens:

You just finished 3 hours of deep work. You know exactly what
you changed and why. Writing it down feels like explaining a
joke — the effort of articulating it kills the momentum. So
you type something vague and hit submit.

The reviewer then has to reverse-engineer your intent from
the diff. They leave a comment asking what you changed.
You explain it in the comment. Everyone wastes 20 minutes
doing what the PR description should have done in the first place.

So I started building a GitHub App to fix this for myself.

It hooks into GitHub, reads the diff when you open a PR,
and writes the description for you. Structured — what changed,
why, how to test it, what to watch for. Takes about 4 seconds.

I'm still building it. Calling it PRDraft.

Honest question for this community: is this a real pain
for you, or have you just accepted it as part of the job?

If you want it : https://prdraft.carrd.co

I built an open-source tool that stops personal data from leaking into AI chatbots

Twisted-Code'r — Sun, 29 Mar 2026 05:40:46 +0000

Ever copy-pasted something into ChatGPT and immediately
thought "wait, should I have done that?"

If you're building an AI app that handles user data, you need to know what's leaking into your LLM API before a regulator does.

That's the problem ShadowAudit solves.

It sits between your app and any LLM API and scans every
prompt before it leaves your system — catching emails,
phone numbers, API keys, and Indian national IDs like
Aadhaar and PAN numbers.

Two lines to integrate:

sa = ShadowAudit.from_config("shadowaudit.yaml")
client = sa.wrap(openai.OpenAI())

That's it. Everything else stays the same.

It also generates GDPR Article 30 compliance reports
automatically from your audit log — one command, done.

Built this over summer as part of my open-source portfolio.
Would love feedback from the community.

GitHub: github.com/Jeffrin-dev/ShadowAudit

CloudDev v0.3.0 — I built a free LocalStack alternative in Go with 17 AWS services published: true

Twisted-Code'r — Tue, 24 Mar 2026 09:47:56 +0000

If you've ever used LocalStack and balked at the $35/month price tag for the pro version, CloudDev might be exactly what you're looking for.

CloudDev is a free, open-source local AWS emulator built in Go — a single binary, zero runtime dependencies, works with your existing AWS CLI and SDKs out of the box.

Today I'm releasing v0.3.0, which adds 8 new AWS services and brings the total to 17 emulated services.

👉 github.com/Jeffrin-dev/CloudDev

Why I Built This

The "vendor kills free tier, community builds alternative" pattern keeps playing out everywhere. LocalStack's free tier is increasingly limited, and most developers just need basic local emulation for dev and CI — not a $35/month SaaS subscription.

The goal was simple: a tool that:

Works with zero config changes to your existing AWS CLI setup
Ships as a single Go binary with no runtime dependencies
Covers the AWS services that 90% of applications actually use
Is completely free and open source

What's in v0.3.0

🔐 Auth & Security

IAM (port 4593) — users, roles, policies, AssumeRole
STS (port 4592) — GetCallerIdentity, AssumeRole, GetSessionToken
KMS (port 4599) — CreateKey, Encrypt, Decrypt, GenerateDataKey

🏗️ Orchestration

CloudFormation (port 4581) — CreateStack, UpdateStack, parses YAML/JSON templates
Step Functions (port 4585) — state machines, executions, RUNNING → SUCCEEDED transitions

🌉 Events & Cache

EventBridge (port 4587) — event buses, rules, PutEvents with Lambda/SQS routing
ElastiCache (ports 4597/4598) — Redis-compatible TCP server + HTTP management API
Cognito (port 4596) — user pools, users, InitiateAuth with mock tokens

Quick Start

git clone https://github.com/Jeffrin-dev/CloudDev.git
cd CloudDev
go build -o clouddev .

./clouddev init my-app
cd my-app
../clouddev up

That's it. All 17 services start immediately.

Works With Your Existing AWS CLI

No special tooling needed. Just point --endpoint-url at CloudDev:

# KMS — create a key and encrypt/decrypt
aws --endpoint-url=http://localhost:4599 kms create-key \
    --description "my-key" --region us-east-1

aws --endpoint-url=http://localhost:4599 kms encrypt \
    --key-id key-1 --plaintext "hello-world" --region us-east-1

# Cognito — create a user pool and authenticate
aws --endpoint-url=http://localhost:4596 cognito-idp create-user-pool \
    --pool-name my-pool --region us-east-1

aws --endpoint-url=http://localhost:4596 cognito-idp initiate-auth \
    --auth-flow USER_PASSWORD_AUTH \
    --auth-parameters USERNAME=user,PASSWORD=pass \
    --client-id client-1 --region us-east-1

# Step Functions — create and run a state machine
aws --endpoint-url=http://localhost:4585 stepfunctions create-state-machine \
    --name my-machine \
    --definition '{"StartAt":"Hello","States":{"Hello":{"Type":"Pass","End":true}}}' \
    --role-arn arn:aws:iam::000000000000:role/role \
    --region us-east-1

The Web Dashboard

Every service gets a real-time status indicator in the dashboard at localhost:4580. It auto-refreshes every 5 seconds so you can see at a glance what's running.

All 17 services show up with their port and a green/red status dot.

How It Was Built

This project was built with an unusual workflow: Claude as the instructor and Codex as the developer.

Claude designed the architecture, wrote the detailed implementation prompts for each module, debugged issues from test output, and caught protocol mismatches (like the AWS CLI sending AWSStepFunctions.* instead of AmazonStates.* as the X-Amz-Target prefix — something you only discover by sniffing the actual HTTP request).

Codex implemented each module from those prompts, one PR at a time.

It's been a genuinely interesting experiment in human-AI-AI collaboration. The hardest bugs were always the subtle protocol differences between what the AWS documentation says and what the AWS CLI actually sends.

Complete Service & Port Reference

Service	Port
S3	4566
DynamoDB	4569
Lambda	4574
SQS	4576
API Gateway	4572
SNS	4575
Secrets Manager	4584
CloudWatch Logs	4586
IAM	4593
STS	4592
KMS	4599
CloudFormation	4581
Step Functions	4585
EventBridge	4587
ElastiCache (Redis)	4598
ElastiCache (HTTP)	4597
Cognito	4596

What's Next

v0.4.0 will focus on:

CloudWatch Metrics
SQS FIFO queues
Lambda layers
X-Ray tracing

Get Involved

The project is Apache 2.0 licensed and contributions are very welcome. Check out CONTRIBUTING.md to get started.

If CloudDev saves you time or money, a ⭐ on GitHub goes a long way — it helps other developers find the project.

👉 github.com/Jeffrin-dev/CloudDev