labsai/EDDI is a Quarkus middleware that stores agent definitions as JSON in MongoDB or Postgres and runs them against 12+ LLM providers. The install path is a one-command script, but the default Compose stack ships with authentication switched off.

Can I use labsai/EDDI commercially?

Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is labsai/EDDI still maintained?

Yes. The repository received new commits within the last day.

What programming language is labsai/EDDI written in?

Mainly Java, according to GitHub's language statistics.

EDDI AI: config-driven multi-agent orchestration in Java

At a glance

What is it?: labsai/EDDI is a Quarkus middleware that stores agent definitions as JSON in MongoDB or Postgres and runs them against 12+ LLM providers. The install path is a one-command script, but the default Compose stack ships with authentication switched off.
Who is it for?: EDDI fits teams that want conversational agents defined as versionable JSON and executed by a Java service they already know how to operate, especially where MCP, A2A or a local Ollama model is on the roadmap. Skip it if you want a Python notebook, a single-agent library, or a hosted SaaS with no Docker in the loop.
Can I use it commercially?: Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository received new commits within the last day.
What is it written in?: Mainly Java, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Written by the Hysen Labs editorial pipeline with AI assistance. Checked against the repository by machine, not yet reviewed by a named editor. How we write these Last updated September 10, 2026.

The problem EDDI targets: agents that live in code you cannot audit

Most agent frameworks put behaviour in Python or TypeScript. Changing a prompt, a routing rule, or which model answers a given intent means a code review, a rebuild and a redeploy. EDDI's README describes the project as a "config-driven multi-agent orchestration middleware" and says it coordinates users, agents and business systems "without writing code". The unit of work is a JSON agent definition stored in the datastore, not a class in a repository.

That matters for a specific kind of buyer. If your organisation already runs Java services, has an operations team comfortable with Quarkus and Docker, and needs an audit trail of what each agent was told to do, the config-first model is easier to govern than a codebase of prompt strings. The README also lists EU AI Act, GDPR and HIPAA concerns as first-class topics, which points at regulated deployments rather than weekend prototypes. The project is not aimed at someone who wants a fifteen-line script that calls an LLM once.

How EDDI works: JSON in the datastore, Quarkus in the middle

The architecture visible in the repository is a Java service built on Quarkus and packaged as a Docker image (labsai/eddi). Agent definitions, conversation state and memory live in a datastore selected by the EDDI_DATASTORE_TYPE environment variable, whose documented values are mongodb and postgres. MongoDB is the default; the .env.example shows the same variable set to mongodb.

The service exposes an HTTP API on port 7070 by default, with HTTPS on 7443, and the README describes routing between users, agents and business systems as the core job. Protocols named in the README include MCP (Model Context Protocol) for tool access, A2A for agent-to-agent calls, OpenAPI for business systems, plus Slack and OAuth 2.0. A separate mcp-sidecar directory and a docker-compose.mcp-sidecar.yml file suggest MCP can also run as its own container rather than inside the main service.

Compose overlays carry the optional pieces: docker-compose.auth.yml for Keycloak, docker-compose.monitoring.yml for Prometheus and Grafana, docker-compose.nats.yml for NATS JetStream, docker-compose.chroma.yml for a vector store, and docker-compose.ollama.yml for a local model. The README states these stack in any combination. One exception is documented explicitly: docker-compose.postgres-only.yml is a complete standalone stack, not an overlay, because an overlay cannot un-declare the base file's mongodb service.

Installing EDDI and creating a first agent

The README's quick start is a one-command installer. On Linux, macOS or WSL2 it is a curl pipe into bash; Docker is the only stated prerequisite. The installer sets up EDDI plus your choice of database through Docker Compose and, according to the README, auto-generates a unique vault encryption key for secret management.

bash

curl -fsSL https://raw.githubusercontent.com/labsai/EDDI/main/install.sh | bash

On Windows the README gives a PowerShell equivalent that downloads install.ps1, unblocks it and runs it.

powershell

