typesense-dashboard is a Quasar and Electron front end for Typesense

A side project that became a real admin tool

typesense-dashboard is a dashboard to manage and browse Typesense collections, and the README is candid about its origins, calling it a side project to test the Typesense API and Quasar with electron.

The screenshots give the scope: server status, collections, adding a collection, aliases, API keys, a single document, search and search JSON, the schema, synonyms and curations. That is the administrative surface of a Typesense node, and it is the part of running a search cluster that a command line makes tedious.

The implementation is Vue with the Quasar component framework, packaged with Quasar's Vite tooling, and it is published under the GPL-3.0. The author is Boris Fritscher. The last push to the main branch was on 2026-07-22, and the release tags follow a steady path: v2.5.0 on 2026-07-22, v2.4.8 on 2026-03-24 and v2.4.7 on 2026-03-04. The hosted version is served from the project's GitHub Pages site.

It ships in two shapes. The web build is a static single page application served by any web server, and the desktop build is an Electron application that talks to Typesense directly. Which one you can use is decided almost entirely by CORS, and that single fact shapes the rest of the design.

CORS decides whether the web build works at all

The constraint is stated up front: as a web application, only a Typesense server started with the --enable-cors option will work.

That is the browser's same-origin policy meeting a search API that has no built-in CORS support. A browser-hosted dashboard on a different origin from the Typesense node will have its requests blocked before they leave the page.

There is a second constraint that catches people out. When you use the dashboard in your browser from an https address, your Typesense server must also be behind SSL, or you get a Mixed Content Network Error. The documentation mentions that you could allow mixed content in the browser, and says that this is not recommended, which is a polite way of describing a configuration that will break for some users regardless of your preference.

The desktop application escapes both problems. With the desktop application, everything except instant search works without CORS, which is a precise limitation worth noting: the instant search feature is the part that still depends on the browser path.

The other desktop-only difference is file size. To export or import large JSON or JSONL files, the desktop version is required, because the browser version times out. That single constraint is the deciding factor for a team that needs to move documents in or out of a collection, and it is the reason the project publishes a desktop build rather than being web only.

Serving the dashboard in Docker behind Caddy

Self-hosting the web version is a two command exercise:

$ docker build -t typesense-dashboard .
$ docker run -d -p 80:80 typesense-dashboard

The image serves the actual files with caddy, and the published Dockerfile is a two stage build. The builder is node:24-alpine, it installs the native build toolchain, runs the npm installs for the app and for the Electron part with scripts disabled, runs the Quasar postinstall and build steps, and the runtime stage is caddy:2-alpine with the built single page application copied into the working directory and an entrypoint script doing the setup. Only port 80 is exposed.

One build argument matters if you are serving from a subfolder. PUBLIC_PATH sets the base path, it has to start with a slash, and the example in the documentation serves from /example:

docker build --build-arg=PUBLIC_PATH=/example -t typesense-dashboard .

The pre-built image is published as well, which skips the build entirely:

docker run -d -p 80:80 ghcr.io/bfritscher/typesense-dashboard:latest

There is also an escape hatch for people who do not want the caddy layer. The documentation points out that you can copy the /srv directory out of the final image into another image of your own, which is a small piece of advice that saves an afternoon when your hosting setup already has a web server.

The one functional caveat of the containerised web build is stated in the same section: the web version has some limitations on the import and export size of files, which is the file size constraint from the browser showing up again in a different place.

One config.json, two ways to supply it in Docker

The application looks for its configuration in /config.json on the initial page load, and the same data is what the browser stores in localStorage. A sample file sits in the project root as config.json.sample.

In Docker there are two ways to provide that file. You can mount it into the container, or you can pass it as an environment variable containing the configuration JSON in base64 encoded format, in which case the container generates config.json at startup:

docker run -d -p 80:80 -v /path/to/config.json:/srv/config.json typesense-dashboard

docker run -d -p 80:80 -e TYPESENSE_DASHBOARD_CONFIG=$(base64 -w 0 /path/to/config.json) typesense-dashboard

The settings it carries are autologin, UI options, bookmarks through the history mechanism, and cluster tagging. The history array is used to populate the client history, which acts as bookmarks, and each entry holds an API key and a node definition. The node definition is a host, a port, a protocol, a path and a TLS flag, and in the example configuration the third entry adds a cluster tag of dev-cluster.

