InfraCore

Enterprise infrastructure operations platform for DevOps, SRE, platform, and security teams.

InfraCore brings project operations, service monitoring, deployment workflows, log analysis, SSH/PEM key governance, internal wiki, notes, AI chat, and RAG-backed knowledge bases into one gateway-first platform.

Platform Overview

Area	Stack
Frontend	React 19, Vite 6, TypeScript, Tailwind CSS 4, Radix UI, Recharts
Backend	Node.js, Express, TypeScript, 11 domain microservices
Gateway	Express API gateway with CORS, proxy routing, Swagger UI, and WebSocket upgrade support
Data	MongoDB via Mongoose
Storage	AWS S3 for attachments and profile/file assets
AI	Google Gemini for log analysis/chat; RAG service supports knowledge ingestion and AI retrieval flows
Realtime	WebSocket monitoring updates
Auth	JWT, role-based access control, 2FA, sessions, API keys

Capabilities

• Project inventory, documentation, tasks, logs, attachments, and deployment workflows
• Enterprise monitoring with service checks, SLA management, alerts, metrics, reports, and live status updates
• AI-assisted log parsing, enhanced analysis, and chat workflows
• SSH/PEM key lifecycle management with encryption, usage history, metrics, and export helpers
• Feature wiki with spaces, entries, templates, comments, permissions, versioning, search, analytics, and audit logs
• RAG knowledge bases with document/text/URL ingestion and source-grounded chat
• Admin console for users, sessions, audit logs, role changes, password resets, and 2FA support
• Organization settings, notes, personal dashboards, and export/report utilities

Architecture

InfraCore is a gateway-first microservices system. The frontend never calls domain services directly; all browser API and WebSocket traffic is routed through the gateway.

flowchart TD
    Browser["Browser\nlocalhost:3000"]

    subgraph Frontend["Frontend - React 19 + Vite"]
        UI["InfraCore UI\nRadix UI, Tailwind, Recharts"]
    end

    subgraph Gateway["API Gateway - :3001"]
        GW["Express proxy\nCORS, JWT passthrough, Swagger, WS upgrade"]
    end

    subgraph Services["Domain Services"]
        AUTH["auth-service :3002\nusers, sessions, 2FA, API keys"]
        PROJ["project-service :3003\nprojects, tasks, docs, deployments, S3 files"]
        MON["monitoring-service :3004\nmonitors, SLA, alerts, metrics, WebSocket"]
        LOG["log-parser-service :3005\nlog parsing, AI analysis"]
        PEM["pem-key-service :3006\nSSH/PEM keys, usage logs"]
        NOTES["notes-service :3007\nnotes"]
        CHAT["chat-service :3008\nchat, AI generation"]
        ADMIN["admin-service :3009\nuser admin, audit, sessions"]
        WIKI["wiki-service :3010\nspaces, entries, permissions, versioning"]
        ORG["organization-service :3011\norganization settings"]
        RAG["rag-knowledge-service :3012\nknowledge bases, ingestion, RAG chat"]
    end

    subgraph Shared["@infracore/shared"]
        SH["protect, authorize, AuthRequest\nUserRef, crypto, sanitize, rateLimiter, errorHandler"]
    end

    subgraph External["External Dependencies"]
        MONGO[("MongoDB")]
        S3["AWS S3"]
        GEMINI["Google Gemini"]
        RAGAI["RAG AI provider config"]
    end

    Browser --> Frontend
    Frontend -->|"/api/* and /ws/* via Vite proxy"| Gateway

    Gateway -->|"/api/auth/*, /api/keys/*"| AUTH
    Gateway -->|"/api/projects/*, /api/tasks/*, /api/deployment/*, /api/files/*"| PROJ
    Gateway -->|"/api/monitors/*, /api/monitoring/*, /ws/monitoring"| MON
    Gateway -->|"/api/logs/*"| LOG
    Gateway -->|"/api/pem-files/*"| PEM
    Gateway -->|"/api/notes/*"| NOTES
    Gateway -->|"/api/chats/*"| CHAT
    Gateway -->|"/api/admin/*"| ADMIN
    Gateway -->|"/api/wiki/*"| WIKI
    Gateway -->|"/api/organization/*"| ORG
    Gateway -->|"/api/rag/*"| RAG

    AUTH & PROJ & MON & PEM & NOTES & CHAT & ADMIN & WIKI & ORG & RAG --> MONGO
    PROJ & AUTH --> S3
    LOG & CHAT --> GEMINI
    RAG --> RAGAI
    Services -.-> SH

Loading

See docs/architecture.md for the gateway route map, service ownership model, and transformation notes.

Services

Service	Port	Responsibility
api-gateway	3001	Public backend entrypoint, route proxying, Swagger UI, WebSocket upgrade
auth-service	3002	Users, login/signup, JWT sessions, 2FA, profile, API keys, security events
project-service	3003	Projects, tasks, logs, documents, deployments, file/S3 access
monitoring-service	3004	Monitor CRUD, health checks, SLA, alerting, metrics, observability, reports
log-parser-service	3005	File/text log parsing and AI-powered analysis
pem-key-service	3006	Encrypted SSH/PEM key records, usage tracking, bulk operations
notes-service	3007	User notes
chat-service	3008	Conversations, generation, log-analysis chat
admin-service	3009	User administration, audit logs, sessions, admin reporting
wiki-service	3010	Spaces, feature entries, permissions, comments, attachments, versions, analytics
organization-service	3011	Organization-level settings
rag-knowledge-service	3012	Knowledge bases, document ingestion, chunks, RAG conversations

Repository Layout

.
├── App.tsx, AppRouter.tsx       # Frontend shell and routing
├── components/                  # React feature and UI components
├── context/                     # Auth and toast providers
├── hooks/                       # Frontend data and behavior hooks
├── services/api.ts              # Frontend API client
├── utils/                       # Export, report, validation, markdown, and wiki helpers
├── services/
│   ├── shared/                  # @infracore/shared middleware, types, models, utilities
│   ├── api-gateway/             # Gateway service
│   ├── auth-service/            # Identity and access
│   ├── project-service/         # Projects, files, tasks, deployments
│   ├── monitoring-service/      # Enterprise monitoring and realtime status
│   ├── log-parser-service/      # Log parsing and AI analysis
│   ├── pem-key-service/         # PEM key governance
│   ├── notes-service/           # Notes
│   ├── chat-service/            # Chat and AI generation
│   ├── admin-service/           # Administration
│   ├── wiki-service/            # Wiki and knowledge documentation
│   ├── organization-service/    # Organization settings
│   └── rag-knowledge-service/   # RAG knowledge bases
├── scripts/
│   ├── admin/                   # Admin/user/token helpers
│   ├── debug/                   # Diagnostics and local investigations
│   ├── dev/                     # Service startup helpers
│   ├── maintenance/             # Readiness and production-support utilities
│   ├── migrations/              # Data migrations
│   ├── seed/                    # Seed data
│   └── testing/                 # Smoke, integration, security, and manual test helpers
├── docs/                        # Architecture and migration documentation
├── reports/                     # PDF/report utilities
├── jenkins/                     # CI/CD notes
└── vite.config.ts               # Frontend dev/build configuration

Prerequisites

• Node.js 20 or newer
• npm 10 or newer
• MongoDB connection string, local or Atlas
• AWS account and S3 bucket for attachment/profile/file workflows
• Google Gemini API key for log analysis and chat features
• Optional: Redis URL for services/features that enable caching or rate-limit backing stores
• Optional: Docker and Docker Compose for containerized service runs

Environment Configuration

InfraCore backend services explicitly load the repository root .env file. Vite also supports .env.local for frontend-only overrides. Do not commit real secrets.

Create or update the root .env file from your secure secret source. For frontend-only Vite overrides, optionally create .env.local:

cp .env .env.local

Minimum local variables:

MONGO_URI=mongodb+srv://...
JWT_SECRET=<long-random-secret>
JWT_LIFETIME=30d
ENCRYPTION_KEY=<32-character-key>
ENCRYPTION_IV=<16-character-iv>

API_KEY=<google-gemini-api-key>
GEMINI_API_KEY=<optional-gemini-alias>
AI_PROVIDER=gemini
AI_MODEL=gemini-2.5-flash

S3_BUCKET_NAME=<bucket-name>
AWS_REGION=ap-south-1
AWS_ACCESS_KEY_ID=<access-key>
AWS_SECRET_ACCESS_KEY=<secret-key>

VITE_API_URL=http://localhost:3001
ALLOWED_ORIGINS=http://localhost:3000
LOG_LEVEL=info
REDIS_URL=<optional-redis-url>
RAG_NVIDIA_API_KEY=<optional-rag-provider-key>
NVIDIA_API_KEY=<optional-wiki-ai-provider-key>
FRONTEND_URL=http://localhost:3000
APP_URL=http://localhost:3000

Operational guidance:

• Use a secret manager in shared, staging, and production environments.
• Rotate JWT_SECRET, AWS credentials, AI provider keys, and encryption material through controlled runbooks.
• Keep frontend-exposed variables limited to the VITE_ prefix and never place private credentials in those values.
• Use separate MongoDB databases or clusters per environment.

Local Development

Install root dependencies:

npm install

Install service workspace dependencies:

cd services
npm install

Build the shared package before starting services:

cd services
npm run build:shared

Start all backend services from the repository root:

npm run dev:services

Start the frontend in another terminal:

npm run dev

Local endpoints:

Endpoint	URL
Frontend	http://localhost:3000
Gateway health	http://localhost:3001/health
Gateway Swagger UI	http://localhost:3001/api-docs
Monitoring WebSocket	ws://localhost:3001/ws/monitoring

Create a first admin user:

npm run script:admin:create

Runtime logs for the full service launcher are written to:

