# Elasticvue: a browser-first Elasticsearch GUI in four delivery shapes

> Elasticvue is an MIT-licensed Elasticsearch GUI that ships as a desktop app, a browser extension, a hosted web app and a Docker image. The delivery method you pick decides whether you have to touch CORS at all.

**cars10/elasticvue** — Elasticsearch gui - desktop app, browser extension, docker, self hosted

- Repository: https://github.com/cars10/elasticvue
- Website: https://elasticvue.com
- Stars: 2,754 · Forks: 201
- Language: TypeScript
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/cars10-elasticvue

## What Elasticvue actually solves, and for whom

Elasticsearch ships with an HTTP API and no graphical client of its own. Elasticvue fills that gap: it is described in the README as "a free and open-source gui for elasticsearch that you can use to manage the data in your cluster." The feature list is the usual operator surface: cluster overview, index and alias management, shard management, searching and editing documents, REST queries, and snapshot and repository management.

The interesting claim is version coverage. The README states it "supports every version of elasticsearch, even those that are EOL," and points to the project wiki FAQ for detail. That matters for teams running an old 6.x or 7.x cluster that they cannot upgrade, because the GUI does not force a cluster upgrade as a prerequisite.

The intended audience is the person who needs to look at a cluster right now without standing up a server. That is why the project distributes the same interface four ways instead of picking one.

## Four delivery shapes, and the CORS line that splits them

The README's usage table is the most decision-relevant thing in the repository. It compares desktop app, browser extension, web, self hosted and Docker across three columns: auto update, whether cluster configuration is required, and support for self-signed SSL.

Desktop app and browser extension need no cluster configuration and auto-update. Desktop gets full self-signed SSL support; the extension gets "partially." Web, self hosted and Docker all require cluster configuration, do not auto-update, and also get only partial self-signed SSL support.

That split is not cosmetic. The README is explicit that you must enable CORS on your Elasticsearch cluster "if you do not use the desktop app or the browser extensions." So the extension and the desktop build avoid a server-side config change that the Docker and web paths force on you. If you are deciding between the extension and a Docker deployment, that is the trade: a Docker image gives you a shared URL for a team, and in exchange you edit elasticsearch.yml.

The desktop app is marked recommended in the README. Given the CORS and SSL columns, that recommendation is consistent with the table rather than just a preference.

## Installing the Docker image and seeding clusters

The README points at an existing image and gives two pull locations. The container listens on 8080.

```bash
# docker hub:
docker run -p 8080:8080 --name elasticvue -d cars10/elasticvue

# ghcr.io:
docker run -p 8080:8080 --name elasticvue -d ghcr.io/cars10/elasticvue
```

The README warns directly above that section that you have to configure your Elasticsearch cluster if you want to use Elasticvue via Docker. Opening the container without that step gets you a UI that cannot talk to the cluster.

Default clusters can be injected so users do not type connection details. The README describes the content as a JSON array of cluster objects, imported automatically every time Elasticvue starts.

```json
[
  {
    "name": "dev cluster",
    "uri": "http://localhost:9200"
  },
  {
    "name": "prod cluster",
    "uri": "http://localhost:9501",
    "username": "elastic",
    "password": "foobar"
  }
]
```

You can pass that array as an environment variable or mount it as a file. The README shows both. The environment variable form:

```bash
docker run -p 8080:8080 -e ELASTICVUE_CLUSTERS='[{"name": "prod cluster", "uri": "http://localhost:9200", "username": "elastic", "password": "elastic"}]' cars10/elasticvue
```

And the volume form, which writes the array to a file first and mounts it at a fixed path inside the nginx-served image:

```bash
echo '[{"name": "prod cluster", "uri": "http://localhost:9200", "username": "elastic", "password": "elastic"}]' > config.json
docker run -p 8080:8080 -v config.json:/usr/share/nginx/html/api/default_clusters.json cars10/elasticvue
```

The cluster object accepts more than name, uri, username and password. The README's key table lists apiKey for API key authentication, plus S3accessKeyId, S3secretAccessKey, S3sessionToken and S3region for AWS IAM authentication. Only uri is marked required.

On the cluster side, the README gives the Elasticsearch settings to add to elasticsearch.yml, including http.cors.enabled: true, an http.cors.allow-origin value chosen for your deployment, and http.cors.allow-headers with Authorization when the cluster uses authorization. The README also notes the same options can be passed as environment variables to a Dockerized Elasticsearch.

## Where Elasticvue is the wrong tool

The CORS requirement is the sharpest limitation, and it is architectural rather than a missing feature. Anything that runs the GUI in a browser tab and talks straight to the cluster needs the cluster to accept cross-origin requests from that origin. Enabling CORS on a production cluster widens what the cluster will answer to, and the README's own instructions require it for the web, self-hosted and Docker paths. If your security posture does not allow that change, those three paths are closed to you and you are left with the desktop app or the browser extension.

Self-signed TLS is the second constraint. The README's table marks support as "partially" for the extension, web, self-hosted and Docker rows, and only the desktop row gets an unqualified yes. A team running internal certificates on the cluster should read that column before standardizing on the Docker image.

There is also a plain mismatch of expectations. Elasticvue is a client. It does not index anything, does not run as a cluster plugin, and does not sit between your application and Elasticsearch. If what you actually need is a server-side service that holds credentials so end users never see them, this is not that product, and the pre-seeded cluster JSON in the Docker path is a convenience for connection details, not a credential-hiding layer.

The README does not document a rollback procedure for the default-cluster import, which runs on every start. If you remove a cluster from the JSON, the README does not say what happens to the entry already stored in the browser.

## Elasticvue against Kibana, and against doing nothing

The README has a section titled "Comparing with other frontends," so the project treats the comparison as part of its own story. The concrete difference visible in the repository is packaging and footprint. Kibana is a server you deploy alongside the cluster, and it is tied to the Elastic stack version you run. Elasticvue is a client that runs in a browser tab, a desktop binary or a single container on port 8080, and the README claims support for every Elasticsearch version including EOL ones.

That difference cuts both ways. A browser-resident client has no server-side session, which is why CORS has to be opened up. Kibana, being a server, does not need that particular change. So the choice is not "lighter versus heavier" in the abstract: it is whether you would rather operate another service or relax cross-origin rules on the cluster.

The alternative to both is curl and the Elasticsearch HTTP API. That costs nothing to install and needs no CORS change, but it gives you no index browser, no shard view and no document editor. Elasticvue's value is concentrated in those interactive screens, and the REST query feature means you can drop to raw requests inside the same tool when a screen does not cover what you need.

## Maintenance, licence and what upgrading costs

Elasticvue is MIT licensed, and the LICENSE file is at the repository root. MIT is permissive, so embedding the built assets in an internal portal or shipping the container internally is not a licensing question in the way a copyleft dependency would be. That is a statement about the licence text, not legal advice; the trademark notice in the README is separate and worth reading, since it states that Elasticsearch is a trademark of Elasticsearch BV.

The repository is not archived, and the last push was on 2026-09-20. Releases are frequent enough to be concrete: v1.14.0 on 2026-03-12, v1.15.0 on 2026-05-12, and v1.16.0 on 2026-09-20. The package.json version matches v1.16.0.

The upgrade cost depends entirely on which shape you chose. Desktop and browser extension rows in the README's table say auto update, so users get new versions without action. Docker and self-hosted say no auto update, which means a new image tag is a manual redeploy, and the pre-seeded cluster JSON is re-imported on every start, so a config change and an image bump can be done in the same step. The web version at app.elasticvue.com updates on the maintainer's schedule, not yours, which is a real consideration if you point a team at it.

If you build from source rather than consuming the image, package.json pins engines.node to >=24.15.0, and the Makefile drives the heavy jobs through Docker: build_docker_nginx for the nginx-served image, build_docker_nginx_multiarch for amd64, arm64 and arm/v7, and build_browser_extensions for the extension artifacts. The compose.yml dev service runs npm run dev -- --host 0.0.0.0 on port 5173, which is the local development path rather than a deployment one.

## Conclusion

Adopt Elasticvue if you want a cluster GUI that runs inside the browser you already have, or a Docker image you can hand to a team with pre-seeded cluster entries. Do not adopt it if you need a server-side component that holds credentials on the user's behalf, or if your security model forbids browser-to-cluster traffic. Before rolling it out, verify the CORS settings on each cluster against the mode you picked, and check whether the web and Docker paths support your TLS setup, since the README marks self-signed SSL support as only partial outside the desktop app.

## FAQ

### What is Elasticvue?

It is a free and open-source GUI for Elasticsearch, used to manage the data in a cluster. It ships as a desktop app, a browser extension, a hosted web app and a Docker image, and the README states it supports every Elasticsearch version including EOL ones.

### How do I use the Elasticvue extension?

You install it from the Chrome, Firefox or Edge add-on store and connect it to a cluster. The README's usage table lists the browser extension as needing no cluster configuration and as supporting self-signed SSL only partially.

### Is Elasticvue safe to use?

The repository does not make a security claim either way. What it does document is that the web, self-hosted and Docker paths require enabling CORS on your Elasticsearch cluster, while the desktop app and browser extensions do not, and that self-signed SSL support is full only for the desktop app.

## Sources

- [cars10/elasticvue on GitHub](https://github.com/cars10/elasticvue)
- [License: MIT](https://github.com/cars10/elasticvue/blob/master/LICENSE)
- [Project website](https://elasticvue.com)
- [README](https://github.com/cars10/elasticvue/blob/master/README.md)
- [Releases](https://github.com/cars10/elasticvue/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cars10-elasticvue