RocketMQ Studio: Multi-Cluster Dashboard and Operations Console

RocketMQ Studio's Specific Management Scope

RocketMQ Studio addresses the operational gap between a RocketMQ cluster and the engineers who need to inspect and administer it. It is aimed at operators, developers, and administrators working with one or several RocketMQ environments. The repository presents the project as a unified platform for multi-cluster and multi-architecture deployments. Its scope is broader than a simple broker dashboard: the documented modules include instance management, cluster operations, Topic and Consumer Group CRUD, ACL permissions, message querying and tracing, dead letter queue handling, alerts, audit logs, and an AI assistant.

The intended audience should understand that Studio manages RocketMQ resources but does not replace the broker, NameServer, or Proxy deployment. The documented architecture keeps the console, backend, database, and RocketMQ services as separate concerns. The frontend is served on port 6789, while the Spring Boot backend listens on port 8888. This separation matters for teams that already run RocketMQ in a particular network or deployment model and only need a management surface.

The README also describes two instance access modes, Proxy and Direct. That choice affects how Studio reaches a cluster, so an adoption decision should include a review of network routing, credentials, TLS, and the permissions available to the connection. A dashboard can expose operational actions such as resending dead letter messages, resetting offsets, changing hot configuration, and disabling users. Those actions require controls and audit review rather than a visual-only monitoring deployment.

Docker Compose Startup and First Console Access

The documented local path uses Docker Compose from the repository root. The compose file is not shown in the repository entries, so the README is the source for the exact commands and ports. The first command creates an external network that the compose files attach to. The second command builds and starts Studio with its MySQL database and `rocketmq-web` service.

Run the shared network creation from the repository root:

docker network create rocketmq_net

The README says to ignore an error if the network already exists. Then build and start Studio:

docker compose -f deploy/docker-compose.yml up -d --build

The next documented step is to open `http://127.0.0.1:6789`. The README states that this starts Studio and its own MySQL database, which is enough to open the console, log in, and explore the interface. It does not start a RocketMQ cluster. The reader should therefore expect an empty management environment until an instance is registered or the optional demo cluster is started.

Studio exposes the frontend through Nginx on port 6789 and the backend through Spring Boot on port 8888. A successful first run should show the console loading on port 6789 and should not be confused with a message broker becoming available. The README does not document a standalone Maven or Gradle startup procedure, so the Docker Compose path is the confirmed tutorial here.

Optional Demo Cluster Connectivity

For a first real use, the repository provides an optional bundled RocketMQ deployment. It includes a NameServer, two brokers, a Proxy, a producer and consumer load generator, and Prometheus. This gives a new user a cluster to register, but it also adds moving parts that are not present in the base Studio deployment.

Start the demo cluster before starting Studio, as the README directs:

docker compose -f deploy/rocketmq/docker-compose.yml up -d

Check its container state with:

docker compose -f deploy/rocketmq/docker-compose.yml ps

The README says to wait until the `ps` output is healthy. Studio reaches this cluster at `nameserver:9876` over the shared `rocketmq_net` network, and the backend default uses that address. The demo cluster exposes NameServer port 9876, Broker port 10911, Proxy Remoting port 8080, and Proxy gRPC port 8081. These ports belong to the demo environment and should not be treated as production requirements.

The demo is useful for checking instance registration and basic resource visibility, but the README does not claim that it reproduces production traffic, failure conditions, authentication setup, or capacity behavior. Teams evaluating Studio should compare the demo's broker and Proxy arrangement with their own RocketMQ topology before drawing operational conclusions.

Authentication, Data Storage, and Shared Environment Setup

The base deployment can be opened without login protection, which is convenient for local exploration but inappropriate as a default assumption for a shared environment. The documented configuration path is to copy `deploy/.env.example` to `deploy/.env`, set `STUDIO_AUTH_LOGIN_REQUIRED=true`, and configure `STUDIO_AUTH_ADMIN_USERNAME` and `STUDIO_AUTH_ADMIN_PASSWORD`.

The configured account is a bootstrap seed. According to the README, the first login against an empty database creates configured users in `rmq_studio_user`. After that, the database becomes the source of truth. Administrators can then create users, enable or disable accounts, and reset passwords through the user-management page. Browser sessions use an `HttpOnly` session cookie, while API clients can request a bearer token explicitly.

