Conduit
Conduit
Docsllms.txtHostingGitHubIntroduction

Getting Started

OverviewInstall ConduitMCP SetupYour First AppStart with AI

Learn

ArchitectureClient vs Admin APIConfiguration

Modules

OverviewAuthenticationAuthorizationDatabaseStorageCommunicationsChatRouterFunctions

Guides

Next.js IntegrationReBAC Team ScopingGitOps State Export

Deployment

Deployment OverviewDocker ComposeKubernetes and HelmLocal from SourceContainer Images

Reference

CLI ReferenceClient APIAdmin APIEnvironment VariablesMCP Tools

Resources

Migration v0.16 → v0.17Legacy DocumentationChangelogFAQGlossaryContributing

Architecture

Core, router, modules, Redis, gRPC service discovery, and health probes.

┌─────────────────────────────────────────────────────────────────┐
│  Core (packages/core)                                           │
│  • ConfigManager + Redis config/event bus                       │
│  • Service discovery (module registry, health, recovery)        │
│  • Admin API (REST / GraphQL / WebSockets)  :3030               │
│  • Health: GET /ready (deep), GET /live (shallow)               │
│  • MCP server at /mcp                                           │
└───────────────┬─────────────────────────────────────────────────┘
                │ gRPC (@conduitplatform/grpc-sdk)
    ┌───────────┼───────────┬──────────────┬──────────────┐
    ▼           ▼           ▼              ▼              ▼
 database    router    authentication  storage    …modules
LayerRole
CoreModule registration, config, Admin API, MCP, readiness coordination
RouterClient API gateway (REST, GraphQL, Socket.io) on :3000
Feature modulesDomain logic; register routes via RoutingManager
RedisConfig bus, pub/sub, shared state
Database moduleMongoDB or PostgreSQL — apps never connect directly

Each module connects to core via CONDUIT_SERVER and registers on startup. Custom modules extend ManagedModule from @conduitplatform/module-tools.

Health and readiness

Core exposes two Admin HTTP probes on port 3030 (no auth required):

EndpointPurposeChecks
GET /liveLiveness — process alive, Admin HTTP respondingReturns { status: "alive" } immediately
GET /readyReadiness — platform can serve trafficCore bootstrap, gRPC health, Redis PING, required/optional module registration

/ready returns 200 with a structured report when ready, or 503 when any required check fails. Each check includes name, status (pass | fail | warn), optional message, and latencyMs.

Legacy clients (plain-text curl without Accept: application/json) still receive Conduit Core is online! or Conduit Core is not ready. Pass ?legacy=true to force plain text. Send Accept: application/json for the structured report.

Configure which modules must be registered before core is ready via READY_REQUIRED_MODULES (comma-separated). The official Helm chart sets this to database or database,router depending on whether the router subchart is enabled. See Environment variables for all READY_* settings.

Kubernetes pattern: point readiness and startup probes at HTTP GET /ready:3030; keep liveness on gRPC health (:5000) so transient module-registration delays do not restart the pod. See Kubernetes and Helm.

See Deployment modes and Client vs Admin API.

Start with AI

Give your LLM a copy-paste prompt to build on Conduit v0.17.

Client vs Admin API

Which API to use in apps, MCP, and server-side code — and what never to mix.

On this page

Health and readiness