DEV Community: MEHRAAN AMIN

How I Built Triage: Turning SigNoz into a Blue Team SOC (And the Deployment Nightmares I Survived)

MEHRAAN AMIN — Sat, 25 Jul 2026 18:18:22 +0000

Most people use OpenTelemetry and SigNoz to watch their CPU usage, find memory leaks, or figure out why their API is taking 400ms instead of 200ms. But for the Agents of SigNoz Hackathon (Track 3: Observe Anything Weird), I wanted to do something completely different.

I didn't want to watch hardware. I wanted to watch hackers.

That is how Triage was born. It is an OpenTelemetry-powered Blue Team SOC (Security Operations Center) that tracks active cyber attacks instead of just generic application performance.

The Original Vision vs. The Reality

Building this sounded straightforward on paper: catch bad traffic, wrap it in an OpenTelemetry span, send it to SigNoz, and show it on a custom dashboard. But actually deploying this beast before the deadline was a completely different story.

If you have ever tried to deploy a full-stack Next.js app, a Python honeypot, and an OTel pipeline while the clock is ticking, you know exactly what kind of panic I am talking about. Here is what actually happened behind the scenes.

1. The Azure VM & Docker Crash
I started by spinning up an Azure virtual machine to self-host the SigNoz backend. I pulled the repo, ran docker compose up -d, and immediately watched my server completely freeze. Turns out, my free tier Azure instance (Standard_B2ats_v2) only had 1 GiB of RAM. You simply cannot run a massive ClickHouse database and a full OTel collector on 1GB of memory without it crashing instantly. I had to pivot fast and rely on the cloud endpoints.

2. The Vercel vs Localhost Trap
Once I got the backend running, I hit my next wall. My Vercel Next.js dashboard kept throwing 500 Internal Server Error on the threat simulation API, and the SigNoz connection kept reading OFFLINE (fetch failed). I was staring at my logs losing my mind until it clicked. My Vercel environment variables had SIGNOZ_API_URL set to http://localhost:8080 and my Python script was looking for OTel on localhost:4318.

Note to self (and everyone else): Vercel is a cloud server. It has no idea what your local Kali Linux machine or Azure VM is doing on localhost. I had to either use Ngrok to tunnel my local endpoints to the public internet or point everything strictly to public cloud URLs so Vercel could actually talk to the backend.

3. The Supabase Keys Nightmare
To persist the threat logs for the dashboard, I was connecting to Supabase. But nothing was writing to the database and the UI was stuck on "UNCONFIGURED".

It turns out I had mistakenly treated my master database key like a public variable. In Next.js, if you prefix a secret key with NEXT_PUBLIC_, you expose it to the browser. But my API routes were strictly looking for the exact string SUPABASE_SERVICE_ROLE_KEY to securely insert data. A single prefix mismatch broke the entire flow. Once I stripped the prefix, passed the raw service key to the Vercel settings, and hit redeploy, the database finally connected and the traces started flowing.

The Features We Built

Despite the deployment chaos, the final system works beautifully. Here is what Triage actually does:

AI-Powered Threat Analysis (Groq & Llama-3.1)
When a normal APM sees a 403 error, it just logs a generic spike on a graph. When Triage intercepts an SQL injection or a leaked API key, it captures the raw payload and immediately sends it to Groq. The LLM generates a clean, 3-sentence summary of the attack vector, which we attach directly to the OpenTelemetry trace.

Python TCP Honeypot Trap
I didn't just want to watch web traffic. I wrote an asyncio Python script that acts as a honeypot listening on port 2222 (mocking SSH) and 63790 (mocking Redis). When automated bots or tools like Nmap run a port scan against my server, the honeypot catches the IP, generates a custom OTel trace, and ships it to the collector via OTLP HTTP on port 4318.

SRE Sidekick (Auto-Ban)
We built an active defense mechanism. If the system tracks 5 attacks from the same IP within 60 seconds, it triggers a self-healing protocol. It drops an sre.auto_ban.triggered span and instantly enforces a firewall block on that attacker.

Cyberpunk SOC Command Center
I built the entire frontend in Next.js 16. It pulls live telemetry traces, shows real-time threat stats, and features a "Red Team Simulator". Judges and users can safely simulate SQL injections or data leaks directly in the browser with one click to see the telemetry populate live.

How I Actually Used SigNoz

This is where it gets fun. I didn't use any of the standard HTTP auto-instrumentation for the security layer. I built custom OpenTelemetry spans tailored specifically for a Blue Team.

Instead of tracking standard routes, I mapped out an adversary's footprint. Here is exactly what I sent to the SigNoz collector:

Custom Spans: I created custom span names like security.trap when a web exploit was caught, and honeypot.port_scan for TCP probes.
Security Attributes: Inside these spans, I injected attributes like security.severity = 'CRITICAL', security.threat_type = 'SQL_INJECTION', and security.source_ip.
AI Metrics: For every payload analyzed by Groq, the trace included llm.latency, llm.model, and threat.goal.

By doing this, I could open the SigNoz Query Builder and run a simple query to see every critical SQL injection attempt across my entire infrastructure, mapped out in real-time.

Final Thoughts

This hackathon pushed me to my absolute limits. Between fighting cloud networking rules, debugging Next.js server crashes, and forcing OpenTelemetry to act like a SIEM, I learned more in a few days than I have in months.

SigNoz proved to be incredibly flexible. It isn't just for tracking uptime. If you structure your telemetry right, you can observe absolutely anything. Even the weird stuff.

Catching API Attacks in Real Time: A Penetration Tester's Guide to SigNoz

MEHRAAN AMIN — Fri, 17 Jul 2026 06:46:09 +0000

When I saw the Agents of SigNoz challenge, my timeline was immediately flooded with basic uptime monitors and standard e-commerce tracing setups. But what if we flip the script and use observability as a Blue Team security tool to catch attackers in real time?

Most developers use OpenTelemetry to figure out why a database query is slow or why an API endpoint is failing. As someone who spends time on penetration testing and building custom security tools on Kali Linux, I see server latency entirely differently. A sudden CPU spike is not always bad code; sometimes it is an active attacker attempting resource exhaustion or a Denial of Service.

I wanted to see if I could build a trap. My goal was to create a vulnerable Express.js API that actively detects SQL injection payloads, deliberately stalls the server CPU, and alerts me instantly through the SigNoz dashboard using OpenTelemetry traces and metrics. Here is exactly how I built it, the errors I hit during the local deployment, and how I caught the attack.

The Setup and The Foundry Curveball

My environment of choice is Kali Linux, and I decided to self-host SigNoz using Docker. Like many developers starting out, I went straight to the GitHub repository and attempted to run the legacy bash installation script using a simple wget command.

My terminal immediately threw a <!DOCTYPE html> syntax error. It turned out I was downloading the HTML page of the script rather than the raw file, but even after fixing that, I realized the old install.sh script had been deprecated. SigNoz recently migrated to a much more robust CLI tool called Foundry for their deployments.

I pivoted to the new instructions and installed the Foundry CLI:_

curl -fsSL https://signoz.io/foundry.sh | bash

To tell Foundry that I wanted a local Docker Compose setup rather than a Kubernetes deployment, I created a quick casting.yaml configuration file:

apiVersion: v1alpha1
kind: Installation
metadata:
  name: signoz
spec:
  deployment:
    flavor: compose
    mode: docker

I ran foundryctl cast -f casting.yaml and the download process began. Everything was going smoothly until the process reached the massive ClickHouse telemetry store containers. Right at 233.1MB out of 246.3MB, my local internet connection dropped completely. The docker daemon threw a fatal context deadline exceeded (Client.Timeout exceeded while awaiting headers) error, and the entire installation crashed out with a signal: killed exception.

Usually, a broken docker pull means you have to clean up dangling images and start over. However, the Foundry CLI handled the interruption perfectly. Once my connection was restored, I ran docker compose down to clear the partial container states, re-ran the cast command, and it picked up the exact remaining 13 megabytes without missing a beat.

Building the Trap

With the SigNoz backend up and running, I needed an application to monitor. I started by creating a new directory and initializing a blank Node.js project. To make sure SigNoz could automatically capture the traces without me writing hundreds of lines of custom spans, I needed to install the official OpenTelemetry auto-instrumentation packages. If you are following along, you can set up the exact same environment using this command:

npm init -y
npm install express @opentelemetry/api @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-trace-otlp-grpc

The auto-instrumentations-node package is the real hero here. It automatically intercepts HTTP requests and Express middleware out of the box, saving a massive amount of setup time.

I wrote a specific login route to act as my trap. If the username field contained common SQL injection characters (like a single quote) or cross-site scripting tags, the server would log a local security alert.

But logging is not enough for true observability. To simulate how a real server reacts to a heavy malicious payload being mitigated by a Web Application Firewall, I added a heavy while loop that deliberately stalls the CPU for a split second before returning a 403 Forbidden error. This meant that an attack would not just cause a status code error, it would cause a highly visible, physical spike in latency.

Here is the exact code I used for app.js:

const express = require('express');
const app = express();
app.use(express.json());

// Dummy login route serving as the trap
app.post('/api/login', (req, res) => {
    const { username, password } = req.body;

    // Simulate detecting a malicious payload
    if (username.includes("'") || username.includes("<script>")) {
        console.warn(`[SECURITY ALERT] Malicious payload detected from IP: ${req.ip}`);

        // Simulate high CPU and Latency during attack mitigation
        let i = 0; while (i < 100000000) i++; 

        return res.status(403).json({ error: "Access Denied" });
    }

    if (username === 'admin' && password === 'admin123') {
        res.status(200).json({ message: "Success" });
    } else {
        res.status(401).json({ error: "Invalid credentials" });
    }
});

app.listen(8081, () => console.log('Vulnerable API running on port 8081'));

You might notice the application is set to listen on port 8081 instead of the standard Node.js port 8080. This was another hard lesson learned during the build. The new Foundry architecture maps the SigNoz frontend dashboard directly to port 8080. When I initially tried to run my API, I hit an EADDRINUSE error. I used a quick sed -i 's/8080/8081/g' app.js command to swap my application port and avoid the conflict.

To instrument the application without manually rewriting all my HTTP handlers, I used OpenTelemetry's auto-instrumentation package. I exported my local SigNoz endpoint and started the server:

export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317"
export OTEL_RESOURCE_ATTRIBUTES="service.name=sec-target-api"
node --require @opentelemetry/auto-instrumentations-node/register app.js

Executing the Attack

With the API listening and sending telemetry data via gRPC to the local collector, I opened a second terminal window to act as the attacker machine.

I wrote a quick bash script to bombard my new API with fifty consecutive requests. I mixed standard failed logins with blatant SQL injection payloads to see if SigNoz could differentiate the traffic noise from the actual attacks.

for i in {1..50}; do
  # Normal failed login attempt
  curl -s -X POST http://localhost:8081/api/login -H "Content-Type: application/json" -d '{"username":"test","password":"123"}' > /dev/null

  # Attack payload featuring SQLi
  curl -s -X POST http://localhost:8081/api/login -H "Content-Type: application/json" -d '{"username":"admin'\'' OR 1=1--","password":"123"}' > /dev/null
done

The moment I executed the loop, my server terminal lit up with warnings. The custom security logic was catching the payloads perfectly.

Catching the Attacker in SigNoz

Local terminal logs are great, but in a production environment, you cannot sit and watch a server console all day. I opened the SigNoz dashboard on localhost:8080 and navigated to the Traces Explorer to see what the telemetry data captured.

The Traces list painted a perfect picture of the attack. Every single malicious request was captured, categorized, and flagged with a red 403 status code. The normal failed logins were also logged, allowing me to easily filter and separate standard user error from malicious intent.

But the most critical piece of observability came from the service metrics. Because I had specifically coded the API to stall the CPU during payload detection, I navigated to the Latency graphs expecting to see the impact.

The P99 latency graph showed an immediate, massive spike pushing past 200ms at the exact timestamp the bash loop was executed.

This visualizes a major concept in cybersecurity. Attackers frequently attempt to exhaust server resources by sending heavy, complex payloads that force the database or backend logic to work overtime. Without a dedicated observability platform like SigNoz, a developer might look at a sluggish server and assume they need to optimize their code or upgrade their hardware. By looking at this dashboard, I could immediately correlate the massive latency spike directly with the influx of 403 errors. The code wasn't slow; it was under attack.

To get even more granular, I clicked into one of the specific red traces from the explorer. SigNoz generated a highly detailed flamegraph representing the exact lifecycle of the HTTP POST request.

The flamegraph visually broke down exactly where the delay was happening. I could see the exact microsecond the request hit the Express middleware, passed through the JSON parser, and finally hit the patched request handler where the CPU stall occurred. If this had been a real application, this trace would tell me exactly which function was vulnerable to resource exhaustion.

What I Learned and Takeaways

Building this project taught me several practical lessons that reading documentation simply cannot cover:

Foundry is Resilient: Dealing with massive Docker image pulls on an unstable internet connection is usually a nightmare. The Foundry CLI proved incredibly resilient, allowing me to resume a broken ClickHouse installation seamlessly.
Mind Your Ports: When self-hosting complex microservice architectures, port collisions are inevitable. Knowing that SigNoz claims port 8080 by default saved me a lot of debugging time when setting up my own Node.js backend.
Metrics Tell a Story: Security is not just about error logs. Monitoring P90 and P99 latency metrics provides a physical representation of how your server reacts to hostile traffic. A sudden latency spike combined with an unusual HTTP status code is often the first indicator of an active breach attempt.

Conclusion

Open-source tools like SigNoz give you total, uncompromised visibility into your system, proving that by combining full-stack development with deep observability, you can catch anomalies before they become full-scale breaches.

HackDesk: My Passion for Hackathons, Powered by Google AI

MEHRAAN AMIN — Fri, 10 Jul 2026 09:55:53 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

My biggest passion is the developer community and hackathons. I love seeing students build amazing things, but I’ve also seen the struggles: organizers stress over check-ins, and beginners freeze when they can't think of a good project idea.

Fueled by this passion to help my community, I built HackDesk - Passion Edition. It is an intelligent, high-performance event management system designed for large-scale hackathons. It features a robust attendee registration system and an AI-powered Hackathon Idea Generator that instantly provides customized, beginner-friendly project ideas to students so they can start building immediately.

Demo

Live Vercel Deployment: HackDesk Passion Edition

(Feel free to try the Idea Generator to see the Google AI fallback in action!)

Code

CodeWithMehru / HackDesk-Passion-Edition

🚀 HackDesk - Passion Edition

An Intelligent, Concurrency-Proof Hackathon Management Platform

HackDesk is a high-performance event management system designed to seamlessly handle large-scale hackathons. It features a robust registration and check-in system, alongside a unique AI-powered Hackathon Idea Generator equipped with atomic locking to prevent race conditions during high-traffic claim events.

Built with modern web technologies to ensure low latency, high availability, and a premium user experience.

✨ Key Features

👥 Smart Registration & Attendance: Bulk-import participants via CSV parsing Manually add late or on-the-spot attendees seamlessly. Active Session tracking (e.g., "Day 1", "Day 2") for accurate multi-day check-ins.

🧠 AI-Powered Idea Pool (Pre-generation & Smart Fallback Architecture): Organizers can generate batches of beginner-friendly project ideas based on specific themes using the Google Gemini AI API Pre-generating ideas prevents API rate limits and keeps the end-user experience lightning fast. If the pool runs empty, the system uses Google AI as…

View on GitHub

How I Built It

I built HackDesk using Next.js 16 (App Router), TypeScript, Tailwind CSS, and Supabase (PostgreSQL).

Managing a hackathon means dealing with high traffic (e.g., 200 students clicking "Generate Idea" at the exact same millisecond). To solve this, I engineered a Concurrency-Proof Idea Claiming system. The backend uses strict isolation and atomic row-level locking in PostgreSQL so that no two students ever get the same idea.

The Smart Fallback Architecture:
To ensure the system never crashes or runs out of ideas, I implemented a two-tier architecture:

It first tries to fetch a pre-generated idea from the Supabase pool.
If the pool is completely empty, instead of throwing an error, the system seamlessly falls back to Google Gemini AI 1.5 Flash. The AI generates a fresh, structured JSON idea on the spot, saves it to the database, and assigns it to the student instantly.

Prize Categories

I am submitting this project for the Best use of Google AI prize category.

I utilized the @google/generative-ai SDK (Gemini 1.5 Flash model) to create the live fallback mechanism. This ensures that the hackathon's idea generation never hits a dead end, combining database reliability with the dynamic generative power of Google AI.

How we built KoshurLock Holmes: an AI detective for cyber attacks, and the night it almost broke me

MEHRAAN AMIN — Sun, 05 Jul 2026 06:54:50 +0000

The problem with a data breach is not finding evidence. It is connecting it.

But let me start where I actually was: 4 AM, last day of the hackathon, staring at this in my terminal.

RateLimitError: GroqException - Rate limit reached for model
`llama-3.3-70b-versatile` on tokens per day (TPD):
Limit 100000, Used 99787, Requested 1616.
Please try again in 20m12s.

Used 99,787 out of 100,000. My deployment was half done, my demo graph was empty on the server, and the free tier had 213 tokens left. The submission deadline was hours away. I had not slept. I had not eaten. My friends were asleep and I was swapping API keys like a gambler swapping chips.

This post is the story of how we got there, and how it ended at 7 in the morning with the best sigh of relief I have ever taken.

First, some honesty about how I got here

When I joined my first WeMakeDevs hackathon, I did not believe in it. I thought it was one of those ordinary online events. Fake prizes, no follow-through, what would I even get out of it. I joined anyway, mostly out of boredom, got into the Discord, talked to people, made a few connections.

I landed in the top 50. A few days later an email showed up: a free Claude Max subscription as a gift. I read it twice. I genuinely could not believe a hackathon had actually delivered something.

So when this hackathon opened, I did not hesitate. I messaged my friends and said we are joining as a team this time. Three of us: me (Mehraan), Aqib, and Ubaid.

The spark

We spent the first evening in our group chat throwing ideas around and shooting most of them down. Then one of my friends dropped a thought that stuck: what happens after a company gets hacked?

I started digging into it. The answer is honestly depressing. After a breach, the evidence is everywhere. VPN records. File access logs. The email gateway. Badge readers at the office doors. CCTV. HR notes. Anonymous tips. Each system tells one small piece of the story, and a human analyst has to stitch all of it together by hand.

That stitching takes days. Sometimes weeks. It is exactly the kind of digital forensics work that companies like Palantir charge enormous money for. And here is the ugly part: read each log alone and the logs will lie to you. If an attacker steals an employee's password, every log points at the employee. The truth only appears when you connect the same person, account, device, IP, and file across every source at once.

So that became the project. An AI investigator that reads all the scattered logs, builds one connected knowledge graph out of them, and answers plain English questions with cited, multi-hop reasoning.

Why the name KoshurLock Holmes

Koshur is what we call the Kashmiri language back home. So the name is exactly what it sounds like: Sherlock Holmes, but ours. A detective from Kashmir.

And the Holmes part is not decoration. The whole product behaves like a detective. It remembers evidence. It recalls answers with citations. You can teach it a confirmed finding. And, this is the part I am most proud of, you can make it forget a planted false clue, and watch the wrong conclusion collapse.

What it actually does

You upload evidence files (CSV, TXT, PDF, DOCX). The backend parses each one, wraps it with a provenance header, and feeds it through Cognee, which extracts entities and relationships and builds a typed knowledge graph. The same person appearing in the VPN log and the badge log resolves to one shared node.

On top of that graph sit four operations that map to Cognee's memory lifecycle:

Remember: ingest each source and build the graph
Recall: ask a question in plain English, get a cited multi-hop answer
Improve: teach it a confirmed analyst finding so the graph reweights
Forget: surgically remove a discredited source

The UI is a security operations console: a full interactive Cytoscape knowledge graph where entity types have their own shapes and colors, a dense filterable timeline built from the log timestamps, an investigation console with expandable raw log citations, and a before-and-after view we call The Turn.

The demo case: a man who was framed

To show what the system can do, we wrote a full fictional incident: the Northgate Financial case.

An employee named Rahul Sharma is framed. On the night of 30 June, someone logs into his account from a foreign IP, 41.220.13.7, out of Lagos. That session downloads the customer database and a PII export and emails them to an external Gmail address. An anonymous tip lands the same week, accusing Rahul directly.

Every log says Rahul did it. Except two: the badge reader and the CCTV both place him physically inside the office at the exact time of the 2 AM foreign login. And a few days earlier, his credentials were phished.

Here is The Turn, live in the app:

Ask "who is responsible?" With all evidence present, including the planted tip, the answer implicates Rahul.
Teach the confirmed SOC finding: the foreign IP is a known attacker, the credentials were phished, this was an account takeover.
Forget the anonymous tip.
Ask again. The conclusion re-derives. Rahul is exonerated, and the system names the external attacker at 41.220.13.7, because the takeover explanation plus the physical alibi make his guilt impossible.

Watching a wrong verdict flip to the right one in front of you never gets old. We also validated the same pipeline on a separate uploaded case, where it correctly identified the true insider and cleared a wrongly accused employee who was on leave.

The architecture decision that shaped everything

Before writing application code we faced a fork in the road.

Option A: the default AI stack. OpenAI for the LLM, a hosted vector database, a separate graph database, paid embeddings. Three or four services, three or four bills, and your evidence leaves your machine.

Option B: make the entire thing free and self-hosted. Groq's free tier for the LLM, embeddings computed locally with FastEmbed, and every kind of storage crammed into one PostgreSQL instance.

We picked B, and it turned out Cognee has a mode built for exactly this. One env var:

USE_UNIFIED_PROVIDER=pghybrid

That puts the relational data, the pgvector index, and the knowledge graph in the same Postgres. One service to run. One pg_dump backs up the entire memory of the investigator. This single decision saved us later in a way I could not have predicted (more on that in the deployment war story).

We were so serious about the no-OpenAI promise that the backend refuses to boot if it detects any path that could route there:

if os.environ.get("OPENAI_API_KEY", "").strip():
    problems.append(
        "OPENAI_API_KEY is present in the environment - unset it so "
        "Cognee cannot fall back to OpenAI"
    )

A hard fail at startup. Paranoid? Yes. Justified? Also yes, as you are about to see.

The quirks that ate my nights

Every tool has sharp edges you only find at 1 AM. Here are the ones that got me, written down so they do not get you.

The silent OpenAI fallback. If you use local FastEmbed embeddings with Cognee, you must set the dimensions explicitly:

EMBEDDING_PROVIDER=fastembed
EMBEDDING_MODEL=sentence-transformers/all-MiniLM-L6-v2
EMBEDDING_DIMENSIONS=384

Leave EMBEDDING_DIMENSIONS unset and Cognee quietly defaults to 3072, which is an OpenAI dimension, and quietly tries to go there. No error. Just wrong behavior you discover much later. This one line is why our startup guard exists.

json_mode, not json_schema. Groq's Llama models mangle the structured tool-call path, and cognify aborts halfway with confusing errors. Plain LLM_INSTRUCTOR_MODE=json_mode works. Hours of my life are in that one setting.

Access control that empties your graph. Cognee's multi-user access control partitions the graph per tenant. Sounds fine, until your node counts read zero and cross-source reasoning falls apart because everything landed in different partitions. For a single-analyst tool: ENABLE_BACKEND_ACCESS_CONTROL=false.

The 100,000 token wall. Groq's free tier gives you 100k tokens per day, and a full ingest of our eight evidence files eats almost exactly that. Run the seed twice in a day and the second run dies mid-graph. Our fix became a core feature: seed once, then pg_dump the whole built graph into a snapshot. Every boot after that restores warm, with zero LLM calls. The demo never spends tokens again.

Deployment day, or, the longest night of my life

Everything worked locally. Then I tried to put it on the internet, and the internet fought back.

Railway does not run a docker-compose file, so the one-command stack became three separate services wired together by hand. The frontend crashed on arrival:

nginx: [emerg] host not found in upstream "backend"

Locally, nginx proxies to a container literally named backend. On Railway there is no such name. And here is the trap: hardcode the Railway internal hostname and your local setup breaks instead. The same config file cannot serve both. The fix was turning nginx.conf into a template that reads the upstream from an environment variable at container start:

location /api/ {
    proxy_pass ${BACKEND_ORIGIN}/;
}

Locally it defaults to http://backend:8000. On Railway a service variable points it at the internal address. One image, both worlds.

Then came the domain confusion that nearly finished me. Railway generated koshurlockholmes.up.railway.app for the backend and koshurlock-holmes.up.railway.app for the frontend. One hyphen apart. At 5 AM, running on no sleep, I pointed the frontend at itself and spent an hour debugging a loop of my own making. If you take one thing from this post: name your services something you cannot confuse at 5 AM.

And the best trick of the night, the one that saved the demo: the server graph was empty and I had no quota left to re-seed it. But remember, the entire memory lives in one Postgres. So I took the snapshot from my laptop and restored it straight into Railway's database over the public connection:

pg_restore --clean --if-exists --no-owner \
  -d "$RAILWAY_DATABASE_URL" \
  scripts/snapshots/cognee_db.dump

Ninety five nodes and 279 edges appeared on the server in about ten seconds. Zero tokens spent. That is the one-Postgres decision from day one paying for itself at the worst possible hour. I nearly cried.

One last bug: every backend restart reset the demo state, so the case kept showing "snapshot not found" after each redeploy. The fix was making the backend restore the snapshot on every startup instead of only on a cold, empty graph. A few lines in the FastAPI lifespan, and restarts stopped being scary.

At 7 AM the full flow finally ran clean on the live link. Demo case loads warm. The Turn flips the verdict. Uploads ingest. I sat back in my chair and just breathed. I had not eaten since the previous afternoon. I did not care.

What I actually learned

I keep coming back to one thought.

A project like this, at this scope, should take three to six months. A knowledge graph engine, a live investigation console, a forensics timeline, a retraction system, self-hosted deployment. Months. We built it in hackathon hours, and I finally understand why people keep doing these things to themselves.

The hackathon effect is real. The pressure, the curiosity, the excitement compress months of work into days, and you come out the other side a different engineer than you went in.

I learned more about Postgres, nginx, LLM rate limits, and my own stubbornness in one sleepless night than in weeks of normal work.

Huge thanks to WeMakeDevs for running this. After two of their hackathons, one skeptical entry and one free Claude Max subscription later, I can say it plainly: these are the best hackathons I have taken part in, and they actually deliver.

KoshurLock Holmes is open source under MIT. The repo has the full docs, the Northgate case spec, and everything you need to run it with one docker compose command and a free Groq key. If you try it, break it, or want to talk about the architecture, find me on GitHub.

The evidence was always there. We just built the detective.

Team: Mehraan Amin (Mehru), Aqib Javid Bhat, Ubaid Mushtaq. Built with Cognee, Groq, FastEmbed, PostgreSQL + pgvector, FastAPI, React, and Cytoscape.js.

How I Built CoralSec Copilot: A Unified Enterprise SOC with Coral & Next.js in 4 Days

MEHRAAN AMIN — Sat, 30 May 2026 06:10:46 +0000

The tech industry is currently in a frenzy. Everyone is rushing to build the next big AI application, slapping a chatbot interface onto a database and calling it a day. But in this gold rush, we are leaving something critical behind: Enterprise Security.

Living in a Kali Linux environment and spending time hunting vulnerabilities teaches you one fundamental truth: security is entirely about context. Hardcoded API keys, undocumented access escalations, and compliance blind spots remain the number one cause of major data breaches. Security teams don’t just need a chatbot that can answer questions; they need a single pane of glass. They need a Security Operations Center (SOC).

For the Pirates of the Coral-Bean Hackathon (hosted by Coral and WeMakeDevs), I decided to tackle this massive industry problem. Over the course of 4 sleepless nights, I built CoralSec Copilot—an AI-powered, unified Enterprise SOC platform.

Here is the complete Captain's Log of my entire journey, the architecture, the roadblocks, and a reproducible guide so you can build and run it yourself.

Day 1: The Brainstorm, Grok, and Cursor AI

When the hackathon was announced, my initial thought was basic: "I'll build a CLI agent that scans code." I fired up my IDE, opened Cursor, and started bouncing ideas around. I even looked into some AI models like Grok to understand how they process vast amounts of real-time data.

But while brainstorming the architecture, I hit a wall. Scanning a GitHub commit for a leaked AWS key is great, but what if the AI also knew whether the developer who pushed that commit had recently escalated their admin privileges? What if it knew the exact SOC2 compliance policy from our company’s Notion workspace?

To do this traditionally, I would have to write dozens of messy REST API integrations. I'd have to handle rate limits, write custom Python scripts for GitHub, another set for Slack, another for Notion, and then build fragile ETL (Extract, Transform, Load) pipelines to bring all that data together.

It sounded like an absolute nightmare for a 4-day sprint. I needed a way to unify data without writing thousands of lines of glue code.

Day 2: The Magic of Coral MCP & Cross-Source SQL

This is where the Coral Protocol stepped in and completely changed my development trajectory.

Coral Protocol is not just a database wrapper; it is a unified data intelligence hub. It allowed me to replace all that custom glue code with read-only, cross-source SQL. By integrating the Coral Model Context Protocol (MCP), I gave my AI agent the ability to write a single query with LEFT JOIN semantics across entirely different platforms.

Instead of writing five different Python scripts to fetch data, my agent can now execute something conceptually like this under the hood:

[[Note for Mehru: Use the code block button in Dev.to for the SQL below]

`SELECT
github.cve_id,
slack.incident_channel,
notion.compliance_policy
FROM github_dependabot AS github
LEFT JOIN slack_channels AS slack ON slack.topic = github.cve_id
LEFT JOIN notion_pages AS notion ON notion.tags = 'SOC2'
WHERE github.state = 'open';`

[End Note]]

As a first-time Coral user, shifting my mindset from writing complex backend logic to simply leveraging Coral’s SQL interface for cross-platform joins was mind-blowing. It completely eliminated the data silos. My AI agent could now correlate a GitHub Dependabot vulnerability, an active Slack security channel, and an internal Notion compliance policy in a single execution path.

Day 3: Giving the AI Brain a Body (Next.js Dashboard)

An AI brain is incredibly powerful, but IT admins and security operators need a visual dashboard to monitor threats continuously. They can't just type prompts all day. I spent the third day wrapping my Coral-powered engine into a persistent Enterprise UI.

Using Next.js 15, Tailwind CSS, and shadcn/ui, I built a 4-module dashboard to act as a single pane of glass:

Global Risk Dashboard
This isn't just a static page. It calculates a dynamic risk score based on aggregated posture signals pulled live from the APIs. It gives security teams a bird's-eye view of their infrastructure's health.
Secret Scanner
Visualizes leaked Personal Access Tokens (PATs) and AWS keys from commit pipelines. It flags critical misconfigurations the moment they happen.
Vulnerability Intelligence
An interactive tracker for OSV and CVE data aligned with Dependabot. It breaks down threats by severity, highlighting things like OpenSSL buffer over-reads or prototype pollution in lodash.
Compliance Monitor
A live ledger that directly compares GitHub admin access against Notion SOC2 policy pages. If someone gets unauthorized admin access on GitHub, the dashboard flags it against the company policy instantly.

Day 4: Resiliency, Python Fallbacks, and The Cybersecurity Mindset

What happens if the cloud alert tables are entirely empty? A security tool cannot just fail silently. I needed this platform to be bulletproof.

To achieve this, I built a resilient Python and LangChain scanner as a fallback. If the primary cloud scans return empty, the system triggers zero-day commit parsing. It uses structured tool calls to parse local commit diffs and surface historical leak patterns before they hit production.

I also engineered bulletproof API pushdowns. I structured the SQL so that queries like Dependabot use exact states (e.g., state = 'open' OR state IS NULL). This ensures that if a third-party API returns a null severity, my dashboard doesn't accidentally drop a valid open alert.

The Sandbox Deployment Decision

When it came time to deploy, I faced a serious dilemma. I wanted the hackathon judges and the community to experience the beautiful Next.js UI. However, as a cybersecurity researcher, I strictly follow security best practices.

Exposing my active Personal Access Tokens (GitHub, Slack, Notion) on a public Vercel domain was an absolute no-go. It defeats the entire purpose of building a security tool.

So, I deployed the live link as an interactive Sandbox / Demo Mode. By adding a simple environment variable, the app renders a safe UI where anyone can explore the UX and the AI agent's frontend flow safely without exposing real company data. But to experience the real-time scanning engine, developers must clone the repo and run it locally with their own keys.

Charting the Course: Build Your Own CoralSec Copilot

If you want to run this Enterprise SOC on your own company's repositories, here is the exact reproducible route to get the real-time scanning engine fired up on your local machine.

Prerequisites:
You will need two terminal windows to run the Next.js UI and the Coral MCP Engine simultaneously.

Step 1: Setup Environment
Clone the repository and set up your environment variables.

[Note for Mehru: Use the code block button in Dev.to for the bash commands below]
git clone https://github.com/CodeWithMehru/coral-security-copilot.git
cd coral-security-copilot
cp .env.example .env
[End Note]

Open the .env file and insert your GitHub, Notion, and Slack tokens. Make sure to set CORALSEC_USE_DEMO=false so you exit the Sandbox and run the live engine!

Step 2: Start Coral Engine
Open your first terminal in the root directory and start the Coral Studio:

[Note for Mehru: Use the code block button in Dev.to for the bash command below] coral mcp studio [End Note]

Step 3: Start the Next.js Frontend
Open a second terminal, install the dependencies, and start the development server:

[Note for Mehru: Use the code block button in Dev.to for the bash command below]
cd frontend
npm install
npm run dev
[End Note]

Open localhost:3000 in your browser to view the live dashboard. You now have a fully functional, AI-powered Enterprise Security Operations Center running on your local machine!
Final Thoughts

Building CoralSec Copilot was an absolute masterclass in data correlation. Coral eliminated the most painful parts of API integration and allowed me to focus entirely on building a robust, intelligent security product.

A massive thank you to Coral and WeMakeDevs for hosting this hackathon. It challenged me to push my boundaries as a full-stack developer and a security researcher. The voyage was long, the code was complex, but the final plunder was absolutely worth it!