DEV Community: BV Nagi Reddy

Giving Kubernetes Dashboard a Graph Brain: How We Integrated FalkorDB for Autonomous SRE

BV Nagi Reddy — Sun, 18 Oct 2026 15:56:19 +0000

The 2:00 AM Kubernetes Outage

Every engineer who has managed a production Kubernetes cluster knows this scenario:

An alert fires. Pods are crash-looping or throwing 504 Gateway Timeout errors. You open the Kubernetes Dashboard and start frantically jumping between tabs:

Tab 1: Pods (they are crash-looping with exit code 137).
Tab 2: Services (which service selects these pods?).
Tab 3: Ingresses (did the routing rule or port change?).
Tab 4: ConfigMaps & Secrets (did a credential update break the database connection?).
Tab 5: RBAC (does the pod's service account have permission to talk to the API?).

In a modern microservices cluster running hundreds of pods, resources do not fail in isolation. A failure in Pod A is almost always caused by an upstream service, an expired secret, or an invalid selector three hops away.

Yet traditional dashboards present the cluster as a set of disconnected inventory tables.

Even worse, when engineers paste error logs into generic AI assistants like ChatGPT, the AI hallucinates. It doesn't have a map of your cluster. It blindly tells you to "restart the pod" or "increase replica memory"—completely unaware that restarting will cause cascading timeouts across three upstream microservices.

Kubernetes is fundamentally a graph.

To solve cluster troubleshooting, we decided to give the Kubernetes Dashboard an active relational nervous system. Here is the engineering story of Pilot Kubernetes, built for the Graph Hacks hackathon (Agents That Act on Connected Data track).

The Big Picture: From Flat Tables to a Live Knowledge Graph

Instead of building a toy standalone CLI, we forked the Go + Angular Kubernetes Dashboard repository and embedded FalkorDB directly into the cluster.

Live K8s State (API Server) ──┐
                              ├──► FalkorDB Graph (6379/TCP) ◄──► Autonomous AI SRE Agent
Live Telemetry (Logs/Metrics) ─┘     (In-Memory Cypher Engine)         (Multi-Hop Graph Tools)

FalkorDB continuously maintains a property graph of the cluster. When an issue occurs, our Autonomous SRE Agent doesn't read a flat dump. It executes openCypher graph queries as internal tools to discover:

Upstream Root Causes: Traversing 1 to 4 hops upstream to see what prerequisite failed.
Downstream Blast Radius: Finding every microservice and dependent workload that will break before taking any action.
Traceable Fixes: Delivering explainable root causes with exact Cypher verification queries and 1-click YAML patches.

Key Architectural Decisions

1. Why Fork the Official Kubernetes Dashboard?

We could have started an empty repo from scratch with a toy Python script. But production operators do not want another throwaway CLI.

By building inside the official Kubernetes Dashboard codebase:

We inherited battle-tested client-go authentication, token handling, and multi-namespace security.
We preserved the clean Angular Material interface enterprise teams are already familiar with.
We proved that graph intelligence can be seamlessly retrofitted into existing, mature cloud-native tools.

2. Why FalkorDB Over Traditional Graph Databases?

Kubernetes state is ephemeral and high-velocity. Pods scale up, fail, and restart in seconds. Heavy, Java-based graph databases introduce massive memory footprints and slow startup times that make in-cluster deployment impractical.

FalkorDB was the clear choice:

Redis Protocol Speed: Built on Redis in C, it delivers sub-millisecond Cypher query execution.
In-Memory Efficiency: A single lightweight container (falkordb/falkordb:v4.4.0) runs comfortably with minimal CPU and memory requests (100m CPU / 200Mi RAM).
openCypher Expressiveness: Cypher makes writing complex, variable-length path traversals (<-[*1..4]-) intuitive and readable.

3. Tool Selection Over Blind Prompting

Instead of stuffing thousands of lines of raw logs into an LLM context window (which leads to token limits and hallucinations), our agent uses a Tool-Augmented Graph RAG pattern implemented in modules/api/pkg/ai/agent.go:

falkordb_explore(resource): Grabs immediate 1-hop topology neighbors.
falkordb_blast_radius(resource, maxHops=4): Discovers upstream dependencies and downstream dependents.
falkordb_diagnose_service(service): Traces (:Service)-[:SELECTS]->(:Pod)-[:EMITTED]->(:LogEvent).
falkordb_attack_paths(namespace): Uncovers transitive RBAC privilege escalation chains.

4. Zero-Hassle Helm Packaging

Rule 10 of Graph Hacks requires easy local or live deployment. We packaged FalkorDB's Deployment, PVC, and Service directly into the official Helm chart templates (charts/kubernetes-dashboard/templates/falkordb/).
One helm upgrade --install command deploys the Web UI, API, and FalkorDB together with zero external database configuration.

How It Works Under the Hood

1. The Continuous Topology Syncer (`pkg/graph/syncer.go`)

A dedicated background goroutine runs inside the Go API pod. Every 60 seconds, it fetches cluster state via k8s.io/client-go and runs atomic Cypher MERGE queries:

MERGE (n:Pod {name: $name, namespace: $namespace})
SET n.status = $status, n.ip = $ip, n.nodeName = $nodeName

It maps relationships across all architectural tiers:

(:Service)-[:SELECTS]->(:Pod)
(:Ingress)-[:ROUTES_TO]->(:Service)
(:Deployment)-[:MANAGES]->(:Pod)
(:Pod)-[:RUNS_ON]->(:Node)
(:Pod)-[:MOUNTS_CONFIG]->(:ConfigMap)
(:Pod)-[:USES_ACCOUNT]->(:ServiceAccount)
(:ServiceAccount)-[:BOUND_BY]->(:RoleBinding)-[:GRANTS]->(:Role)

2. Live Telemetry & Log Ingestion (`pkg/graph/telemetry.go`)

A secondary syncer ingests live CPU usage rate (cpuMilli) and memory consumption (memoryMi) directly onto Node and Pod nodes.

Simultaneously, it tails pod logs, filters warning and error lines, and creates rolling LogEvent nodes:

(:Pod {name: "api-7d4db"}) -[:EMITTED]-> (:LogEvent {level: "ERROR", message: "dial tcp: connection refused"})

Old log events are automatically culled after 30 minutes, keeping FalkorDB fast and bounded.

Production Cypher Queries in Action

1. Multi-Hop Blast Radius Calculation

When an operator investigates a degraded service, FalkorDB calculates both upstream causes and downstream impact in a single traversal:

// Downstream Blast Radius: What workloads will break? (1 to 4 hops)
MATCH (n:Service {name: $name, namespace: $namespace})<-[*1..4]-(dependent)
RETURN DISTINCT dependent.name, dependent.namespace, labels(dependent), dependent.status;

// Upstream Dependencies: What prerequisites does this service need?
MATCH (n:Service {name: $name, namespace: $namespace})-[*1..4]->(dependency)
RETURN DISTINCT dependency.name, dependency.namespace, labels(dependency), dependency.status;

2. Uncovering Transitive RBAC Attack Paths

Kubernetes RBAC is notoriously difficult to audit. A pod's ServiceAccount might appear unprivileged, but it can inherit cluster-admin permissions through nested RoleBindings:

MATCH (sa:ServiceAccount {namespace: $namespace})-[:BOUND_BY]->(b)-[:GRANTS]->(r)
WHERE (r:Role OR r:ClusterRole) AND r.sensitive = 'true'
RETURN sa.name AS serviceAccount, 
       b.name AS binding, 
       r.name AS role, 
       labels(r)[0] AS roleKind;

⏱️ The 2:00 AM Bug: Feature-by-Feature, How We Solve It in Under 2 Minutes

Let's walk through an actual incident scenario:

The Alert: @service/checkout-api is throwing 504 Gateway Timeout errors and child pods are in CrashLoopBackOff.

Here is how each feature in Pilot Kubernetes turns a 45-minute nightmare into a 2-minute fix:

Minute 0:00 – Feature 1: Interactive 5-Tier Topology Canvas (`/ai/traffic`)

Traditional Way: You log into the dashboard, open the Pods tab, see 200 pods, search for "checkout", click on it, check events, go to Services tab, check endpoints... 15 minutes wasted.
With Pilot Kubernetes: You open the Topology Canvas. The cluster is automatically organized into 5 clear tiers: Ingress ➔ Service ➔ Workloads ➔ Pods ➔ Config/Storage. In 1 click, you isolate the checkout-api stack. You immediately see the red degraded indicator on the pod and notice its bezier connection to the database pg-cluster is glowing red.

Minute 0:30 – Feature 2: Multi-Hop Blast Radius Engine (`pkg/graph/result.go`)

Traditional Way: In panic mode at 2 AM, engineers are tempted to immediately restart pods or roll back deployments. Doing this blindly often takes down other downstream services.
With Pilot Kubernetes: You click Blast Radius on checkout-api. FalkorDB runs a 1-to-4 hop Cypher traversal:

  MATCH (n:Service {name: 'checkout-api'})<-[*1..4]-(dependent) RETURN dependent;

In 3 milliseconds, FalkorDB warns you: 3 dependent microservices (payment-gateway, order-processor, and mobile-api) depend directly on this service. You now know exactly what is at risk and avoid making blind changes that cause cascading outages.

Minute 1:00 – Feature 3: Live Telemetry Graph & Log Correlation (`pkg/graph/telemetry.go`)

Traditional Way: You run 5 terminal tabs with kubectl logs -n prod checkout-api-7d8f -f --tail=500 trying to parse thousands of lines of noisy JSON logs.
With Pilot Kubernetes: The telemetry syncer has already filtered out the noise and created rolling LogEvent nodes in FalkorDB linked directly to the pod:

  (:Pod {name: "checkout-api-7d8f"}) -[:EMITTED]-> (:LogEvent {level: "ERROR", message: "FATAL: password authentication failed for user 'app'"})

The graph correlates CPU/memory spikes with the exact database authentication error timestamp.

Minute 1:30 – Feature 4: Autonomous AI SRE Agent (`pkg/ai/agent.go`)

Traditional Way: You ask ChatGPT: "Why is my pod crashing with code 137?" ChatGPT gives a generic 500-word essay suggesting memory leaks, JVM flags, or node pressure.
With Pilot Kubernetes: In the AI Diagnostics Studio, you type: @service/checkout-api is failing. What is the root cause and blast radius?

The agent doesn't guess. It autonomously executes FalkorDB tools:

falkordb_explore(@service/checkout-api)
falkordb_diagnose_service(@service/checkout-api)
falkordb_blast_radius(@service/checkout-api)

The agent reveals the real truth:

"The pod is crash-looping because an automated Secret rotation 10 minutes ago updated the Secret db-credentials, but the checkout-api Deployment template was still pointing to the legacy Secret key POSTGRES_PASSWORD_V1. The pod cannot authenticate with PostgreSQL and exits upon boot."

Minute 2:00 – Feature 5: 1-Click YAML Remediation Patch

The Fix: The agent doesn't just explain the bug; it provides:
1. The exact Cypher query to verify the relationship in FalkorDB.
2. The exact kubectl command to inspect the Secret.
3. A ready-to-apply YAML patch updating the deployment secret key reference.

You apply the patch. The new pod boots, reconnects to PostgreSQL, and the FalkorDB topology canvas turns green. Incident resolved in under 2 minutes.

Bonus – Feature 6: AI Security & RBAC Attack Path Analyzer (`/ai/security`)

If the 2 AM failure is a 403 Forbidden authorization failure, FalkorDB traces the RBAC path:

  MATCH (sa:ServiceAccount {name: 'checkout-sa'})-[:BOUND_BY]->(b)-[:GRANTS]->(r)
  RETURN r.rules;

It immediately spots missing verbs on required resources and generates a hardened, least-privilege Role manifest on the spot.

The "Rule 3" Test: Why FalkorDB is Essential

Hackathon Rule 3 states:

"The graph has to do real work. If the product still works once FalkorDB is taken out, the graph is decoration rather than the thing the product runs on."

In Pilot Kubernetes, if you take FalkorDB down:

Blast Radius Calculations Halt: The API has no graph traversal engine to calculate dependency paths.
The AI SRE Agent Loses Its Vision: Tool execution fails. The agent cannot inspect graph neighborhoods and cannot ground its diagnoses.
RBAC Attack Path Finding Stops: Multi-hop permission chains cannot be evaluated with flat API calls.
Telemetry Correlation Breaks: Ingress-to-Service-to-Pod-to-LogEvent correlation fails.

FalkorDB is not a visualization cache; it is the reasoning engine the product runs on.

Quickstart: How to Run It in 60 Seconds

You can deploy the entire stack—including the Web UI, API, and in-cluster FalkorDB—with a single Helm command:

1. Deploy via Helm

# Clone the repository
git clone https://github.com/Niteesh57/Pilot-Kubernetes.git
cd Pilot-Kubernetes

# Deploy Pilot Kubernetes with embedded FalkorDB
helm upgrade --install pilot-dashboard ./charts/kubernetes-dashboard \
  --namespace kubernetes-dashboard \
  --create-namespace \
  --set falkordb.enabled=true \
  --set falkordb.persistence.enabled=true

2. Access the Dashboard

Forward local traffic to the web container:

kubectl port-forward -n kubernetes-dashboard \
  svc/pilot-dashboard-kubernetes-dashboard-web 8080:8000

Open http://localhost:8080 in your browser.

3. Verify FalkorDB Connectivity

Test that FalkorDB is actively synchronizing cluster topology:

curl -s http://localhost:8080/api/v1/graph/status
# Returns: {"connected":true,"graphName":"kubepilot","nodeCount":142,"edgeCount":318}

Conclusion

Agents are only as good as the context they work with.

By giving our SRE agent FalkorDB's connected graph, decisions become explainable, verifiable, and free of hallucinations. An operator can see the exact graph path that led to a diagnosis, inspect the blast radius before applying a fix, and execute remediation with confidence.

GitHub Repository: https://github.com/Niteesh57/Pilot-Kubernetes
Live Documentation: https://niteesh57.github.io/Pilot-Kubernetes/
Hackathon Track: Agents That Act on Connected Data
License: Apache 2.0

Have questions about our graph schema or Go syncer? Check out the repo or drop a comment below!

TigerDB: The Desktop Memory Agent That Never Lets Your Friend Forget Where They Left Off

BV Nagi Reddy — Mon, 05 Oct 2026 04:19:17 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built this for my friend — a freelance developer who routinely puts in 10-to-12-hour days across multiple machines, three monitors, and a chaos of browser tabs, Docker containers, and half-finished code sessions. His single biggest frustration is what he calls "the Monday morning blank screen": he sits down, opens his laptop, and has absolutely no idea what he was doing when he stopped. He loses 30-to-45 minutes every single morning just reconstructing context — what file was he editing, what Docker error was he chasing, what did he promise to send to a client before he closed the laptop.

TigerDB is a unified desktop memory intelligence system that watches his work sessions, stores every meaningful activity into a three-layer database, and hands him a concise morning briefing the moment he opens his machine.

The three layers are:

Vector Engine (pgvector + HNSW index): encodes every file edit, terminal command, and browser visit as a 384-dimensional embedding for natural-language search
Property Graph Engine (tiger_graph): models each work session as a directed acyclic graph — activity nodes connected by typed edges (ACCESSED_RESOURCE, COMMITTED_TO) — so you can trace exactly what led to what
TimescaleDB Hypertable: a time-partitioned telemetry log that tracks which workflows succeeded, which failed, and the GRPO reward signals that teach the agent to get smarter session over session

When my friend opens his laptop in the morning, a single click surfaces three tiles: yesterday's unfinished threads with their progress percentage, any blockers or failed deployments that need Reflect-Replan, and today's auto-generated agenda. He can also speak a natural query — "where did I put that Kafka config?" — and the agent retrieves the exact file path, code snippet, and the promise he made about it, ranked by a hybrid scoring formula that weights semantic similarity, past success rate, and recency.

Demo

Live Site: TigerDB: The Desktop Memory Agent

The demo shows:

TigerDB's memory architecture
Property Graph execution trajectories
Live desktop activity insertion
Vector memory retrieval
Equation 4 memory ranking
Positive and Negative Paradigms
TimescaleDB telemetry
Voice-based memory retrieval

Running Locally

docker compose up
npm run dev
uvicorn tiger_agent.api:app --host 0.0.0.0 --port 8000

The application runs locally with PostgreSQL, pgvector, TimescaleDB, React, and FastAPI.

Code

Niteesh57 / tigerdb

TigerDB: Unified Graph & Vector Database for Memory Intelligence Agent (MIA)

An enterprise-grade implementation of the Memory Intelligence Agent (MIA) lifelong learning framework (arXiv:2604.04503v4), powered by TigerDB — a unified multi-model engine combining PostgreSQL 18, TimescaleDB HA, pgvector, and a native Property Graph Model.

Includes a full-stack Desktop Memory Agent Web HUD with real-time Graph DAG visualization, speech-enabled AI assistant, morning briefings, in-situ WebMCP auto-healing, and a zero-downtime deployment container for Render.com.

📑 Table of Contents

View on GitHub

Key files:

tiger_agent/desktop_memory.py — core activity recorder: creates graph nodes + vector embeddings in a single transaction
tiger_agent/morning_assistant.py — morning briefing engine: unfinished threads, blockers, today's agenda
tiger_agent/llm_client.py — NVIDIA NIM gateway with structured JSON output and local fallback
tiger_mia/ — Memory Intelligence Agent core: Manager, Planner, Executor, Judger

How I Built It

The architecture implements the Memory Intelligence Agent (MIA) framework (arXiv:2604.04503) on top of PostgreSQL 18. Every component is open-source:

Inference layer — NVIDIA NIM (open-weight models via NIM API):
The agent uses meta/llama-3.3-70b-instruct served through NVIDIA NIM — an open-weight model that can be self-hosted on any NVIDIA GPU. The LLM client (llm_client.py) uses langchain_openai pointed at the NIM endpoint and requests structured JSON output via Pydantic schemas, so the response is always parseable into { format, speakingtext, content } without hallucinated formatting.

Embedding layer — sentence-transformers (local inference):
Every desktop activity is encoded into a 384-dimensional vector using all-MiniLM-L6-v2, running fully locally via the sentence-transformers library. No activity text ever leaves the machine at embedding time.

Memory layer — TigerDB (PostgreSQL 18 + pgvector + TimescaleDB):

pgvector 0.8.6 provides HNSW indexing (vector_cosine_ops) for sub-millisecond cosine similarity search
A custom tiger_graph schema stores execution DAGs in plain PostgreSQL tables, traversed with recursive CTEs
TimescaleDB hypertable partitions the trajectory log into 7-day chunks with 90% columnar compression

Agent runtime — four-role architecture:

Role	Responsibility
Memory Manager	Hybrid retrieval (Eq. 4), knowledge replacement at threshold θ=0.92, workflow compression
Planner	Few-shot in-context learning with Positive & Negative Paradigms, Reflect-Replan
Executor	ReAct loop tool interactions, logging execution graphs into TigerDB
Judger	Evaluates correctness, computes multi-signal GRPO rewards (r₁ correctness, r₂ tool efficiency, r₃ format)

The hybrid scoring formula (Equation 4 from the MIA paper) ranks retrieved memories by:

Score (m_{i}) = 0.50 \cdot Sim^_{i} + 0.35 \cdot \frac{s _{i}}{u _{i} + 1} + 0.15 \cdot \frac{1}{u _{i} + 1}

This means a memory that was correct and short rises above memories that were merely semantically close — the agent genuinely learns which workflows worked.

🐯 Tiger Data: Best Use of Tiger Data

TigerDB was designed from the ground up around exactly the three patterns the Tiger Data prize calls out: store embeddings with pgvector, run hybrid keyword and vector search for an agent, and let an agent manage a database. Here is precisely how each one works.

1. Storing Embeddings with pgvector

Every desktop activity — a file edit, a terminal command, a browser tab, a promise made to a client — is encoded into a 384-dimensional vector using sentence-transformers/all-MiniLM-L6-v2 and persisted into tiger_mia.memory_units via pgvector:

# tiger_agent/desktop_memory.py — record_activity()
q_embed = self.embedder.encode(
    f"{title} {activity_type} {path_or_url} {snippet} {promise_text or ''}"
)
insert_sql = """
    INSERT INTO tiger_mia.memory_units (
        modality, category, question, caption,
        question_embedding,          -- vector(384)
        trajectory_graph_id,
        compressed_workflow, judgment_label,
        execution_length, usage_count, success_count
    ) VALUES (
        'desktop_activity', %s, %s, %s,
        %s::vector, %s,
        %s::jsonb, %s,
        1, 1, 1
    ) RETURNING id;
"""

The HNSW index (vector_cosine_ops) makes every lookup sub-millisecond even as memories accumulate across months of work sessions.

2. Hybrid Keyword + Vector Search for an Agent

The search_timeline method — called every time the agent answers a voice query — runs a true hybrid scoring formula directly in SQL, combining pgvector cosine similarity with PostgreSQL full-text similarity() in a single query:

-- tiger_agent/desktop_memory.py — search_timeline()
SELECT
    id,
    question AS title,
    caption AS snippet,
    category AS activity_type,
    compressed_workflow,
    trajectory_graph_id,
    -- Hybrid score: 70% keyword (pg_trgm similarity) + 30% vector (pgvector cosine)
    (0.7 * GREATEST(similarity(question, %s), similarity(COALESCE(caption, ''), %s))
     + 0.3 * (1 - (question_embedding <=> %s::vector))) AS composite_score,
    (1 - (question_embedding <=> %s::vector)) AS similarity
FROM tiger_mia.memory_units
WHERE modality = 'desktop_activity'
ORDER BY composite_score DESC
LIMIT %s;

When the Planner retrieves memories for in-context learning, it uses Equation 4 from the MIA paper — a three-signal scoring formula that weighs semantic similarity, historical success rate, and access frequency together:

Score (m_{i}) = 0.50 \cdot Sim^_{i} + 0.35 \cdot \frac{s _{i}}{u _{i} + 1} + 0.15 \cdot \frac{1}{u _{i} + 1}

This means the agent doesn't just retrieve what's similar — it retrieves what worked, actively separating Positive Paradigms (correct past workflows) from Negative Paradigms (failed patterns to avoid).

3. Agent Managing the Database Through WebMCP

TigerDB includes a WebMCP Action Engine — a direct agent-to-database execution layer that lets the agent manage system state without the user copy-pasting commands. When the morning briefing surfaces a failed Docker deployment (stored as a Negative Paradigm in TigerDB), the agent calls docker_heal directly:

# tiger_agent/webmcp_actions.py
class WebMCPActionEngine:
    def execute(self, action_type: str, params: Dict[str, Any]) -> Dict[str, Any]:
        """Dispatches action to the appropriate handler."""
        handler_map = {
            "docker_heal":    self.heal_docker_container,  # auto-restarts containers
            "docker_status": self.get_docker_status,       # live container table
            "open_file":     self.open_local_file,         # reveals file in explorer
            "draft_email":   self.create_draft_email,      # creates draft from promise
            "resume_session": self.resume_session          # restores work contexts
        }

And on the database side, the agent writes every action outcome — whether the Docker heal succeeded or failed — back into tiger_mia.memory_units as a new judgment-labeled memory, and logs the reward signals to the TimescaleDB hypertable:

-- TimescaleDB Hypertable: agent self-updates its own memory after each action
INSERT INTO tiger_mia.trajectory_logs
    (time, question, total_steps, correctness_reward, tool_reward, format_reward,
     total_reward, advantage, metadata)
VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s::jsonb);

The result is a closed loop: the agent reads from TigerDB, acts on the world, and writes the outcome back to TigerDB — with no human in the middle.

Why Does Open Innovation Matter?

My friend's computer is his livelihood. Every file path, every client name in a browser tab, every half-written email draft is private business data. The core insight of this project is that desktop memory is the most personal data a person generates, and it should never leave their machine by default.

With closed AI APIs, continuous desktop activity monitoring would require streaming every file name, every snippet of code, every URL visited to a third-party server for embedding and inference. That is a non-starter for a freelancer with NDAs and client confidentiality obligations.

Open-source AI made three things possible that a closed API never could:

Local embedding inference. sentence-transformers with all-MiniLM-L6-v2 runs entirely on the CPU. Every activity is vectorized locally. The data never moves off the machine.
Self-hostable LLM. NVIDIA NIM serves open-weight models like Llama 3.3 70B. My friend can run this on his own NVIDIA GPU at home. The morning briefing LLM call — the part that reads his unfinished tasks and failed deployments — stays on his own hardware.
Inspectable, modifiable memory. Because TigerDB is built on PostgreSQL with documented schemas, my friend can open psql, see exactly what the agent remembers about him, delete rows he doesn't want, and modify the scoring weights. A closed memory API gives you none of that transparency or control.

Open innovation didn't just make TigerDB cheaper — it made it ethically possible to build a tool that watches someone's work all day.

My Agent Session

Prize Categories

🐯 Tiger Data — Best Use of Tiger Data: pgvector HNSW embeddings for all desktop activities + hybrid keyword/vector SQL search + WebMCP agent that reads, acts, and writes outcomes back to TigerDB autonomously
🟢 NVIDIA: Uses NVIDIA NIM API with open-weight Llama 3.3 70B for structured LLM responses
🐘 TimescaleDB / PostgreSQL: Core storage layer — pgvector HNSW + TimescaleDB hypertable + recursive CTE property graph, all on PostgreSQL 18
🦜 LangChain: langchain_openai used as the LLM client interface to NVIDIA NIM

Built during Hacktoberfest Weekend 2026.

Kindy: A friendly voice companion that helps you find ways to give back

BV Nagi Reddy — Mon, 07 Sep 2026 01:50:37 +0000

This is a submission for Weekend Challenge: Generosity Edition

What I Built

Whenever I look at charity websites, almost all of them immediately ask for money. But what if you're a student or just tight on cash right now?

It often makes people feel guilty or like they have nothing to offer.
The truth is, generosity isn't just about writing a check. You can give your time, your skills, your advice, or just a listening ear.

For this challenge, I built Kindy — an interactive 2D animated avatar you can actually talk to.

Instead of filling out a boring form, you have a quick voice chat with Kindy. You tell it what you like doing, what skills you have, or how much free time you have this weekend. Kindy then:

Reacts with funny, exaggerated emotions (crying when you say you're tired, hyping you up when you doubt yourself, and celebrating your ideas).
Gives you 6 simple, realistic ways you can make an impact.
Uses Google Maps to look up real community centers, food banks, and volunteer spots near your city.

Demo

Live Demo: Kindy Avatar Studio

Note: The application is deployed on Google Cloud Run. Since Cloud Run may scale down when there is no activity, the first request can take a few seconds to start the application. Please wait a few seconds if the page takes time to load.

Once the application opens, you can enter any random/demo data you like. This entered information is stored only in your browser.

The avatar supports direct speech interaction. Simply open the URL and start speaking—you don't need to configure or think about anything else.

Code

You can find the full code on GitHub:

Niteesh57 / Kindy

Understand how you're feeling and what you have to offer, then help you find a meaningful way to help someone else.

Kindy — The Generosity Companion 🎨✨

Kindy is a real-time, voice-driven AI companion and avatar studio. Powered by Google Gemini 3.8 Flash and Gemini 3.1 Flash TTS, it brings a stylized 2D cartoon avatar to life through audio-driven lip sync, multi-emotion acting, spatial hand gestures, Google Search & Maps grounding, and a 6-card interactive action HUD.

🌟 Live Deployment & Demo Video

🌐 Live Web Application: https://kindy-avatar-studio-619077244859.us-central1.run.app
🎬 Video Walkthrough (YouTube): Watch the Demo Video

💡 Core Purpose & Persona

The Generosity Companion & Comic Well-Wisher

Kindy operates on a simple philosophy:

"Everyone has something meaningful to give." Whether it is 20 minutes of spare time, professional skills, tutoring, attention, physical presence, surplus items, or mentorship.

The High-Drama Comic Well-Wisher

Kindy is not a monotone chatbot. It embodies a passionate comic well-wisher and benchmark mentor:

Benchmark Face ([serious, hands_up]): When users doubt themselves…

View on GitHub

Tech stack:

Frontend: React, Vite, and custom SVG animations for avatar expressions.
Voice & Audio: Web Audio API and browser's SpeechRecognition for automatic voice detection (so you can just talk naturally).
Backend: Node.js + Express with WebSockets for real-time streaming.
AI: Google GenAI SDK with Gemini 3.8 Flash and Gemini 3.1 TTS.
Deployment: Multi-stage Dockerfile ready for Cloud Run.

How I Built It

I wanted Kindy to feel like a real conversation with an encouraging friend, not a dry chatbot:

The Avatar & Expressions: I built a custom face overlay in React with different SVG states (crying eyes, sweat drops, anime-style anger veins, star eyes, and waving hands). The backend sends emotion tags like [crying] or [excited] alongside the text, and the frontend switches expressions as words are spoken.
Real-Time Voice & WebSockets: Instead of clicking buttons for every turn, I used browser's built-in SpeechRecognition to detect when you start and stop talking. Your voice goes through a WebSocket to the Node server, which streams both text and audio back simultaneously so there is very little lag.
Grounding in the Real World: General advice like "go volunteer" isn't very helpful. By connecting Google Search and Google Maps tools to Gemini, Kindy can check where you live and suggest actual local libraries, youth mentoring groups, or neighborhood kitchens.
Simple Docker Setup: I wrapped the React build and the Node server together in one Docker container so anyone can run it locally with docker compose up or deploy it to Google Cloud Run in one command.

Prize Categories

Best Use of Google AI

Kindy relies on Google AI for its brain and voice:

Gemini 3.8 Flash: Handles the conversation, keeps track of the user's profile, and outputs real-time emotion cues.
Gemini 3.1 Flash TTS: Generates the expressive voice output so Kindy can speak out loud.
Google Search & Google Maps Tools: Powers the local search so Kindy recommends verified places and groups in your city.
Google GenAI SDK (@google/genai): Connects everything cleanly in Node.js.

Lessons Learned

Building this over the weekend showed me that giving back feels much more approachable when someone helps you break it down into small, doable steps. Even spending 20 minutes sharing advice with someone starting out in your field counts as generosity.

Thanks for checking out Kindy!

DEV Community: BV Nagi Reddy

Giving Kubernetes Dashboard a Graph Brain: How We Integrated FalkorDB for Autonomous SRE

The 2:00 AM Kubernetes Outage

The Big Picture: From Flat Tables to a Live Knowledge Graph

Key Architectural Decisions

1. Why Fork the Official Kubernetes Dashboard?

2. Why FalkorDB Over Traditional Graph Databases?

3. Tool Selection Over Blind Prompting

4. Zero-Hassle Helm Packaging

How It Works Under the Hood

1. The Continuous Topology Syncer (pkg/graph/syncer.go)

2. Live Telemetry & Log Ingestion (pkg/graph/telemetry.go)

Production Cypher Queries in Action

1. Multi-Hop Blast Radius Calculation

2. Uncovering Transitive RBAC Attack Paths

⏱️ The 2:00 AM Bug: Feature-by-Feature, How We Solve It in Under 2 Minutes

Minute 0:00 – Feature 1: Interactive 5-Tier Topology Canvas (/ai/traffic)

Minute 0:30 – Feature 2: Multi-Hop Blast Radius Engine (pkg/graph/result.go)

Minute 1:00 – Feature 3: Live Telemetry Graph & Log Correlation (pkg/graph/telemetry.go)

Minute 1:30 – Feature 4: Autonomous AI SRE Agent (pkg/ai/agent.go)

Minute 2:00 – Feature 5: 1-Click YAML Remediation Patch

Bonus – Feature 6: AI Security & RBAC Attack Path Analyzer (/ai/security)

The "Rule 3" Test: Why FalkorDB is Essential

Quickstart: How to Run It in 60 Seconds

1. Deploy via Helm

2. Access the Dashboard

3. Verify FalkorDB Connectivity

Conclusion

TigerDB: The Desktop Memory Agent That Never Lets Your Friend Forget Where They Left Off

What I Built

Demo

Running Locally

Code

Niteesh57 / tigerdb

TigerDB: Unified Graph & Vector Database for Memory Intelligence Agent (MIA)

📑 Table of Contents

How I Built It

🐯 Tiger Data: Best Use of Tiger Data

1. Storing Embeddings with pgvector

2. Hybrid Keyword + Vector Search for an Agent

3. Agent Managing the Database Through WebMCP

Why Does Open Innovation Matter?

My Agent Session

Prize Categories

Kindy: A friendly voice companion that helps you find ways to give back

What I Built

Demo

Code

Niteesh57 / Kindy

Understand how you're feeling and what you have to offer, then help you find a meaningful way to help someone else.

Kindy — The Generosity Companion 🎨✨

🌟 Live Deployment & Demo Video

💡 Core Purpose & Persona

The Generosity Companion & Comic Well-Wisher

The High-Drama Comic Well-Wisher

How I Built It

Prize Categories

Best Use of Google AI

Lessons Learned

1. The Continuous Topology Syncer (`pkg/graph/syncer.go`)

2. Live Telemetry & Log Ingestion (`pkg/graph/telemetry.go`)

Minute 0:00 – Feature 1: Interactive 5-Tier Topology Canvas (`/ai/traffic`)

Minute 0:30 – Feature 2: Multi-Hop Blast Radius Engine (`pkg/graph/result.go`)

Minute 1:00 – Feature 3: Live Telemetry Graph & Log Correlation (`pkg/graph/telemetry.go`)

Minute 1:30 – Feature 4: Autonomous AI SRE Agent (`pkg/ai/agent.go`)

Bonus – Feature 6: AI Security & RBAC Attack Path Analyzer (`/ai/security`)