DataRoom: a Vue and Spring Boot designer for dashboards and big-screen displays

What DataRoom is, in the terms the project uses

DataRoom is described as a simple, free, open source designer for large screens and pages that supports generating them through AI conversation. The repository description is a compressed version of the same claim: conversational generation of screens and pages, an integrated front end and back end solution, dozens of chart types, support for more than twenty data sources, aimed at large-screen, low-code and BI scenarios.

The stack is stated in full. The back end is Spring Boot 3.x on JDK 17, the front end is Vue 3.x with Vite 8.x, Element Plus and ECharts 6.x. The top-level layout follows that split, with dataRoomServer/ for the Java service, dataRoomFront/ for the Vue application, dataRoom-script-api/ for the scripting API, plus scripts/, skills/, doc/ and a Dockerfile at the root.

The workflow the project describes is a single chain. Data source connection, then data cleaning and processing, then screen or page design, then preview, then publication. That ordering is the product's pitch: it is not a chart component you embed, it is the whole path from a database to a published dashboard with access control.

The feature list covers the operational parts as well as the visual ones. There is user, role, permission and log management, page publishing with sharing and IP plus expiry-time control, and component interaction events such as show or hide, page navigation, data refresh, variable updates and high-code execution, along with timed refresh. There is a separate section on system integration, describing configuration-based single sign-on with the RuoYi framework, with the note that other frameworks can be extended.

The licensing is Apache License 2.0, and the code is hosted on Gitee, GitHub and AtomGit at once, which is a practical detail for a project of this kind: the Gitee presence is where the community and the issue tracker live, and the README's registration link for companies points at Gitee.

Data sources: the breadth is the feature

The data source support is where the project spends the most words, and the README lists the same set twice, once in the overview and once in the data source section.

The relational databases named are MySQL, PostgreSQL, Oracle, SQLServer, Doris, Dameng, DB2, GBase, PolarDB, H2, GoldenDB, MariaDB, OceanBase, Hive, TDengine, TiDB and StarRocks. The document stores are MongoDB and Elasticsearch. Then there is the streaming and messaging side with MQTT, and the file formats with Excel and CSV.

The mix of names tells you something about the audience. Several of these are Chinese enterprise databases, Dameng, GBase, GoldenDB and Kingbase among them, and the presence of Apache Doris, StarRocks, TDengine and Clickhouse points at the analytical database market rather than the transactional one. The list is the list of what a state or enterprise data team in that region actually runs.

Above the raw connections sits a data set layer. The README describes support for several kinds of data set, JSON, HTTP, SQL, Excel and CSV, Elasticsearch and WebSocket, which sit between the connection and the screen. That intermediate step is what turns a list of twenty connections into a reusable abstraction, since a screen binds to a data set rather than to a driver.

Real-time data sets are supported through MQTT and WebSocket, and the README explicitly frames that as suited to Internet of Things scenarios.

On the credential side, the README states that passwords are stored with asymmetric encryption, which is a reasonable choice for a system that holds a connection string to every database in the estate. The open API surface is described as standard RESTful with Open API 3.x, which is what you need if the dashboards are going to be consumed by something other than a browser.

Two designers, and why the layout differs

The README documents two distinct design surfaces, and the difference between them is not cosmetic.

The screen designer for large displays uses absolute positioning, with flexible design. Its listed capabilities are a ruler, canvas zoom, canvas dragging, layer management, multi-select, alignment, grouping and ungrouping, history with rollback, undo and redo, timed refresh and component interaction. This is the tool for a wall display where you place a chart exactly where you want it.

The page designer uses a grid layout and adapts to the page size, which the README ties to low-code scenarios. Its listed capabilities are history with rollback, undo and redo, timed refresh and component interaction. A grid is what you want for something that will be viewed in a browser at an unknown size, and it is the constraint that makes a page designer different from a screen designer rather than a smaller version of it.

Both are backed by a page management section that uses a directory tree, and supports creating, designing, previewing and publishing both screens and dashboards.

The asset library is the other substantial part of the front end. It supports directory tree management and the import and preview of images, video and 3D models, and it has storage extensions covering local storage, MFS, MinIO, RustFS and Ceph, all of which speak the S3 protocol. Built-in assets cover backgrounds, icons, borders, titles and decoration, and the README notes they come from the network and remain the copyright of their original authors, for study and research use only.

There is also a map management section for importing, previewing and automatically resolving regions, which is a specific capability that general dashboard tools usually leave to a separate component.

AI generation through SKILL, MCP and conversation

The AI capability is the feature the README leads the screenshots with, and it is described in a few different ways that are worth separating.

The overview says the system supports AI capabilities, creating screens and pages through conversation via SKILL and MCP. The screenshots section says it supports creating screens and pages through the MCP protocol, connecting AI tools through conversation. And there is a separate MCP protocol section describing the ability to expose the MCP protocol externally so that AI tools can connect to it, with a screenshot page for the AI generation integration.

So there are two directions. The project can consume an AI tool to create a screen, and it can be driven by an AI tool through MCP. The example in the README shows the effect of a first generation, with the original prompt given as a request to use MCP to create a 618 monitoring screen, followed by the resulting screen.

