Apache Pulsar Manager: a retired admin GUI and what replaces it

The project has been retired by the Apache Pulsar project

The README opens with a warning block, and its content is the single most important fact about this repository. Apache Pulsar Manager is no longer maintained, and using it is not recommended. The description of the repository says the same thing in its first words, that it is a no longer maintained project, and the repository's topics are `deprecated` and `unmaintained`.

The project status section gives the specifics rather than leaving them implied. Pulsar Manager is no longer maintained by the Apache Pulsar project. It will not receive new releases, bug fixes or updates for newer Pulsar versions, and its documentation has been removed from the current Pulsar documentation.

That last clause has a practical consequence beyond the missing manual. Pulsar Manager is a tool that talks to brokers and bookies across a cluster, and the cluster's own administration surface changes between versions. A tool that is not updated for newer Pulsar versions is not just missing features, it is a component whose assumptions about the cluster it administers are no longer guaranteed to hold.

The README is direct about who should read it. We do not recommend using Pulsar Manager for new deployments. If you are running it today, plan to move to an alternative solution and remove the Pulsar Manager deployment. If you deployed it with the Apache Pulsar Helm chart, disable the `pulsar_manager` component, which is already disabled by default in current chart versions.

The repository itself is not archived. The last push to the tree was on 2026-09-29, and the topic list carries the deprecation labels, so the tree is being touched, most likely for housekeeping, while the releases tell the same story: v0.5.0-candidate-1 on 2025-01-15, and before that v0.4.0 on 2023-05-12 with v0.4.0-candidate-2 a week earlier. No version has shipped in the ordinary sense for a long time, and the most recent tag is a release candidate.

What Pulsar Manager was: a frontend and a backend service

The section titled what Pulsar Manager was gives the architecture, and it is worth reading carefully because it explains what a replacement has to cover.

Pulsar Manager was a web-based GUI for managing and monitoring Apache Pulsar clusters. It consisted of a frontend web application and a backend service that connected to the brokers and bookies of one or more Pulsar clusters. So it was not a single process, and it was not a plugin inside the broker. It was a separate web application with its own backend, and the backend held the connection to the cluster.

That architecture explains the resource management surface in the repository. There is a `front-end/` directory and a `src/` directory, which are the two halves of that split, plus a `distribution/` directory for the packaged artefacts and a `docker/` directory for the container build. The project is built with Gradle, with `build.gradle`, `settings.gradle`, `gradle.properties` and the `gradlew` wrapper scripts checked in, and the `Jenkinsfile` alongside `.asf.yaml` mark it as an Apache Software Foundation project with the standard release tooling.

The primary language recorded for the repository is Vue, which tells you the frontend was a Vue application, and the `front-end/` directory at the top level is where that code lives.

For a team planning a migration, the practical reading of this structure is that a replacement is not just a different web page. Whatever you move to has to reach the brokers and the bookies of the cluster, hold administrative credentials to do it, and present a UI over it. Anything you pick has to speak the same admin API the brokers expose, and it has to hold whatever permissions it needs to issue those operations.

The views it offered, and why each one needs a replacement

The README lists the views Pulsar Manager provided: tenants, namespaces, topics, subscriptions, clusters and brokers, and a way to issue admin operations from the browser.

That list is a checklist for whoever replaces it, and each item corresponds to a distinct part of the Pulsar administrative model.

Tenants are the top level of the resource hierarchy. Namespaces sit inside tenants and are where policies live: quotas, retention, bundles, and the settings that decide how data is handled. Topics are the actual streams, and subscriptions are the consumers attached to them, with cursor positions, types and backlog state. Clusters and brokers are the physical layer, and monitoring them means looking at the state of the nodes, their resources and their health.

Admin operations from the browser is the part that is easy to overlook and the part that matters most for migration. Creating a namespace, changing a quota, terminating a topic or inspecting a subscription backlog are all write operations against a live cluster, and an administration UI is a much more dangerous thing to expose than a read-only dashboard. Whatever replaces Pulsar Manager should be reviewed for exactly that reason, and the project itself does not document the permission model it used, so that review cannot be done from this repository.

Monitoring was the other half of the description. A management GUI for a streaming system is where you go when something is not consuming, when a backlog is growing, or when a broker has been evicted, and the replacement has to answer those questions too, not only perform mutations.

Leaving cleanly: the Helm chart path and the removal path

The README gives a specific instruction for the most common deployment route, and it is worth following exactly.

If you deployed Pulsar Manager with the Apache Pulsar Helm chart, disable the `pulsar_manager` component. The README notes that this component is already disabled by default in current chart versions, which means the default path into a current chart is one where you have nothing to remove, and the people who need to act are the ones who deployed earlier and carried the setting forward.

That is the whole removal guidance, and it is deliberately thin. There is no deprecation timeline, no migration wizard and no compatibility statement, because the project is not being transitioned, it is being retired.

The other instruction is about the deployment rather than the chart. If you are running it today, plan to move to an alternative solution and remove the Pulsar Manager deployment. Removing rather than leaving it running is the right reading, since an unmaintained admin interface holding cluster credentials is an attack surface with no one patching it.

For a standalone deployment, the shape of the container and distribution assets in the repository is what you would have deployed, so those are the pieces to remove from your orchestration and from your secrets and credential stores.

Two other repository entries matter for a decommissioning pass. There is a `SECURITY.md` at the root, and the Apache community channels are named in the README as the place to ask questions about managing Pulsar, at pulsar.apache.org/community/. For a retirement, the security contact and the community channel are the two addresses worth having, because the first covers reports about anything still running in the wild and the second covers the handover of knowledge about the deployment you are tearing down.

Where to look instead, and what the alternatives page has to answer

Every pointer in the README leads to the same place. The warning block links to the Administration UI documentation, the alternatives section says to go to the Administration UI documentation for alternative solutions for managing Apache Pulsar, and the homepage of the repository is the same URL at pulsar.apache.org/docs/administration-ui.

That single destination is the whole of the project's guidance for replacement, and the README does not name any specific alternative product. This is a deliberate choice worth noting: the Apache Pulsar project is pointing at a documentation page rather than endorsing a replacement, so the choice is left to you, and the burden of the evaluation is on the reader.

That places a specific set of questions on whoever does the selection. Does the candidate cover tenants, namespaces, topics, subscriptions, clusters and brokers, the full list of views Pulsar Manager had? Does it issue the same admin operations, or a subset? Does it need its own backend service with broker and bookie access, or is it a thinner client? Does it work against the Pulsar version you actually run, given that this project stopped being updated for newer versions and a replacement may be more current, or may lag in a different way? And what is its permission and authentication model, since the old one's is not documented here.

The project also stops contributing community support. Issues and pull requests for Pulsar Manager are no longer accepted, and the source code stays available in the repository for reference, but it is not maintained. The Apache Pulsar community channels are named for questions about managing Pulsar, so support for the replacement question belongs there, not in this repository's issue tracker.

Licence, repository state and what the remaining tree is good for

The licence is settled and simple. Pulsar Manager is licensed under the Apache License, Version 2.0, with the LICENSE file in the repository root, and the repository's own licence field records Apache-2.0. The copyright and patent grant and the requirement to include the notice and the licence text all come with it, and for a retired internal deployment none of that changes.

What remains in the tree is still worth having, in a limited way. The source code stays available for reference, and the repository contains a `docs/` directory, a `CONTRIBUTING.md` and the Gradle build. For a team that built internal tooling on top of Pulsar Manager, the reference value is real, and the Apache 2.0 licence permits reading it, modifying it and redistributing it. A fork maintained in house is a legitimate option, and it is the one that comes with the whole cost of maintaining a Vue frontend and a backend service against a cluster API that moves.

The remaining top level entries describe that scope: `src/`, `front-end/`, `distribution/`, `docker/`, `docs/`, `gradle/`, `gradle.properties`, `build.gradle`, `settings.gradle`, the Gradle wrapper, the `Jenkinsfile`, `.asf.yaml` and `SECURITY.md`.

The maintenance picture for planning purposes is settled. The last push to the tree was on 2026-09-29, the repository is not archived, the topics are `deprecated` and `unmaintained`, the newest tag is the v0.5.0 candidate from 2025-01-15, and the documentation has been removed from the current Pulsar documentation. A tool in that state is not going to receive a fix for a broker that changed its API, and the README says not to build on it.

Editorial conclusion

Adopt nothing here. Apache Pulsar Manager is retired by the Apache Pulsar project and the README says plainly that using it is not recommended and that it will not receive new releases, bug fixes or updates for newer Pulsar versions, so a new deployment on it would start life already unsupported. If you are running it today, the concrete next step is to pick a replacement from the Administration UI documentation at pulsar.apache.org/docs/administration-ui, and if you deployed it with the Apache Pulsar Helm chart, disable the `pulsar_manager` component, which is already disabled by default in current chart versions.

Frequently asked questions

Official sources

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