Invoke-WebRequest -UseBasicParsing -Uri "https://raw.githubusercontent.com/labsai/EDDI/main/install.ps1" -OutFile "install.ps1"
Unblock-File .\install.ps1
.\install.ps1

The installer accepts flags. The README lists --defaults for a prompt-free run, --db=postgres --with-auth for PostgreSQL plus Keycloak, --full for database, auth and monitoring together, and --local to build the image from local source.

bash

bash install.sh --defaults
bash install.sh --db=postgres --with-auth
bash install.sh --full

After installation the README says the dashboard is where the Platform Operator, or a form-based agent wizard, creates your first AI agent. The wizard is the first real use: you describe the agent in a form rather than writing a class. If you prefer manual Compose control, the README gives these, and the Ollama overlay is worth noting because it sets EDDI_OLLAMA_DEFAULT_BASE_URL so the wizard pre-fills a base URL that resolves inside the container network.

bash

docker compose up
docker compose -f docker-compose.postgres-only.yml up
docker compose -f docker-compose.yml -f docker-compose.ollama.yml up -d

Updating is handled by a CLI wrapper the installer creates; the README notes it re-checks the remote digest even when the tag is unchanged.

bash

eddi update

If the command is not on your PATH, the README points at ~/.eddi/eddi on Linux and macOS, or ~/.eddi/eddi.cmd on Windows, and gives the manual equivalent from the install directory.

bash

cd ~/.eddi
docker compose --env-file .env -f docker-compose.yml pull
docker compose --env-file .env -f docker-compose.yml up -d

The default Compose stack runs with authentication disabled

This is the limitation to read before anything else. In the repository's docker-compose.yml, EDDI_SECURITY_ALLOW_UNAUTHENTICATED defaults to true, with a comment stating that every API endpoint is then reachable without a token and that the value must be false for anything reachable from outside localhost. Two further flags, EDDI_MCP_ALLOW_UNAUTHENTICATED and EDDI_SECRETSTORE_ALLOW_UNAUTHENTICATED, also default to true, and the comment explains they are deliberately separate so that inheriting the first flag is not enough to expose agent CRUD or vault writes. QUARKUS_OIDC_TENANT_ENABLED defaults to false.

The file does describe a guard: AuthStartupGuard logs a [SECURITY] ERROR banner at boot and a WARN reminder every hour when OIDC is off in production mode, and HighValueSurfaceGuard refuses to boot while OIDC is off and the MCP or secretstore flags are unset. That is a reasonable mitigation, but it is a log line, not a lock. The README's own quick start works out of the box on a laptop precisely because auth is off, so the convenient path and the safe path diverge at the first command.

The second constraint is deployment shape. MongoDB is the default datastore, and the Postgres route is a separate complete Compose file rather than an overlay, so teams standardised on Postgres cannot simply add a flag to the default stack. The README does not document a supported migration path between the two datastores. A third gap: the README does not state whether agent definitions can be exported and re-imported across instances, which is the question any team will ask before promoting an agent from staging to production.

Where EDDI is the wrong tool

If your agent logic is genuinely a few hundred lines of Python, EDDI adds a JVM service, a datastore, a Compose file and a secrets vault to manage. The config-driven model pays off when many people edit agents and you need those edits to be data rather than code; it costs you when one engineer owns the whole thing.

It is also the wrong fit if you need a framework to embed inside an existing Java application as a library. EDDI ships as a Docker image and a service, and the README's install paths are all container-oriented. There is a --local build path for contributors, but nothing in the README describes consuming EDDI as a Maven dependency inside another application.

Finally, if your requirement is a hosted product with no infrastructure, EDDI is the opposite of that. You supply the Docker host, the datastore and the Keycloak instance. The compliance topics in the README describe what the project is built to support, not a certification the vendor carries for you.

EDDI against a general-purpose agent library

The natural alternative for a Java team is LangChain4j used directly. EDDI lists langchain4j among its topics, so the relationship is layered rather than competing: a library such as LangChain4j gives you model clients, prompt templates and tool-calling primitives inside your own process, while EDDI gives you a running service that stores agent definitions, routes conversations and persists memory.