The database schema is not populated with instances, Topics, consumer groups, or ACL records by default. The repository includes development-only loaders under `deploy/mysql/`, with `upgrade-demo-instance.sql` and `upgrade-demo-acl.sql` documented as the files to import in that order. The README explicitly says they are sample-data loaders, not upgrade migrations, and should never be used in a production database. That warning makes the distinction between initial schema creation, demonstration data, and production migration management important.

Monitoring and Administration Workflows

The documented feature set gives operators several ways to move from observation to action. The Dashboard module presents global statistics for clusters, brokers, Topics, and consumer groups, including TPS trends. The Clusters module covers Broker, NameServer, and Proxy node operations, hot configuration updates, and NameServer configuration drift detection. These are administration features, not merely charts.

Topic management supports CRUD, route viewing, consumer lists, and Normal, FIFO, Delay, Transaction, and Lite message types. Consumer Group management includes consumption progress, subscription details, offset resets, and configuration import and export. The README specifically describes a group view that exposes subscription mode, online clients, total lag, consumption delay, per-Topic subscription consistency, and filter expressions.

Message operations include searching by Topic, Message Key, or Message ID within a time range. A result can be inspected, traced, verified, or downloaded as a single message. The Dead Letter Queue module supports viewing and batch resend. Alerts cover disk, lag, TPS, and node-offline conditions, with DingTalk, email, and SMS notifications. Audit Logs can be filtered by type, time, and result, with history cleanup available. These capabilities fit a team that manages ongoing service operations, but each action needs an explicit authorization decision because the console can change messaging state rather than only display it.

AI Assistant and rmqctl Integration

RocketMQ Studio includes an AI assistant with several documented modes: query, diagnose, manage, and general. The README says that Studio hosts a general-purpose agent CLI, including Claude Code or Qoder, or a plain OpenAI-compatible HTTP engine. The project does not describe itself as implementing its own tool-calling loop.

RocketMQ capabilities reach the agent through `rmqctl`, a Go CLI located in the repository. It runs as an MCP stdio server and calls back into Studio's own MCP endpoint. The same signed, instance-scoped, risk-gated tool surface is available to the hosted agent, a developer using commands such as `rmqctl topic list`, and an external agent configured from `rmqctl mcp config`. The Dashboard screenshot also describes model selection, MCP tool calls, server-side conversation history, and visible chain of thought.

This design is an alternative to adding RocketMQ operations directly to a model provider's API. It keeps the bridge in the repository and routes tool access through Studio. The README does not document the complete configuration syntax for external agents, model credentials, or every available tool, so those details must be checked in `docs/ai-ag` and the `rmqctl/` directory before relying on the AI path. The use of visible chain of thought also deserves an explicit privacy and retention review when conversations contain operational or message-related data.

License, Maintenance, and Upgrade Boundaries

The repository is licensed under `Apache-2.0`. That identifies the stated license for the project, but this review does not interpret licensing or provide legal advice. Users should still check the repository `LICENSE` and `NOTICE` files for the terms and notices that apply to their distribution, modifications, and deployment.

The repository is not archived, and the last push was on 2026-10-15. Recent releases listed for the project are `v3.0.0-preview` on 2026-09-23, `rocketmq-dashboard-2.1.0` on 2025-08-01, and `rocketmq-dashboard-2.0.0` on 2024-09-18. The release labels indicate a moving project with both stable-numbered releases and a preview release. The README does not provide a compatibility matrix between Studio versions and RocketMQ versions, nor does it describe a rollback procedure for a database or console upgrade.

The upgrade path therefore has a practical limitation: the repository names releases, but the README does not explain how existing Studio schemas, users, instances, or demo data should be migrated. The sample SQL files must not be mistaken for migrations. Before upgrading a deployed console, an operator should inspect the relevant release notes and deployment files, back up MySQL, and confirm the supported RocketMQ connection mode rather than relying on the release number alone.

Editorial conclusion

RocketMQ Studio fits operators who need a unified console for RocketMQ instances, topics, consumer groups, ACLs, message queries, dead letter queues, and operational monitoring. It is a poor fit for production use until the team connects its own RocketMQ deployment, reviews authentication settings, and verifies the permissions and resource limits required by its clusters. The first checks should be the Docker Compose services on ports 6789 and 8888, the registered RocketMQ instance, and the account configuration in `deploy/.env`.

Frequently asked questions

Official sources

1. apache/rocketmq-dashboard on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases