EDDI
labsai394 ดาว
Config-driven engine that turns JSON into production-grade AI agents. Multi-agent orchestration, 19+ LLM providers, MCP/A2A protocols, RAG, persistent memory, and enterprise compliance (EU AI Act, GDP
- ทรานสปอร์ต
- stdio
- สถานะ
- โลคัล
Power your agent
การติดตั้งจากผู้เผยแพร่ ไม่ใช่เอนด์พอยต์ของ PlugMCP
URL แบบรีโมตหรือคำสั่งบนเครื่องของคุณ? การติดตั้งสองแบบต่างกันอย่างไร
รันบน PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
เปิดจากผู้เผยแพร่
E.D.D.I (Enhanced Dialog Driven Interface) is a production-grade, config-driven multi-agent orchestration middleware for conversational AI. It coordinates users, AI agents, and business systems through intelligent routing, persistent memory, and API orchestration — without writing code.
Built with Java 25 and Quarkus. Ships as a Red Hat-certified Docker image with the Manager dashboard and Chat UI built in. Selected as a UNIDO Trusted Partner for Industrial AI. Native support for MCP (Model Context Protocol), A2A (Agent-to-Agent), the OpenAI Chat Completions API, Slack, OpenAPI, and OAuth 2.0.
Website · Documentation · License: Apache 2.0
The fastest way to get EDDI running is the one-command installer. It sets up EDDI + your choice of database via Docker Compose and points you at the dashboard, where the Platform Operator (or the form-based agent wizard) creates your first AI agent for you.
Linux / macOS / WSL2:
curl -fsSL https://raw.githubusercontent.com/labsai/EDDI/main/install.sh | bash
Windows (PowerShell):
Invoke-WebRequest -UseBasicParsing -Uri "https://raw.githubusercontent.com/labsai/EDDI/main/install.ps1" -OutFile "install.ps1"
Unblock-File .\install.ps1
.\install.ps1
Requires Docker. The wizard auto-generates a unique vault encryption key for secret management.
Everything is served from one port: http://localhost:7070 opens a chooser between the Manager (/manage, the admin dashboard) and the Workforce workspace (/workforce, group conversations), and the standalone chat UI is at /chat. See Getting Started.
bash install.sh --defaults # All defaults, no prompts
bash install.sh --db=postgres --with-auth # PostgreSQL + Keycloak
bash install.sh --full # Everything enabled (PostgreSQL + auth + monitoring)
bash install.sh --local # Build Docker image from local source
bash install.sh --eddi-version=6.5.0 # Pin a release (image and compose files from its tag)
bash install.sh --dry-run # Show the image tag and the git ref the files come from
With the default latest image, the compose files are downloaded from the newest
release's tag (looked up through the GitHub API), not from main.
The --local flag is for contributors testing pre-release builds:
./mvnw package -DskipTests # Build the Java app
bash install.sh --local # Build Docker image + start containers
The installer creates an eddi CLI wrapper that makes updating easy:
eddi update
This pulls the latest Docker image from the registry and restarts the containers. It works even when the same tag (e.g. latest) was re-published — Docker always checks the remote digest for changes.
Upgrading across releases? Read the upgrade guide first: Upgrading from 6.4 lists what an existing deployment must change, because several defaults now fail closed (a Keycloak realm imported from 6.1–6.4 needs a repair that re-running the installer applies and
eddi updatedoes not). A database that comes from EDDI 5 starts with Upgrading from 5.x.
eddicommand not found? The CLI lives at~/.eddi/eddi(Linux/macOS) or~/.eddi/eddi.cmd(Windows). Either restart your terminal so the PATH takes effect, or use the full path:# Linux / macOS ~/.eddi/eddi update # Windows (PowerShell) & "$HOME\.eddi\eddi.cmd" update
If the eddi CLI isn't available, run the equivalent docker commands from your install directory (~/.eddi by default):
cd ~/.eddi
docker compose --env-file .env -f docker-compose.yml pull
docker compose --env-file .env -f docker-compose.yml up -d
Adjust the -f flags to match your setup (e.g. add -f docker-compose.auth.yml if using Keycloak).
If you prefer manual control over Docker Compose:
# Default (EDDI + MongoDB)
docker compose up
# PostgreSQL instead of MongoDB — a complete stack, so it is NOT layered on
# docker-compose.yml (an overlay cannot un-declare the base's mongodb service).
# The database password has no default; keep the value stable across runs
# (install.sh --db=postgres generates one into .env for you)
POSTGRES_PASSWORD=$(openssl rand -base64 24) docker compose -f docker-compose.postgres-only.yml up
# With Keycloak authentication. No realm account ships a password (see the
# header of docker-compose.auth.yml, or let install.sh --with-auth set one)
docker compose -f docker-compose.yml -f docker-compose.auth.yml up
# With Prometheus + Grafana monitoring
docker compose -f docker-compose.yml -f docker-compose.monitoring.yml up
# With a local LLM — Ollama on the same Docker network, reachable as
# http://ollama:11434 (no host.docker.internal needed)
docker compose -f docker-compose.yml -f docker-compose.ollama.yml up -d
# The same local LLM, on the host's NVIDIA GPUs — layered on the Ollama overlay
# above, never instead of it (all it adds is `gpus: all`)
docker compose -f docker-compose.yml -f docker-compose.ollama.yml \
-f docker-compose.ollama-nvidia.yml up -d
# Auth + monitoring + NATS together (overlays stack in any combination)
docker compose -f docker-compose.yml -f docker-compose.auth.yml \
-f docker-compose.monitoring.yml -f docker-compose.nats.yml up
# A cluster: three EDDI replicas behind a round-robin load balancer, a
# three-node NATS JetStream cluster and MongoDB — a whole stack, run on its own
EDDI_VAULT_MASTER_KEY=$(openssl rand -base64 24) MONGO_PASSWORD=$(openssl rand -base64 24) NATS_PASSWORD=$(openssl rand -base64 24) \
docker compose -f docker-compose.cluster.yml up -d
Available compose overlays: docker-compose.auth.yml (Keycloak), docker-compose.monitoring.yml (Prometheus+Grafana), docker-compose.nats.yml (cluster mode with one replica and one NATS server), docker-compose.ollama.yml (local LLM; add docker-compose.ollama-nvidia.yml on top for NVIDIA GPU access), docker-compose.chroma.yml (vector store), docker-compose.mcp-sidecar.yml (reach a stdio-only MCP server through a bridge sidecar — read the MCP Client guide first), docker-compose.local.yml (build from source). docker-compose.postgres-only.yml is a complete standalone stack rather than an overlay — use it on its own, not with -f docker-compose.yml; so is docker-compose.openwebui.yml, a runnable Open WebUI demo of the OpenAI-compatible API, and docker-compose.cluster.yml, the multi-replica stack above (see Clustering).
The compose files publish EDDI (and Keycloak) on 127.0.0.1 only. To reach them from another host, set EDDI_BIND=0.0.0.0 (and KEYCLOAK_BIND for Keycloak) in .env — with authentication on.
The Ollama overlay pulls llama3.2:3b on first start and keeps models in a named volume; override with OLLAMA_PULL_MODEL=qwen3:4b, or set it empty to skip the pull. It also sets EDDI_OLLAMA_DEFAULT_BASE_URL, so the agent wizard and the setup API pre-fill a base URL that resolves from inside the container — the one thing that trips up every first local-LLM agent, because localhost there is the container, not the host.
docker-compose.ollama-nvidia.yml adds GPU access to that Ollama and needs two things of the host, neither of which it degrades gracefully without: Docker Compose 2.30.0 or newer, which is where the gpus service attribute was introduced — older versions fail on it, so check docker compose version — and the NVIDIA Container Toolkit configured as a Docker runtime. gpus: all is a device request: with no GPU driver registered, the daemon cannot satisfy it and the container fails to start (could not select device driver "" with capabilities: [[gpu]]) rather than quietly falling back to the CPU. If you want Ollama on the CPU, leave this overlay off.
docker pull labsai/eddi # Pull latest from Docker Hub
Most multi-agent frameworks (LangGraph, CrewAI, AutoGen) are Python/Node libraries — great for prototyping, hard to govern in production. EDDI approaches from the opposite direction: a deterministic engine built to safely govern non-deterministic AI.
"The engine is strict so the AI can be creative." — Project Philosophy
VOTE phases collect explicit ballots (majority or approval, weighted, quorum-gated) and record a decision with the full tally, the raw ballots, and the losing side's dissentsRETRO phase distils lessons into team-owned group memory, so they surface in every member's later discussions — institutional knowledge that compounds run over runjsonResponseFormat policy (auto | on | off) negotiates structured JSON output across all execution paths with provider-aware rulesGLOBAL, USER, CONVERSATION) to avoid redundant calls; fail-safe to USER on misconfigurationEDDI implements open standards — not proprietary APIs:
self, group, global)self memories unless the agent allows morelongTerm / conversation / step scoping, plus secret for values that go straight into the vault — EDDI's importance extraction mechanismmaxToolContextTokens caps tool output within a single turn (default 60k tokens), evicting oldest tool exchanges to prevent provider context-window errors while preserving tool-call pairingPOST /conversations/{id}/attachments with multipart/form-data)IAttachmentStore SPI with grant-based access control and per-tenant quotasAttachmentTextExtractor) and forwarded as inline context to any LLM, not just vision modelsModelCapabilityService routes images to vision-capable LLMs and falls back to text metadata for otherscontentTypeMatcher behavior rule condition routes image/*, application/pdf, etc. to different workflowsdeleteByConversation() cascades to attachment storage when conversations are erasedpersistent (reuse same conversation across fires) or new (fresh context each time)maxAgentsPerTenant enforcement on agent deploymentPAUSE_CONVERSATION action halts the entire pipeline; new user input returns 409 Conflict until a human resumesPHASE or TASK granularityWAIT_INDEFINITELY, AUTO_APPROVE, AUTO_REJECT, or ABORT when humans don't respond in time${connection:name} resolves per request to an org-wide key or the end user's own OAuth grant (details)${caller:token}, released only to the caller's own origin or to EDDI itself and never persisted (details)"secret": true: usable for one turn, never stored or returned (details)eval(), no script engines, no reflection-based executionUSE / VIEW / EDIT / OWN shares (details){snippets.safety_rules}{vars.default-model} in any config (details)eddi.messaging.type=nats runs any number of replicas of the published image behind a plain round-robin load balancer: cluster-wide conversation leases with fencing, shared security and tool state in NATS JetStream KV, cross-node cancel/GDPR/undeploy, rolling updates without lost turns. See Clustering/q/metrics (tools, vault, memory, scheduling, conversations). Pre-built Grafana dashboard includededdi.pipeline.task carrying eddi.task.id, eddi.task.type, eddi.task.index, eddi.conversation.id and eddi.agent.id. The equivalent metric tags are un-prefixed (task.id, task.type)eddi.llm.request.duration, eddi.llm.tokens, eddi.llm.request.errors) and traced as a gen_ai.client.inference span/q/health/live and /q/health/readyonEmpty / onTruncation / onRefusal), streaming timeout retry, and admin endpoint to reset stuck conversations📖 Monitoring Guide: See docs/monitoring/monitoring-guide.md for architecture overview, metrics reference, alerting rules, and a production checklist.
Both UIs live in this repository (ui/manager, ui/chat) and are built into the EDDI jar and Docker image — nothing to deploy separately.
/manage) — Admin dashboard for agent building, testing, deployment, and monitoring, with the Platform Operator, an agent wizard, and editors for every resource type, including knowledge-base ingestion sources/workforce) — A workspace for group conversations: boards, member threads, a live discussion overview, and history/chat) — Standalone React chat with SSE streaming and Keycloak authEDDI provides built-in infrastructure for regulatory compliance:
Windows users: Replace
./mvnwwith.\mvnw.cmdin all commands below.
Dev mode starts the application with live reload — code changes are picked up automatically without restarting:
# Linux / macOS
./mvnw compile quarkus:dev '-Djvm.args=--add-modules=jdk.incubator.vector'
# Windows (PowerShell)
.\mvnw.cmd compile quarkus:dev '-Djvm.args=--add-modules=jdk.incubator.vector'
-Djvm.args hands the forked dev JVM the same --add-modules=jdk.incubator.vector flag the container image sets. Only jlama (in-process) agents need it — without it Jlama silently falls back to scalar tensor operations and answers far too slowly — so you may drop it if you never run one. mise run dev passes it for you.
Then open http://localhost:7070. The Quarkus Dev UI is available at http://localhost:7070/q/dev.
💡 The Manager and Chat UI build with Maven, at packaging time. Their sources live in
ui/managerandui/chat../mvnw package(andverify,install) builds them into the jar, about two minutes;compile,testand dev mode never touch npm, so dev mode serves/manageonly after apackage. For frontend work runnpm run devinui/manager(port 3000, proxying to the backend on 7070). Upgrading an older checkout? Run./mvnw cleanonce.
Dev mode also enables:
r in the terminal to re-run tests on changes💡 Secrets Vault: To use the secrets vault (storing API keys encrypted), set the master key before starting:
# Linux/macOS export EDDI_VAULT_MASTER_KEY=my-dev-passphrase # Windows (PowerShell) $env:EDDI_VAULT_MASTER_KEY = "my-dev-passphrase" # Or in a .env file (already in .gitignore) echo "EDDI_VAULT_MASTER_KEY=my-dev-passphrase" > .envWithout this, the vault is disabled and secret management returns HTTP 503. Any passphrase works for local development. See Secrets Vault for production setup.
JaCoCo is configured to run automatically during ./mvnw test. After tests complete, find the coverage report at:
target/site/jacoco/index.html
# Build app + Docker image
./mvnw clean package '-Dquarkus.container-image.build=true'
# Build without container (for install.sh --local)
./mvnw package -DskipTests
# Generate third-party licenses (Red Hat certification)
./mvnw package -Plicense-gen -DskipTests
No shipped manifest creates the eddi-secrets Secret that holds the vault master
key — a Secret in the manifests would be reconciled on every kubectl apply and
overwrite a live key, making everything already encrypted with it undecryptable.
So the Secret is created out-of-band, before the first apply. Without it the
EDDI pod sits in ContainerCreating (MountVolume.SetUp failed: secret "eddi-secrets" not found) and never starts.
# Kustomize overlays — create the vault Secret first, then apply
bash k8s/create-secrets.sh # PowerShell 7: pwsh -File .\k8s\create-secrets.ps1
# ...plus the database credentials, which are no longer shipped: mongodb-secrets
# (MongoDB runs authenticated) or postgres-secrets — commands in the Kubernetes Guide
kubectl apply -k k8s/overlays/mongodb/ # MongoDB backend
kubectl apply -k k8s/overlays/postgres/ # PostgreSQL backend
# Quickstart (one-file manifest; same Secret step, see the Kubernetes Guide)
kubectl apply -f https://raw.githubusercontent.com/labsai/EDDI/main/k8s/quickstart.yaml
# Helm (renders the Secret itself, so the key is a required value). Local,
# port-forward shape without OIDC: the two opt-ins are required, see the guide.
helm install eddi ./helm/eddi \
--set eddi.vaultMasterKey="$(openssl rand -base64 24)" \
--set mongodb.rootPassword="$(openssl rand -base64 24)" \
--set eddi.security.allowUnauthenticatedMcp=true \
--set eddi.security.allowUnauthenticatedSecretStore=true \
--namespace eddi --create-namespace
Includes overlays for auth (Keycloak), monitoring (Prometheus/Grafana), cluster mode (a three-node NATS JetStream cluster and three EDDI replicas), Ingress, and production hardening (PDB, NetworkPolicy). See the Kubernetes Guide for details, including the Keycloak upgrade note for existing installs.
We welcome contributions! Please read our Contributing Guide for details on setting up your development environment, code style, commit conventions, and the pull request process.
Every PR is automatically checked by CI (build + tests), CodeQL (security), dependency review, and AI-powered code review.
EDDI ships with security-by-default for production deployments:
AuthStartupGuard fails startup if OIDC is disabled in production without explicit opt-out; tokens must carry the eddi-backend audience and name a user${vault:…}, ${connection:…} or ${caller:…} reference resolves only where the configuration wrote it, not when it arrives through conversation data (a value EDDI auto-vaulted itself is the one exception)OutboundHttp, with private IP blocking, per-hop redirect validation, scheme enforcement and in-flight body capsX-Content-Type-Options, X-Frame-Options, Content-Security-Policy configured out of the box127.0.0.1, and the Helm chart and Kustomize overlays ship no default credentialssecurity-extended queriesFor vulnerability reports, see our Security Policy. For architecture details, see Security Architecture.
This project follows the Contributor Covenant Code of Conduct.
Config-driven engine that turns JSON into production-grade AI agents. Multi-agent orchestration, 19+ LLM providers, MCP/A2A protocols, RAG, persistent memory, and enterprise compliance (EU AI Act, GDP
ภาพรวม
Config-driven engine that turns JSON into production-grade AI agents. Multi-agent orchestration, 19+ LLM providers, MCP/A2A protocols, RAG, persistent memory, and enterprise compliance (EU AI Act, GDPR, HIPAA). Built on Quarkus.
เครื่องมือ
ยังไม่มีรายการเครื่องมือ เซิร์ฟเวอร์แบบรีโมตจะได้รายการหลังการตรวจสอบสถานะครั้งแรก
FAQ
คัดลอกคอนฟิก stdio สำหรับ Cursor, Claude Desktop, Claude Code หรือ VS Code ได้ในหน้านี้ คอนฟิกนี้ใช้การติดตั้งของผู้เผยแพร่ ไม่ใช่พร็อกซีของ PlugMCP
ระเบียนนี้ไม่ได้ระบุตัวแปรสภาพแวดล้อมที่จำเป็น
EDDI ทำงานแบบโลคัลผ่าน stdio
ตรวจสอบล่าสุดเมื่อ 2026-11-15 Config-driven engine that turns JSON into production-grade AI agents. Multi-agent orchestration, 19+ LLM providers, MCP/A2A protocols, RAG, persistent memory, and enterprise compliance (EU AI Act, GDPR, HIPAA). Built on Quarkus.