# Next AI Draw.io: an AI chat layer over draw.io, self-hosted or in Docker

> Next AI Draw.io turns natural language prompts into draw.io XML inside a Next.js app, with an MCP server for Claude Desktop, Cursor and VS Code. It is Apache-2.0, self-hostable, and the last push was on 2026-05-21.

**DayuanJiang/next-ai-draw-io** — A next.js web application that integrates AI capabilities with draw.io diagrams. This app allows you to create, modify, and enhance diagrams through natural language commands and AI-assisted visualization.

- Repository: https://github.com/DayuanJiang/next-ai-draw-io
- Website: https://next-ai-drawio.jiang.jp/
- Stars: 36,043 · Forks: 3,855
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/dayuanjiang-next-ai-draw-io

## The gap Next AI Draw.io fills between a prompt and a draw.io file

Most text-to-diagram tools return a picture. You get a PNG, you paste it into a document, and the moment someone asks you to move a box or rename a service you are back to redrawing by hand. Next AI Draw.io takes the other route: the output is draw.io diagram data, so the result stays editable in the same editor your team already uses. The README describes the project as a Next.js web application that "integrates AI capabilities with draw.io diagrams", and the examples it lists are the kind of thing that would otherwise take twenty minutes of dragging: a RAG architecture diagram for a chat application, an authentication flow using React with AWS in a serverless style, a transformer architecture diagram with animated connectors.

The audience is narrow and fairly specific. It suits engineers who already think in draw.io files, who want a diagram checked into a repository rather than exported to an image, and who are willing to run a Node service or a Docker compose stack to get it. It also suits people who want the model to be a choice rather than a fixed vendor decision, because the app supports multiple providers and the README documents a server-side multi-model configuration plus an admin panel. It is not aimed at someone who wants a diagram once and never touches it again.

The feature list is broader than pure generation. Image-based diagram replication lets you upload an existing diagram or a photo and have the model reproduce it. PDF and text upload extracts content and builds a diagram from a document. Diagram history keeps versions so you can restore a state from before an AI edit. There is also an AI reasoning display for models that expose their thinking, which the README names as OpenAI o1/o3, Gemini and Claude.

## How the chat, the draw.io editor and the MCP server fit together

The architecture is a Next.js application that hosts both the chat panel and an embedded draw.io editor. The Dockerfile exposes a build argument named NEXT_PUBLIC_DRAWIO_BASE_URL, and its default is https://embed.diagrams.net, which tells you the editor is normally loaded as an embedded frame rather than bundled. If you want the editor to come from your own infrastructure, the docker-compose.yml shows the pattern: a jgraph/drawio container on port 8080, and the app built with NEXT_PUBLIC_DRAWIO_BASE_URL=http://localhost:8080.

That frame boundary is the core design decision. The AI side never renders a diagram itself. It produces diagram data, and the embedded editor is what displays and manipulates it. It also explains why diagram history can work at all: the app tracks changes to the diagram state and lets you restore a version from before the AI touched it, which is a different guarantee from an undo stack inside the editor frame.

A second entry point bypasses the browser UI entirely. The repository ships an MCP server under packages/mcp-server, published as @next-ai-drawio/mcp-server, so agents like Claude Desktop, Cursor and VS Code can drive diagram creation. The README's example prompt for that path is a flowchart of user authentication with login, MFA and session management, and it states that the diagram appears in your browser in real time. That is the most interesting part of the project for anyone already working inside an agent: the diagram becomes a tool call, not a separate tab you switch to.

Provider configuration is deliberately not hardcoded. The repository contains an env.example file, the README points to a provider configuration guide under docs/en/ai-providers.md, and there is a server-side multi-model configuration plus an admin panel whose settings persist to data/settings.json according to the docker-compose.yml comment. The demo site is sponsored and, per the README note, currently runs the glm-4.7 model, which is worth knowing because your self-hosted results will differ from the demo.

## Install Next AI Draw.io locally and generate a first diagram

The README gives a four-step local setup. You clone the repository, install dependencies, copy env.example to .env.local, and run the dev server.

