hawtio: A Web Console for JVM Management

What hawtio solves for Java application teams

hawtio addresses the need to inspect and manage Java applications through a browser rather than by giving every operator direct access to JVM internals. It is intended for developers, application teams, and operators who need a web interface for supported JVM management functions. The console is modular. The README identifies plugins for Apache Camel and JMX, while it says that plugins for Logs, Spring Boot, and Quartz will be provided soon.

That plugin boundary is central to evaluating the project. Hawtio is not documented as a complete administration suite for every Java framework or every JVM subsystem. Its useful features depend on the plugins present in the installation, the management interface exposed by the target application, and the connectivity between the console and Jolokia. Custom plugins are also supported, so an application team can add functionality that is not included in the core project.

The repository includes examples related to Camel, Keycloak, observability, security, logging, and plugin development. Those directories show areas covered by examples, but they do not by themselves establish production support for every example. The project is best evaluated as an extensible console whose scope is determined by integrations.

Jolokia connection and modular architecture

The central server-side dependency is Jolokia, which the README describes as having a footprint of around 300KB. Jolokia can run as a JVM agent or be embedded as a servlet inside `hawtio-default.war`. This gives Hawtio two practical deployment shapes. A standalone console can connect to a remote Jolokia endpoint, while an application can package the servlet and expose Hawtio through its own runtime.

The browser-side application contains static HTML, CSS, JavaScript, and images. Plugins add application-specific views and operations. Jolokia is the bridge between the browser console and JVM management data, so the console depends on a reachable endpoint and on the target JVM exposing the relevant management facilities.

The repository layout reflects this modular design. It includes `console`, `console-minimal`, `plugins`, `hawtio-war`, `hawtio-war-minimal`, `platforms`, `hawtio-jbang`, and `hawtio-system`. That spread of artifacts means Hawtio is not simply one executable file. A deployment may involve the console, a platform integration, plugins, and either an embedded or remote Jolokia endpoint. The README does not document authentication, authorization, TLS, proxy configuration, or audit logging for the console, so those points require verification in the relevant deployment documentation.

Install and start hawtio with JBang

The shortest documented first use is the JBang route. Install JBang from the project's documented download page, then install the Hawtio application and display its command help. The first command installs the application through JBang, and the second invokes the resulting `hawtio` command.

jbang app install hawtio@hawtio/hawtio
hawtio --help

To connect directly to a remote Java application, pass a named Jolokia URL with `--connection` or `-n`. Hawtio attempts the connection at startup. The documented example targets a local Jolokia endpoint.

hawtio --connection=myconn=http://localhost:8778/jolokia/

If the Connect plugin has stored a named endpoint in browser local storage, the same name can be used without repeating the URL.

hawtio --connection=myconn

The README also documents multiple named connections. Each connection opens a separate browser tab, with one tab associated with each JVM. This is convenient for operating several processes, but the operator must keep track of the named endpoints and understand that the cached connection information is stored in the browser.

Integrating hawtio with Spring Boot 3.x

The README says Hawtio v4 supports Spring Boot 3.x. To attach the console to a Spring Boot application, add `hawtio-springboot` to the Maven dependencies. The documented version is `5.3.0`.

<dependency>
  <groupId>io.hawt</groupId>
  <artifactId>hawtio-springboot</artifactId>
  <version>5.3.0</version>
</dependency>

The integration also requires exposing the Hawtio and Jolokia actuator endpoints and enabling JMX in `application.properties`.

management.endpoints.web.exposure.include=hawtio,jolokia
spring.jmx.enabled=true

After adding the dependency and properties, run the application with the documented Maven goal. The README says that opening the local actuator URL should show the Hawtio console.

mvn spring-boot:run

The console is then available at `http://localhost:8080/actuator/hawtio`. This route is appropriate when Hawtio should share the application's lifecycle and endpoint configuration. It also makes the framework integration part of the application build, so changing Hawtio versions can require checking Spring Boot compatibility and the related plugin artifacts.

Integrating hawtio with Quarkus 3.x

The README also says that Hawtio v4 supports Quarkus 3.x. The Quarkus integration uses the `hawtio-quarkus` artifact at the documented version `5.3.0`.

<dependency>
  <groupId>io.hawt</groupId>
  <artifactId>hawtio-quarkus</artifactId>
  <version>5.3.0</version>
</dependency>

Start Quarkus in development mode with the documented Maven command.

mvn compile quarkus:dev

The README says that `http://localhost:8080/hawtio` should display the console. Unlike the Spring Boot example, this documented setup does not show an additional application-properties block. The Quarkus artifact and runtime integration therefore provide the project-specific attachment shown in the README.

The main trade-off is lifecycle coupling. Embedded integration can be convenient for development and for an application that already has an appropriate management endpoint. It also requires checking the framework version, application configuration, plugin set, and exposure of the resulting URL. A standalone CLI deployment may fit better when the console should not be packaged inside the application.

Where plugin coverage and endpoint controls limit adoption

Hawtio is the wrong tool when a team expects one console to cover every operational task across a heterogeneous Java estate. The README names Apache Camel and JMX as available plugins and describes several future plugins. It does not state that all plugins have identical version support, release cadence, or operational behavior.

The README also provides no configuration guidance for authentication, authorization, TLS, audit logging, or network restrictions on the console. This does not mean those features are absent from every deployment. It means the README does not establish them, so an adoption decision cannot treat the management URL as safe merely because the application is running locally. A Jolokia endpoint exposes JVM management operations to whatever can reach it.

Plugin-based design also creates a support boundary. If a required view or operation is missing, adding it may require a custom plugin or a separate management solution. The repository's examples can help identify possible integrations, but the project documentation does not turn every example into a general compatibility promise. Teams should compare their actual management requirements with the documented plugin list before selecting Hawtio.

Maintenance, releases, and license implications

The repository is not archived, and the last push was on 2026-10-13. Recent releases include `hawtio-5.3.0` on 2026-09-08, `hawtio-5.2.1` on 2026-06-08, and `hawtio-5.2.0` on 2026-05-20. These are signs of recent project activity, but release dates alone do not guarantee compatibility with every plugin, framework, or application.

Hawtio is licensed under Apache License, Version 2.0. The repository's `LICENSE.txt` contains the governing terms, while `NOTICE.txt` and `RELEASING.md` provide related project files. This review does not interpret the license or give legal advice.

Because the repository contains separate console, platform, WAR, JBang, system, and plugin modules, an upgrade may involve more than changing one application property. The README identifies Spring Boot 3.x and Quarkus 3.x as supported in Hawtio v4 and uses version `5.3.0` in its examples. Before upgrading, check the target version's `CHANGES.md`, Maven dependencies, framework requirements, plugin artifacts, and endpoint configuration. The repository also contains test and end-to-end test workflow files, but the README does not state that these checks guarantee support for every external integration.

Editorial conclusion

Adopt hawtio when you need a browser-based console for supported JVM management features and can control access to Jolokia endpoints. Do not choose it as a complete administration platform without checking plugin coverage for your application. Verify the supported framework version, required plugins, endpoint protections, and deployment behavior before exposing the console beyond a trusted environment.

Frequently asked questions

Official sources

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