/tmp/<service-name>.log

Common Commands

Command	Purpose
npm run dev	Start the Vite frontend on port 3000
npm run dev:services	Start all 11 backend services
npm run dev:monitoring:enterprise	Start enterprise monitoring helper flow
npm run dev:rag	Start only the RAG service helper
npm run dev:rag:stop	Stop the RAG service helper
npm run dev:rag:restart	Restart the RAG service helper
npm run build	Build the frontend
npm run preview	Preview the frontend production build
npm test	Run root Vitest tests
npm run test:watch	Run root Vitest in watch mode
npm run script:smoke-test	Run gateway API smoke tests against running services
npm run script:admin:create	Create an admin user
npm run script:test:pem	Run PEM validation helper
npm run script:test:pem:full	Run full PEM test suite
npm run script:test:wiki:setup	Prepare wiki phase-1 testing data

Service-level commands:

cd services/<service-name>
npm run dev
npm run build
npm start

Shared package:

cd services/shared
npm run build

Docker Compose

The compose file under services/docker-compose.yml defines the gateway and service containers. It expects environment variables to be available to Docker Compose.

cd services
docker-compose up --build

Stop containers:

cd services
docker-compose down

MongoDB is intentionally commented out in compose; use MongoDB Atlas or enable a local MongoDB service explicitly for your environment.

Testing And Quality Gates

Run the core frontend test suite:

npm test

Run gateway smoke tests after the backend stack is running:

npm run script:smoke-test

Run service-specific tests where configured:

cd services/project-service && npm test
cd services/rag-knowledge-service && npm test
cd services/monitoring-service && npm test

Before production promotion, complete:

• Frontend build: npm run build
• Shared package build: cd services && npm run build:shared
• Gateway smoke test: npm run script:smoke-test
• Critical UI smoke pass against the microservices stack
• Security-sensitive workflow checks for auth, 2FA, admin, PEM keys, S3 file access, and AI features

Production Readiness Notes

Recommended deployment posture:

• Deploy the frontend as static assets behind a CDN or web tier.
• Expose only the API gateway publicly; keep domain services private on the service network.
• Terminate TLS at the ingress/load balancer and forward to the gateway over the private network.
• Configure health checks for /health on the gateway and every service.
• Use per-environment secret management, least-privilege AWS IAM, and private MongoDB networking where possible.
• Configure centralized logs, metrics, alerting, and dashboards for every service.
• Run database migrations and seed scripts as controlled one-off jobs, not ad hoc shell sessions.
• Back up MongoDB and S3 according to recovery-point and recovery-time objectives.

Security Model

• JWT authentication is enforced through shared middleware.
• Role-based authorization uses authorize(...roles) from @infracore/shared.
• Auth service owns users, sessions, 2FA, API keys, profile flows, and security events.
• Admin service provides operational administration, audit, and session management workflows.
• PEM key and organization-sensitive fields use encryption utilities from the shared package.
• File workflows use AWS S3 rather than local service disk storage.
• Gateway centralizes public backend exposure and CORS policy.

Known architectural debt is tracked in docs/monolith-retirement-checklist.md, including remaining auth/session boundary hardening and contract-test coverage.

Shared Package

services/shared builds the @infracore/shared package consumed by backend services.

It provides:

• protect JWT authentication middleware
• authorize(...roles) role guard middleware
• AuthRequest Express request type
• UserRef read-only Mongoose model stub for auth-owned user references
• Encryption/decryption utilities
• Input sanitization
• Rate limiter middleware
• Central error handler

Rebuild after shared changes:

cd services/shared
npm run build

Documentation

• Architecture
• Microservices migration
• Monolith retirement checklist
• Repository structure
• Scripts guide
• Services guide
• Jenkins guide

Current Transformation Status

The legacy backend migration is API-cutover complete:

• All active route families are gateway-wired to domain services.
• API smoke tests passed 14/14 on 2026-04-30.
• Runtime startup uses dev:services; the old root monolith command has been removed.
• Wiki user coupling has been refactored to denormalized snapshot fields.

Remaining enterprise hardening items:

• Complete manual UI smoke tests against the microservices stack.
• Finish auth/session ownership cleanup so admin operations use auth-owned contracts.
• Add gateway-to-service contract tests and broader integration coverage.
• Standardize logging, metrics, readiness, and liveness patterns across every service.
• Confirm each service can be built and deployed independently.

Contribution Standards

• Put frontend work under the root app structure: components/, hooks/, context/, utils/, and related frontend modules.
• Put backend behavior in the owning service under services/.
• Do not add new runtime code to a legacy monolith path.
• Keep service data ownership explicit; avoid direct cross-service collection reads for new work.
• Store user display data as denormalized snapshots where cross-service documents need attribution.
• Document architecture, ownership, and operational changes under docs/.
• Add focused tests for high-risk paths, shared behavior, auth/security flows, migrations, and gateway contracts.

License

Private project. Confirm licensing and distribution terms with the repository owner before external use.