ES-King: a desktop Elasticsearch client built with Wails and Vue

A Wails shell over the Elasticsearch REST API

ES-King is a desktop client for Elasticsearch, written as a Vue front end inside a Wails application, with the default branch named wails and the app sources under app. The communication model is the first thing to understand: the client talks to the cluster over the REST API, and the README states that in practice there are generally no Elasticsearch version compatibility problems as a result. That is a direct consequence of using the HTTP interface rather than the Java transport client, and it means the same binary works against clusters of different vintages without a matching client library. The same design decision has a second effect that is easy to miss: anything the REST API exposes is reachable from the GUI, and anything it does not expose will not be in the GUI either. The project is Apache-2.0 licensed, and its stated ambition is a modern, practical, lightweight client whose install package stays under 10MB, adapted to the major desktop systems except Windows 7.

Cluster and node metrics, gathered in one dashboard view

The monitoring half of the client is a wide surface rather than a single health check. The README lists node level detail including the node list, roles, heap memory usage, total memory usage, CPU usage, disk space, network traffic and five minute load. It also lists node level cache statistics for field data, segments, query cache and request cache, plus a segment count. Shard metrics are summarised separately: total active shards, shards initialising, unassigned shards, delayed allocation shards and the percentage of active shards. The value here is not any single number but the density, since an operator checking whether a node is healthy usually has to open several APIs and reconcile them. The documentation for the project is generated and published at the zread.ai page linked from the README, and the README labels it as AI generated, so treat the prose there as a starting point for the API surface rather than an authoritative specification.

Index lifecycle, reindex and bulk import in one window

Index management covers the operations that normally mean a series of API calls. You can search for indices and manage aliases, including adding an alias with a Filter or Routing and removing it, and you can export index contents to CSV. The lifecycle actions listed are creating an index, deleting it, opening and closing it, Flush, Refresh, clearing caches and Force Merge for segment merging. Mappings and Settings can be viewed online and updated dynamically. For data movement there are two named paths: reindex based on the Reindex API for asynchronous copying and migration, and backup, which filters index data by DSL and downloads it locally as a JSON file. The document view mirrors that breadth, with paged browsing by query DSL, sorting and quick field filtering, single document viewing, online JSON editing and deletion, batch deletion through _delete_by_query, and bulk import and _bulk writes from local JSON or CSV files. Field analysis adds a top values distribution and a cardinality statistic for a chosen field.

Allocation Explain turns a red shard into a diagnosis

The diagnostics section is where this client earns its keep for on-call engineers. It shows the full shard list with status, the reason a shard is unassigned and the node it lives on, and it offers a one click Allocation Explain that goes deep into why a shard is unassigned or cannot be moved, with a pointer to the official guidance. Alongside that are live thread pool views for general, search and write pools, showing active threads, queued work and rejections, a hot threads view that captures and displays the stack of the node's busiest threads, and a pending tasks view for tasks queued or blocked on the master node. Thread pool rejections and hot threads are exactly the signals that point at a slow query or a memory pressure problem before a node leaves the cluster. None of these are inventions of the client, they are existing Elasticsearch APIs with a table in front of them, and the value is the presentation plus the ability to move from symptom to explanation in a couple of clicks.

Snapshot repositories, SLM schedules and index templates

Backup management is treated as a first class feature. The repository manager creates, verifies and deletes snapshot repositories across several storage types, listed as fs, s3, hdfs, azure and gcs. Snapshot operations cover creating a snapshot, filtering which indices it contains, and restoring, with support for renaming indices during restore, restoring global state and watching progress in real time. On top of that sits the SLM automated backup policy, where you configure a Cron schedule, a naming template for time based names, and automatic retention or cleanup of expired snapshots. Templates are managed in the same place: index templates and component templates can be viewed, created, edited and deleted, and an index can be created in one step from an existing template. The index lifecycle management policies are also viewable, creatable and deletable. Taken together, this is a coherent backup story for an Elasticsearch cluster that a small team has to administer without a dedicated platform.

Switching clusters rebuilds the client, so credentials do not linger

Connection handling is the part of the design that shows operational thinking. Connection configurations can be imported and exported, including a safe export without the password, and an import updates and merges an entry that has the same name. The isolation guarantee is the important one: when you switch clusters, the client is rebuilt, which the README presents as the way to avoid any residue of BasicAuth, TLS settings or a custom CA certificate from the previous cluster. In a tool that stores credentials for several environments, leftover authentication state is a genuine problem, and rebuilding the client is a blunt but effective answer. The interface side of the same feature shows feedback on connection cards and a badge for the currently connected cluster. The console also supports multiple languages, with Simplified Chinese, English and Japanese listed as complete translations.

Release binaries for three platforms, and a wails dev loop

Adoption does not require building anything. The README points to the GitHub releases page and tells you to pick the Assets entry matching your platform, with Windows, macOS and Linux builds available, and the last three tags are v0.35 on 2026-10-08, v0.34 on 2026-09-09 and v0.33 as a pre-release on 2026-09-09. The default branch is wails, which is also the name of the framework the project credits alongside the naive ui component library. Working on the client itself means installing Go, Node.js and npm, then installing the Wails CLI, and running the development server from the app directory:

go install github.com/wailsapp/wails/v2/cmd/wails@latest

cd app
wails dev

The build therefore has two toolchains, a Go side for the desktop host and a Node side for the Vue assets, and the release artefacts are produced from that stack rather than from a pure JavaScript bundle. The repository is not archived and the last push was on 2026-10-08, matching the newest tag, so the release cadence and the source tree move together.

Editorial conclusion

Adopt ES-King when you want a fast local GUI for day to day Elasticsearch work and need shard allocation explanations or snapshot management without living in the browser. Do not expect it to replace a cluster management platform, and check that your cluster is reachable over REST with the credentials you plan to store, since connections are rebuilt on every switch.

Frequently asked questions

Official sources

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