appbaseio/dejavu: a browser UI for Elasticsearch and OpenSearch data

What dejavu solves, and who ends up using it

Elasticsearch and OpenSearch both expose a JSON HTTP API and nothing else. Reading a document means curling an endpoint; editing one means a PUT with the full body; importing a CSV means writing a bulk request by hand or scripting one. Kibana covers some of this, but it is a large Node service to run, and its README comparison table positions dejavu as the lighter option with data import and export in JSON and CSV, which Kibana's column lists as export only, with no CSV.

Dejavu's audience is narrow and practical. Someone debugging why a document did not match a query. Someone who needs to fix a single field on a handful of records. Someone loading a CSV from a colleague into a fresh index and defining the field mappings from a form instead of a mapping JSON blob. The README also lists a search UI builder, aimed at people testing relevancy visually rather than through a query editor.

The project is a monorepo. The top-level package.json is named dejavu-monorepo at version 3.10.0, and the packages directory plus lerna.json indicate the code is split into packages such as dejavu-main and @appbaseio/dejavu-browser. The last push to the repository was on 2026-07-02, and the most recent release listed is 3.10.0 from 2025-09-07.

Client-side rendering and what that means for your cluster

The README states that dejavu is 100% client-side rendered. That single design decision explains most of its behaviour. The container serves static assets and a small server entry point (the Dockerfile ends with node packages/dejavu-main/server.js), while the queries themselves go from your browser to the cluster. There is no backend proxy holding your credentials.

The practical consequence is CORS. Your cluster has to accept requests from whatever origin dejavu is served on. The repository's docker-compose.yml makes this explicit for the bundled OpenSearch service: it sets http.cors.enabled=true and http.cors.allow-origin to http://localhost:1358,http://127.0.0.1:1358, with http.cors.allow-headers listing X-Requested-With, X-Auth-Token, Content-Type, Content-Length and Authorization. If you point dejavu at a cluster whose CORS settings do not include its origin, the UI will load and the queries will fail. That is a cluster-side configuration problem, not a dejavu bug, and it is the first thing to check when the app appears empty.

The second consequence is authentication. The README notes that since v1.5 you can define custom headers, so you can pass an auth header of your own. Because those headers live in the browser, dejavu is a tool for a trusted operator on a trusted network, or for a cluster already protected at the network layer. It is not a way to expose an unauthenticated cluster to the internet.

Connected indices are cached locally in the browser, per the README, which is why returning to a previously used index is quick. It also means the list of clusters you have touched is a browser-local artifact, not something shared across a team.

Running dejavu with the bundled docker-compose stack

The repository ships three compose files: docker-compose.yml, docker-compose-v7.yml and docker-compose-v8.yml. The default one pairs dejavu with an OpenSearch 2.17.0 container. The compose file sets DISABLE_SECURITY_PLUGIN=true on OpenSearch, so this stack is for local work only; do not carry that environment into anything reachable from outside your machine.

From the repository root, start both services:

docker compose up

The compose file maps OpenSearch to 9200 and dejavu to 1358. Open http://localhost:1358 in a browser and you should see the connection screen, where you enter the cluster URL. For this stack that URL is http://localhost:9200. The allow-origin values in the compose file already cover port 1358, so the connection should succeed without further CORS edits.

If you prefer to run dejavu on its own against a cluster you already have, the image is published on Docker Hub as appbaseio/dejavu. The Dockerfile exposes port 1358 and starts the server with node packages/dejavu-main/server.js. The README also points to a hosted app at dejavu.reactivesearch.io as an alternative to running anything locally.

To build from source instead, the Dockerfile shows the toolchain: node:lts-alpine3.21, yarn install, then DISABLE_FAVICONS=1 yarn build:dejavu:app. The root package.json requires Node >=14.17.1 and its start script runs lerna run watch with NODE_OPTIONS=--openssl-legacy-provider, which tells you the build expects an older OpenSSL behaviour.

Importing a CSV and defining mappings from the UI

The importer is the feature the README leans on hardest, and it is the one that saves the most typing. It takes a CSV or JSON file and walks you through a mapping configuration before writing documents. The README describes this as a guided data mapping configuration, and claims dejavu is the only Elasticsearch web UI that supports importing via JSON and CSV plus defining field mappings from the GUI, starting at v1.0.

This matters because a wrong type in a mapping is expensive to undo: changing a field from text to keyword on a populated index generally means reindexing. Doing the type decision in a form, with the column values visible, is a real improvement over writing the mapping JSON blind.

Export is covered too. Any filtered view can be exported as JSON or CSV, according to the README, which makes the round trip useful for extracting a subset of documents, editing them outside the browser, and re-importing. Bulk updates via Elasticsearch's Query DSL are supported as of v1.5, alongside individual document edits and deletions, so a filter built visually can be turned into a bulk change without leaving the UI.

For a large file on a flaky connection, plan for the possibility of a partially populated index and check the document count afterwards.

Where dejavu is the wrong tool

Dejavu has no visualizations. The README's own comparison table gives Kibana the read view, visualizations and charting column, and gives dejavu CRUD and data filters. If your goal is a dashboard, a time-series chart or an alert, dejavu does not do it and is not trying to. Teams sometimes reach for a data browser when what they actually need is a monitoring stack, and this is the point where that substitution fails.

The second boundary is security posture. With 100% client-side rendering, custom auth headers held in the browser, and a compose file that disables the OpenSearch security plugin for convenience, the intended deployment is a developer machine or an internal network. If you need to give a non-engineer read access to production data with an audit log, dejavu is not the layer that provides it.

Third, the project's own feature list is the ceiling. The README's roadmap section records the completed 1.0.0 roadmap rather than a plan for what comes after v3.10.0. Treat the current feature set as what you get, and check the release history before assuming a gap will close.

Finally, the build carries legacy weight. React 18 is in the root dependencies while the README's comparison table still lists React 16.6, and the start script needs --openssl-legacy-provider. Both are signs of a codebase that has been updated selectively rather than rebuilt. That is not disqualifying, but it does mean a local build may need pinning rather than just a current Node install.

How dejavu differs from elasticsearch-head and Kibana

The README compares dejavu against elasticsearch-head, elasticsearch-kopf, elasticsearch-browser and Kibana. The head and kopf projects install as Elasticsearch plugins or static pages and are built on jQuery 1.6.1 and Angular 1.x respectively; the README's table lists read data and full-text search for head, and no data import or export for either. elasticsearch-browser is listed as a plugin that does not work with 2.0 and later, and as a data view for a single type.

The real difference is where the tool lives. A plugin runs inside the cluster process, so it inherits the cluster's own auth and needs no CORS configuration, but it also has to be installed into every cluster you want to inspect and it moves with the cluster version. Dejavu runs outside as a container or static app, so one instance can point at several clusters, which is consistent with the v3.0 multi-index support and the global search bar described in the README. The cost is the CORS and header setup described earlier.

Against Kibana the split is capability versus weight. Kibana is a Node, Hapi and Jade application per the table, with visualizations and charting that dejavu lacks, and export without CSV. Dejavu is smaller and adds CSV import and export plus the search UI builder. If you already run Kibana, dejavu is a complement for the import and edit workflows, not a replacement.

One thing the comparison table does not cover is maintenance. The last push to this repository was on 2026-07-02, and the release cadence shows 3.8.3 in September 2024, then 3.9.0 and 3.10.0 in August and September 2025. The gaps are uneven, so check the release history against your engine version rather than assuming continuous tracking.

Licence and the cost of keeping it current

Dejavu is MIT licensed, and the root package.json carries "license": "MIT" with the full text in LICENSE.md. MIT is permissive: you can run it internally, modify it, and ship it inside a product, provided you keep the copyright notice and licence text. This is a summary of what the repository states, not legal advice; if you are embedding it in a distributed product, have your own counsel read LICENSE.md.

Upgrade cost is dominated by version matching rather than by dejavu itself. The presence of docker-compose-v7.yml and docker-compose-v8.yml alongside the default file suggests the project tracks Elasticsearch major versions separately, so the first question before upgrading is which compose file or image matches your engine. The Dockerfile pins node:lts-alpine3.21, which will drift as that tag moves; if you build your own image, pin the digest rather than the floating tag.

The client-side architecture keeps operational cost low. There is no database to migrate, no state on the server, and the index cache lives in the browser. Upgrading the container does not touch your cluster. The one thing to re-verify after any upgrade is your custom auth headers, since those are configured in the UI rather than in a file you can diff.

Editorial conclusion

Adopt dejavu when you need to inspect, filter or bulk-edit documents in an Elasticsearch or OpenSearch cluster and you do not want to run Kibana for it, or when you want to hand a CSV import to someone who will not write a bulk request by hand. Skip it if you need dashboards, charting or alerting, since its README scopes it to browsing, editing and search preview, not visualization. Before rolling it out beyond localhost, verify two things yourself: whether your cluster's CORS headers allow the origin you will serve dejavu from, and whether the version you pull matches your engine, since the repository ships separate docker-compose-v7.yml and docker-compose-v8.yml files alongside the default compose file.

Frequently asked questions

Official sources

1. appbaseio/dejavu on GitHub
2. License: MIT
3. Project website
4. README
5. Releases