The difference shows up in who can change an agent. With a library, the agent is a class in your repository and changing it is a pull request, a build and a deploy. With EDDI, the README's agent wizard and the JSON definitions in the datastore mean a non-developer can create or adjust an agent through the dashboard. You trade compile-time type safety and direct access to library internals for runtime configurability and a central place where every agent definition lives.

A second comparison point is the protocol surface. EDDI's README names MCP and A2A as native, and the repository carries docker-compose.mcp-sidecar.yml, so an MCP server can run alongside the main service. A bare library leaves that wiring to you.

Maintenance, upgrades and licence

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent: 6.3.0 on 2026-08-20, 6.2.0 on 2026-07-27, and 6.1.2 on 2026-06-28. The README advertises a Red Hat-certified Docker image, which sets an expectation that image tags are the supported upgrade unit.

The documented upgrade path is a single command, eddi update, which the README says pulls the latest image and restarts the containers, checking the remote digest even when the tag has not changed. That is convenient, and it is also the risk: following it on a production host moves you to whatever the latest tag points at. The README does not document rollback, a pinning workflow beyond setting EDDI_VERSION in .env, or a schema migration step for the datastore. Teams that need change control should set EDDI_VERSION to a specific release rather than latest and treat the CLI as a development convenience.

On licensing, the project is Apache-2.0, which permits commercial use and modification. The repository carries a licenses/ directory and a PRIVACY.md, and the README lists EU AI Act, GDPR and HIPAA as compliance topics. Those are statements about what the software is designed to support. Whether your deployment satisfies a given regulation depends on your configuration, your data flows and your own legal review; the Apache-2.0 licence grants no compliance guarantee.

Editorial conclusion

EDDI fits teams that want conversational agents defined as versionable JSON and executed by a Java service they already know how to operate, especially where MCP, A2A or a local Ollama model is on the roadmap. Skip it if you want a Python notebook, a single-agent library, or a hosted SaaS with no Docker in the loop. Before adopting, read the three unauthenticated flags in docker-compose.yml and decide what your .env sets them to, then confirm the datastore choice: docker-compose.postgres-only.yml is a standalone stack, not an overlay, and cannot be layered on docker-compose.yml.

Frequently asked questions

Do I need to write code to create an agent in EDDI?

The README states agents are created through the dashboard, either by the Platform Operator or through a form-based agent wizard, and that the middleware coordinates agents without writing code. Agent definitions live as JSON in the configured datastore.

Is EDDI secure by default?

No. In the repository's docker-compose.yml, EDDI_SECURITY_ALLOW_UNAUTHENTICATED defaults to true, and the comment says every API endpoint is then reachable without a token and that the value must be false for anything reachable from outside localhost. The MCP and secretstore endpoints have their own separate flags, also defaulting to true.

Which databases can EDDI use?

The .env.example documents EDDI_DATASTORE_TYPE with the values mongodb and postgres, and MongoDB is the default. The README notes that docker-compose.postgres-only.yml is a complete standalone stack rather than an overlay, because an overlay cannot un-declare the base file's mongodb service.

How do I update an EDDI installation?

The installer creates an eddi CLI wrapper, and the README's update command is eddi update, which pulls the latest Docker image and restarts the containers. If the command is not on your PATH, the README gives the full path at ~/.eddi/eddi or a manual docker compose pull and up sequence.

Can EDDI run a local LLM without an external provider?

Yes, via the Ollama overlay. The README states docker-compose.ollama.yml pulls llama3.2:3b on first start, keeps models in a named volume, and sets EDDI_OLLAMA_DEFAULT_BASE_URL so the agent wizard pre-fills a base URL that resolves from inside the container.

Official sources

Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

markdown

[![Hysen Labs](https://hysenlabs.com/badge/labsai-eddi.svg)](https://hysenlabs.com/projects/labsai-eddi)