3 ms·

Show HN: Khaga – AI Infrastructure Diagnosis for AWS, GCP, Azure and Kubernetes

I built this after getting frustrated with jumping between CloudWatch, kubectl, and 4 other tools every time something broke in prod. You point it at your AWS, GCP, Azure, or Kubernetes setup and it gives you a root cause analysis in plain English — severity, evidence, and fix commands. Also does Terraform plan review, Dockerfile analysis, CI/CD log parsing, and SOC2/ISO27001 compliance estimates. Free to try, no credit card. Would love harsh feedback from people who actually manage infrastructure.

matrixgard 7mo ago
The CloudWatch + kubectl + 4-other-tools triage loop is real — I've burned hours on that exact workflow at 2am during an incident. The pain isn't the tools themselves, it's that each one gives you a different slice of truth with no shared context, so you end up mentally joining logs across systems with no guarantee you're even looking at the right time window. The SOC2 compliance estimate piece is interesting. In practice that's notoriously hard to do from infrastructure signals alone — a lot of what auditors actually care about (access reviews, change management evidence, vendor risk questionnaires) lives outside the infra layer entirely. Curious how you're approaching that part — are you generating evidence artifacts or more of a gap-assessment output? Also, how are you handling credentials for multi-cloud — are you asking users to drop keys in or is there an OIDC/role-based flow?
- Gowrishankarhq 7mo ago
  You've nailed exactly the problem — the "mentally joining logs across systems with no shared context" is the core pain. Each tool gives you a slice but nobody gives you the full picture in one place. On SOC2 — you're right, I'm not generating audit evidence artifacts (yet). Right now it's a gap assessment — it scans infra signals like encryption at rest, public access configs, logging enabled/disabled, IAM policies, and maps them to SOC2 criteria. It's honest about what it can't assess — access reviews, change management, vendor questionnaires — and explicitly flags those as out of scope. The goal is to give a team a starting point, not replace an auditor. On credentials — currently key-based, encrypted at rest with Fernet. OIDC/role-based is on the roadmap. The honest tradeoff is that OIDC requires more setup on the user side which adds friction for early adoption — but for teams with real compliance requirements it's clearly the right answer. Planning to add AWS AssumeRole + GCP Workload Identity as the next auth layer. Would love your feedback on what a useful evidence artifact output would look like — you clearly know what auditors actually want to see.

matrixgard 7mo ago

The CloudWatch + kubectl + 4-other-tools triage loop is real — I've burned hours on that exact workflow at 2am during an incident. The pain isn't the tools themselves, it's that each one gives you a different slice of truth with no shared context, so you end up mentally joining logs across systems with no guarantee you're even looking at the right time window. The SOC2 compliance estimate piece is interesting. In practice that's notoriously hard to do from infrastructure signals alone — a lot of what auditors actually care about (access reviews, change management evidence, vendor risk questionnaires) lives outside the infra layer entirely. Curious how you're approaching that part — are you generating evidence artifacts or more of a gap-assessment output? Also, how are you handling credentials for multi-cloud — are you asking users to drop keys in or is there an OIDC/role-based flow?

Gowrishankarhq 7mo ago
You've nailed exactly the problem — the "mentally joining logs across systems with no shared context" is the core pain. Each tool gives you a slice but nobody gives you the full picture in one place. On SOC2 — you're right, I'm not generating audit evidence artifacts (yet). Right now it's a gap assessment — it scans infra signals like encryption at rest, public access configs, logging enabled/disabled, IAM policies, and maps them to SOC2 criteria. It's honest about what it can't assess — access reviews, change management, vendor questionnaires — and explicitly flags those as out of scope. The goal is to give a team a starting point, not replace an auditor. On credentials — currently key-based, encrypted at rest with Fernet. OIDC/role-based is on the roadmap. The honest tradeoff is that OIDC requires more setup on the user side which adds friction for early adoption — but for teams with real compliance requirements it's clearly the right answer. Planning to add AWS AssumeRole + GCP Workload Identity as the next auth layer. Would love your feedback on what a useful evidence artifact output would look like — you clearly know what auditors actually want to see.