```bash
git clone https://github.com/DayuanJiang/next-ai-draw-io
cd next-ai-draw-io
npm install
cp env.example .env.local
```

The copy step matters more than it looks. env.example is where the provider settings live, and the README sends you to docs/en/ai-providers.md for per-provider instructions rather than listing keys inline. Fill in at least one provider before starting, or the chat panel will have nothing to call.

```bash
npm run dev
```

The dev script in package.json is next dev --turbopack --port 6002, so the app listens on port 6002, not the usual 3000. The README says to open http://localhost:6002. Note that the production start script uses a different port: next start --port 6001.

If you would rather not manage Node and a draw.io instance separately, the repository includes a docker-compose.yml with two services and a named build argument for the editor URL.

```bash
docker compose up
```

That stack builds the app with NEXT_PUBLIC_DRAWIO_BASE_URL=http://localhost:8080, runs the app on port 3000, reads environment variables from a .env file, and mounts ./data into /app/data so admin panel settings survive a restart. The dependency on the drawio service is declared, so the editor container starts first.

Once the app is up, the first real use is a single prompt in the chat panel. The README's own examples are a reasonable starting point: ask for a RAG architecture diagram for a chat application, or an authentication flow using React with AWS in a serverless style. What you should see is the embedded draw.io editor populated with a diagram you can then edit by hand, plus an entry in the diagram history you can restore later. If you prefer to work from an agent, the MCP route is a one-liner in Claude Code:

```bash
claude mcp add drawio -- npx @next-ai-drawio/mcp-server@latest
```

After that, a prompt like "Create a flowchart showing user authentication with login, MFA, and session management" should push a diagram into the browser session.

## Where Next AI Draw.io stops being the right tool

The dependency on a language model is not incidental, it is the whole product, and that shapes the failure modes. A diagram request that the model misreads produces plausible-looking XML that is structurally wrong: boxes in the wrong order, connectors that imply a data flow your system does not have. The README's diagram history feature exists precisely because this happens, and the fact that the project advertises restoring a version from "before the AI editing" is an admission that AI edits are not always an improvement.

Cost and rate limits sit on the same axis. The README notes that the demo site has usage limits and that you can bring your own API key to bypass them, with the key stored locally in your browser and never on the server. Self-hosting moves the cost to you, which is fine for occasional diagram work and less fine if you want a team of thirty people generating diagrams all day against a frontier model.

The embedded editor is another boundary. Because the app loads draw.io as an embed, a self-hosted deployment that cannot reach the configured editor URL will show a chat panel that works and a canvas that does not. The Dockerfile default points at https://embed.diagrams.net, which means an air-gapped environment needs the jgraph/drawio container and the matching build argument, not just a firewall exception.

Finally, this is a web application with an Electron desktop build and multiple deploy targets, not a library. If what you actually want is a function you can call from your own service to turn a prompt into diagram XML, the repository layout does not advertise one; the MCP server is the closest thing to a programmatic interface, and it is designed around agent clients rather than a general API. Teams that need deterministic, template-driven diagram generation should look at generating draw.io XML directly instead.

## Next AI Draw.io against Mermaid and diagram-as-code tools

The honest comparison is not against another AI drawing app, it is against Mermaid and the diagram-as-code family. Mermaid takes a text grammar that a human writes and a renderer that turns it into a picture. Next AI Draw.io takes prose that a model interprets and an editor that turns it into editable draw.io data. The difference in approach shows up in three places.

Control: Mermaid output is deterministic. The same source renders the same diagram every time, which is why it works well in documentation pipelines and pull requests. Next AI Draw.io output varies with the model and the prompt, which is a feature when you are sketching an architecture you have not finalized and a liability when the diagram is a compliance artifact.

Representation: Mermaid's grammar is a constrained subset of diagram types. draw.io covers a much wider surface, including the cloud architecture shapes the README calls out for AWS, GCP and Azure, plus animated connectors. If your diagrams need vendor icons or precise layout, the draw.io side wins on expressiveness.