The top-level skills/ directory in the repository is consistent with the SKILL half of that. It sits alongside dataRoom-script-api/, which is the scripting API used for component interaction events including the high-code event type.

What to note is that the AI path is a generation path, not a query path. The README describes using it to create screens and pages. There is no claim about asking questions of your data through the same interface, and the chart types and the data set layer are still the mechanism through which data reaches a screen.

The repository's own position on generated contributions is worth checking before you plan around it, since a project with an AI integration feature may have opinions about AI-generated pull requests.

Deployment: the Docker image and what it does not cover

The Docker section is short, and the constraint is stated before the command:

docker run -d --name dataroom -p 8081:8081 gcpaas/dataroom:latest

The note above it says that the access address, username and password are in the user manual, and that only linux/arm64 systems and architectures are supported. That is a narrow constraint. The published image targets arm64 Linux, so on an x86 server you are building the image yourself.

The Dockerfile explains the shape of the artifact. It is a two-stage build. The first stage is based on eclipse-temurin:17-jdk and is called release-unpack, and it copies a RELEASE/dataRoom-*.zip into /opt/gcpaas, picks the most recent zip with a shell command, tests that it is non-empty, and extracts it with jar. The second stage is eclipse-temurin:17-jre, which copies the unpacked dataRoom directory from the first stage, sets the working directory, sets an environment variable RUN_ENV to docker, and runs the server jar with a fixed timezone of GMT+8.

Two details in that are worth noting. The image does not build the application; it expects a prebuilt release zip to be present, which means the image is an unpack-and-run wrapper around a build artefact rather than a reproducible build from source. And the timezone is fixed in the entrypoint rather than being a container setting, which is a small thing that will surprise you if you deploy outside that timezone and the application stores timestamps.

The build files confirm the Java side. There is a pom.xml at the root with mvnw and mvnw.cmd wrappers, so the server is built with Maven.

The open source and commercial split, and where the documentation lives

The section the README marks as a special note is the one to read first.

It states that the project code is fully open source, and that a demo environment is not currently provided. It also states that there is a commercial version, that you can register with an email address and that the password is sent to that address, and that the commercial version's feature introduction and pricing are on a separate page.

So the shape is open code with a hosted commercial product alongside it, and the free path does not come with a hosted instance to try. That is a materially different proposition from an open source project you can evaluate on a demo site, and it matters for anyone who wants to see the product before committing to deploying it.

The documentation has a similar shape. The user manual is on Yuque, and the README says the manual password is in the QQ group announcements. The group section repeats the pattern: questions about the manual, the documentation password, deployment packages and usage go to the QQ groups, with eight group numbers listed and a group verification password.

For a Chinese-language project that is an entirely normal arrangement. The manual is where the operational detail lives, the access credentials and the password are shared with the community, and the commercial product has its own documentation. What it means for an evaluator is that the README you can read is the feature list and the technical shape, and everything else is behind either a group membership or the commercial product.

The changelog is linked for version differences, feature changes and security changes, and there is a CONTRIBUTING.md at the root. The last push to the repository was on 2026-10-22, and the only tagged release is 3.0.0 from 2026-06-24.

DataRoom against a hand-built dashboard stack and against an established BI platform

Two comparisons make the choice clearer.

The first is against building a dashboard stack yourself. The usual components are a Java or Node back end with a query layer, a charting library such as ECharts or a BI library, a layout engine to place the charts, an authentication and permission system, and a publishing mechanism. Assembling that is a project of its own, and the parts that are hardest are rarely the charts. They are the permission model that decides which rows of which table a given user can see, the publishing step that turns a designed screen into a link with an expiry, and the audit log that records who changed what. The README's feature list puts all three of those in scope, and that is where the value of an integrated product lies over a charting library.

The second is against an established BI platform. The difference in approach is where the data lives. A BI platform expects the data in its own warehouse, with an ETL layer feeding it, and the dashboard queries that warehouse. DataRoom connects to the operational databases directly, with the data set layer sitting on top of a live connection. That is faster to stand up, because there is no data pipeline to build, and it is riskier, because a dashboard that queries a live production table can be slow and can affect the source system.

The screen designer is also a category of its own. A BI tool produces charts and tables for people to read on a laptop. A large-screen display is built to be watched from across a room, with a fixed aspect ratio, large type and a designed composition. That is a different design problem, and the absolute positioning model with rulers, layers and grouping is the tool for it.

The deciding factor is the data source list. If your estate runs the databases this project names and you want live dashboards over them, the connection breadth is the argument for it. If your data is already in a warehouse and your users need drill-down and slicing, a BI platform does that better.

Editorial conclusion

Adopt DataRoom when you need to build operational dashboards and large-screen displays in front of a wide range of databases, and want a designer with preview, publishing and per-screen access control rather than a charting library you wire up yourself. Do not adopt it if you need the whole feature set for free today, since the README says the open code currently comes without a demo environment and that a commercial version exists separately. Verify first that your database is on the supported list, that the deployment target is linux/arm64 if you use the provided image, and that the manual you need is reachable, because the documentation password is distributed through the community group rather than published.

Frequently asked questions

Official sources

1. gcpaas/DataRoom on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases