MongoGuard AI

MongoDB observability dashboard with:

• Live cluster status/metrics/logs
• Runtime MongoDB URI connection from the frontend
• Anomaly detection (slow queries, auth bursts, query spikes)
• Grounded AI chat powered by Google AI Studio Gemini Flash

Monorepo

apps/
  api/      # Express backend
  web/      # Next.js dashboard
packages/
  shared/   # Shared zod schemas/types

Local setup

1. Install

npm install

2. Env files

copy apps\api\.env.example apps\api\.env
copy apps\web\.env.local.example apps\web\.env.local

apps/api/.env important fields:

API_PORT=4000
GEMINI_API_KEY=your_google_ai_studio_key
GEMINI_MODEL=gemini-3-flash

MongoDB can still be configured from env (MONGODB_URI, MONGODB_DB, etc.), but now you can also set URI directly from the dashboard UI.

3. Start apps

npm run dev

• API: http://localhost:4000
• Web: http://localhost:3000

New runtime connection flow

From dashboard:

1. Open Dashboard
2. Paste Mongo URI in MongoDB Connection
3. Set DB name
4. Click Connect

This calls:

• POST /connection to apply URI without restarting API
• GET /connection for current runtime connection state
• DELETE /connection to switch back to simulation mode

AI chat (Gemini Flash)

The assistant endpoint is:

• POST /ai/chat

Behavior:

• Uses Google AI Studio API key (GEMINI_API_KEY)
• Tries Gemini Flash models with fallback (gemini-3-flash, gemini-3.0-flash, gemini-2.5-flash, etc.)
• Includes recent metrics/logs/anomalies + short chat history
• Returns structured response: answer, evidence, suggested actions

Useful endpoints

• GET /status
• GET /metrics?windowMinutes=60
• GET /logs?limit=100
• GET /anomalies?activeOnly=false&limit=50
• GET /mongo/inventory?collectionLimit=10
• GET /ai/context?windowMinutes=30
• POST /ai/chat
• POST /testing/scenario

How to test alerts/logs quickly

Option A: One-click test from UI

In dashboard, use the Generate test events buttons:

• Slow Query Spike
• Auth Failure Burst
• Query Volume Spike

This injects synthetic metrics/logs and should trigger anomalies in the Alerts tab.

Option B: API test call

curl -X POST http://localhost:4000/testing/scenario ^
  -H "Content-Type: application/json" ^
  -d "{\"scenario\":\"slow_query_spike\",\"intensity\":3}"

Other scenario values:

• auth_failure_burst
• query_volume_spike
• mixed

Notes

• Runtime URI is held in API process memory; restarting API resets runtime connection state.
• Dashboard local storage keeps your last typed URI/DB for convenience on the same browser.
• If Gemini key/model is invalid, chat returns actionable error guidance instead of failing silently.

Deploy API + Web (connected)

This repo now includes two deployment workflows:

• Web (GitHub Pages): .github/workflows/deploy-pages.yml
• API (Render): .github/workflows/deploy-api-render.yml

1) Deploy the API (Render)

1. In Render, create a new service from this repo using render.yaml.
2. Set required env vars in Render:

• GEMINI_API_KEY
• MONGODB_URI (or direct connector env vars)
• CORS_ALLOWED_ORIGINS = your Pages origin (example: https://<your-user>.github.io)

3. In Render service settings, copy the Deploy Hook URL.
4. In GitHub repo secrets, add:

• RENDER_DEPLOY_HOOK_URL = Render deploy hook URL

On every push to main that changes API/shared code, GitHub Actions builds API and triggers Render deploy.

2) Deploy the Web (GitHub Pages)

1. In GitHub repo Settings → Pages, set source to GitHub Actions.
2. In GitHub repo Settings → Secrets and variables → Actions → Variables, add:

• NEXT_PUBLIC_API_BASE_URL = your deployed API URL (example: https://mongoguard-api.onrender.com)

On every push to main that changes web/shared code, the web app is built as static export and deployed to Pages.

3) Connection between web and API

• Web calls API through NEXT_PUBLIC_API_BASE_URL.
• API allows browser requests from CORS_ALLOWED_ORIGINS.
• Make sure both point to each other correctly:
  • NEXT_PUBLIC_API_BASE_URL → deployed API URL
  • CORS_ALLOWED_ORIGINS → deployed Pages origin