Workflow: Mermaid lives in a text file next to the code. Next AI Draw.io lives in a running application, with the MCP server as the bridge into an agent. If your team already reviews .mmd files in diffs, adding an AI layer does not remove the need for that review step; it just moves the authoring effort earlier.

There is also the plain draw.io answer. If your diagrams are simple enough that a person can place the boxes, the AI layer adds a provider key, a Node service and a failure mode without removing much work.

## Licence, releases and what maintenance actually looks like

The project is Apache-2.0, and the LICENSE file sits at the repository root. For most teams that is the permissive end of the spectrum: you can use it commercially, modify it and redistribute it, provided you keep the licence and notice files and state significant changes. Apache-2.0 also includes an explicit patent grant, which matters if you are embedding this in a product. Two caveats that are not legal advice but are worth flagging to whoever reviews the dependency: the repository is marked private in package.json, which affects publishing of the app package itself rather than your rights under the licence, and the README documents sponsorship arrangements with ByteDance Doubao and Atlas Cloud. Sponsorship affects which model the hosted demo uses, not the terms you get from the source.

On maintenance, the facts are these. The repository is not archived. The last push was on 2026-05-21, and the most recent release in the list is v0.4.16 on the same day, following v0.4.15 on 2026-04-14 and v0.4.14 on 2026-03-30. That is a steady cadence of patch-level releases through the spring, and then a gap. Four months of quiet is not abandonment, but it is also not the profile of a project shipping weekly, so plan your upgrade expectations accordingly.

The upgrade cost is dominated by the environment rather than the application code. Because provider configuration lives in .env.local and, in Docker, in a .env file read by compose, a version bump means re-checking your provider settings against the current env.example and the provider guide. The Dockerfile takes NEXT_PUBLIC_DRAWIO_BASE_URL, NEXT_PUBLIC_BASE_PATH and NEXT_PUBLIC_SELFHOSTED as build-time arguments, so a change to any of them is a rebuild, not a config reload. In a subdirectory deployment you also need NEXT_PUBLIC_BASE_PATH set consistently at build and runtime, which the compose file shows commented out for exactly this reason. The ./data volume is the one piece of state to back up, since it holds the admin panel settings.

## Conclusion

Adopt it if you already keep diagrams as draw.io files and want prompts, image uploads and PDF extraction to produce editable XML rather than a locked image. Skip it if you need a hosted, zero-setup tool with an SLA, or if your team does not want to manage provider keys and a draw.io instance. Verify first that your chosen provider works with the model name you configure, that the MCP server package resolves on your Node version, and that the ./data volume is writable before you rely on the admin panel settings.

## FAQ

### Is draw.io better than Lucid?

The repository does not compare the two. What it does show is why draw.io matters here: Next AI Draw.io produces draw.io diagram data and loads the editor as an embed, so the value of the tool depends on your team already working in draw.io rather than on a head-to-head feature comparison.

### Which is better, draw.io or Visio?

The project does not compare draw.io with Visio. The relevant fact for this project is that the Dockerfile defaults NEXT_PUBLIC_DRAWIO_BASE_URL to https://embed.diagrams.net, so a self-hosted deployment can point at a draw.io instance of its own rather than depending on a proprietary editor.

### How does draw.io make money?

The README does not describe draw.io's business model. It does describe how this project is funded: the README credits ByteDance Doubao and Atlas Cloud as sponsors, and notes that the hosted demo currently runs the glm-4.7 model because of that sponsorship.

### Which is the best AI to draw?

The README does not rank models. It shows that Next AI Draw.io is provider-agnostic: settings live in env.example with a guide at docs/en/ai-providers.md, there is a server-side multi-model configuration and an admin panel, and the README lists OpenAI o1/o3, Gemini and Claude as models whose reasoning can be displayed.

## Sources

- [Official documentation](https://next-ai-drawio.jiang.jp/)
- [Official README](https://github.com/DayuanJiang/next-ai-draw-io#readme)
- [Project repository](https://github.com/DayuanJiang/next-ai-draw-io)
- [Release notes](https://github.com/DayuanJiang/next-ai-draw-io/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dayuanjiang-next-ai-draw-io