There is one special host value worth knowing. Setting node.host to "SAME" makes the dashboard resolve the host from window.location.hostname, the protocol from window.location.protocol and the port from window.location.port, defaulting to 80 or 443 when it is absent. That is the setting to use when you reverse-proxy the dashboard and Typesense under the same domain, which is a common and tidy arrangement. A minimal configuration for it is short:

{
  "node": {
    "host": "SAME",
    "path": "/api"
  }
}

The ui section has one documented option today. Setting hideProjectInfo to true hides the project information section, which holds the version, the GitHub link and the issue tracker, from the navigation menu, and the default is false.

Cluster Status polls several nodes side by side

The Cluster Status page is the most substantial feature in the project, and it is the part with the most moving pieces behind it.

The page shows multiple Typesense nodes side by side and polls their status in parallel. Each node card shows the node URL and version, the role with the leader and follower distinction emphasised, memory and disk usage, the Typesense memory metrics such as the typesense_* series, system network receive and transmit figures, and the stats if the node has them enabled.

The rules for when it appears and how nodes are grouped are specific. The navigation entry appears only when the currently connected node belongs to a cluster. Nodes are associated with a cluster using an optional clusterTag field embedded in each login history entry, and an entry that omits the tag is not part of any cluster at all. The page is shown only when the currently connected node itself carries a cluster tag.

Ordering is deterministic, by host, then port, then protocol, and the node you are currently connected to is highlighted. You can switch to another node directly from its card.

There are two ways to define the clusters. In the interface you can tag any saved server entry from the server history popover with a text tag, and the tag input autocompletes existing tags while accepting new values. Or you can pre-populate history entries with a clusterTag in config.json, which is the way to make the grouping work for everyone who connects to the same dashboard without anyone having to tag anything by hand.

The desktop build and the three missing API features

The desktop application is available from the release page, and you can also build it yourself. On Linux there is one specific wrinkle the documentation calls out: the app cannot be started by clicking on it in Nautilus, because of how the file is recognised, and the fix is to make it executable and run it from a command line:

./'Typesense-Dashboard'

The known issues and limitations section is short and honest. Three API features are not implemented: create snapshot, delete by query, and scoped search key generation.

Those three are not trivial gaps for an operator. A snapshot is how you copy a collection or back one up, delete by query is how you remove documents matching a filter rather than one key at a time, and scoped search keys are the mechanism for handing a client a key that can only search a subset of a collection. Anyone whose operational runbook depends on any of those has to fall back to the Typesense API or another tool for those steps.

There is also a testing gap, visible in the package scripts. The test script is a placeholder that prints a message and exits successfully, so the project ships with no automated test suite of its own. For a tool whose whole job is mutating a live search cluster, that is worth knowing before you trust a change.

Quasar for the interface, Electron for the shell

The development workflow is the standard Quasar one, and the scripts make it explicit.

Dependencies are installed with yarn, and the development server starts with quasar dev. The desktop variant is quasar dev -m electron --devtools. Linting is eslint over the TypeScript, JavaScript and Vue sources, the format script is prettier, and the type check is vue-tsc --build. Production builds are quasar build and quasar build -m electron --target all for the desktop targets.

The dependency list tells you what the interface is made of: Quasar and its icon set, Vue with vue-router and Pinia for state, the Typesense JavaScript client at 3.0.6, and the instantsearch stack with typesense-instantsearch-adapter and vue-instantsearch, which is what powers the instant search feature that still needs CORS. Monaco is the editor used for schema and document views, axios handles HTTP, and file-saver and pretty-bytes deal with downloads and sizes. The engines field allows Node 20, 22, 24, 26 or 28.

There is a typesense-test-server directory in the repository, and the repository also carries a Quasar config, an ESLint flat config, a Prettier config, an entrypoint script for the container and separate config samples for autologin and the full configuration.

On the licence, this is a GPL-3.0 project, which is worth noting for a piece of tooling that may be embedded into an internal operations setup, since the copyleft obligations attach to a distributed derivative rather than to internal use. The project is not archived, and the current version is 2.5.0.

Editorial conclusion

typesense-dashboard suits a team that wants a graphical way to manage Typesense collections, schemas, aliases, API keys and search experiments, and it is the wrong tool for a browser-only deployment of large data, because the web version times out on large imports and exports where the desktop build does not. Before choosing, decide between the web and desktop builds on that basis, and note that create snapshot, delete by query and scoped search key generation are still missing from the API surface.

Frequently asked questions

Official sources

1. bfritscher/typesense-dashboard on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases