Shipped v0.1.0 of an open-source Terraform drift scanner — 0 stars, looking for first feedback
18, based in Kerala, India. Start college in about 9 months. Wanted to build something real before that — not a SaaS wrapper, something that solves an actual infra problem.
The problem: Terraform says your infrastructure looks one way. AWS console shows it looks another way, because someone made a manual change. Most teams find out during an incident, not before. Existing drift tools tell you it happened. None of them tell you why it matters or what to do about it.
What I built — SynchroIaC:
- GitHub Action scans your Terraform state against live AWS (EC2, S3, IAM for now)
- Risk-classifies every drift: low/medium/high/critical
- AI explains what changed and why it matters
- One-click fix PR generation
- Your AWS credentials never leave your own GitHub Actions runner
Built in 2 days using Codex/Jules as implementation, me as architect. Stack: Go scanner, Next.js API on Vercel, Supabase, Groq for AI explanations.
Where I'm at: v0.1.0 shipped, live dashboard, listed on GitHub Marketplace, 11/11 e2e tests passing. Zero stars. Zero users. Posted on Dev.to yesterday, no traction yet.
What I actually want from this post:
Not validation. I want someone who runs Terraform in production to tell me if this solves a real problem or if I built a solution looking for one. I can't answer that myself — I've never run infra at scale.
If you've dealt with drift before, I'd genuinely value 5 minutes of your time looking at this and telling me what's missing or what's wrong.
Repo: github.com/Jeffrin-dev/SynchroIaC
Dashboard: synchroiac-io.vercel.app
Happy to answer anything about the build, the architecture decisions, or why I made specific tradeoffs.
This is already in a real category of pain where “detecting drift” is solved, but “understanding blast radius and deciding what to do next” is still where teams slow down or make mistakes. The risk scoring + PR generation direction is interesting because it moves from visibility to action, which is usually where these tools actually become useful in production.
That's exactly the gap I was trying to close, glad it reads that way. Detection alone felt like it was solving the wrong problem — you already know something changed, the question is always "does this matter and what do I do."
Right now the risk classification is rule-based (attribute + resource type + before/after value), not learned. Curious if that's the right first step or if you think blast radius actually needs more context than a single-resource diff can give — like dependency graphs between resources, or knowing what's downstream of a change.
If you've seen tools attempt this well (or badly), I'd like to know what worked.
I think the bigger question isn't whether blast radius needs more context.
It's whether the product is trying to predict technical impact or justify operational decisions. Those sound similar, but they lead to very different products.
I've got a few thoughts on that which are easier to explain than squeeze into a thread. If you're interested, what's the best email to reach you on?
jeffrin4v@gmail.com
Thanks, Jeffrin.
I've just sent it over. Looking forward to hearing your thoughts whenever you have a chance.