labsai/EDDI

**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
---
📑 Table of Contents
- 🏁 Quick Start
- 💡 Why EDDI?
- 📸 See It In Action
- ✨ Features
- 📖 Documentation
- 📋 Compliance & Privacy
- 🏗️ Development
- Prerequisites
- Quarkus Dev Mode
- Maven Command Reference
- Build & Docker
- Kubernetes
- 🤝 Contributing
- 🔒 Security
- 📜 Code of Conduct
---
🏁 Quick Start
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:**
**Windows (PowerShell):**
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.
🔧 Installer options
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:
🔄 Updating
The installer creates an eddi CLI wrapper that makes updating easy:
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 update does not). A database that comes from EDDI 5 starts with Upgrading from 5.x.
> **eddi command 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:
>
>
Manual update (without the CLI)
If the eddi CLI isn't available, run the equivalent docker commands from your install directory (~/.eddi by default):
Adjust the -f flags to match your setup (e.g. add -f docker-compose.auth.yml if using Keycloak).
🐳 Docker Compose (Manual)
If you prefer manual control over Docker Compose:
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.