Banana ports Kibana dashboards onto Apache Solr without a Solr plugin

Banana keeps Kibana's dashboard format and swaps the storage engine

The fork relationship is the whole design. Banana was forked from Kibana and works with all kinds of time series and non time series data stored in Apache Solr. It keeps what Kibana was good at, which the README describes as Kibana's dashboard configuration capabilities, and ports the key panels to work with Solr. It then adds panels built on D3.js. The goal stated in the README is a UI with many configuration options that lets users rapidly develop end-to-end applications on Solr. For a team already running Solr, that means the saving is not the charts themselves but the ecosystem around them: a saved dashboard format, panel configuration, and a known set of panels, without writing a Solr plugin for each visualisation or learning a Solr-native dashboard tool from scratch. The data path is the part Banana does not change. Data still enters Solr through Logstash, Flume or other connectors, and Banana only reads what is already indexed there.

Four deployment routes, from a Solr webapp to a standalone webserver

Banana is an AngularJS app, so it can run in several places, and the README documents four options. Option 1 puts the webapp inside an existing Solr instance, which is the simplest path. Option 2 is the Lucidworks Silk stack, which packages Solr, Logstash with a Solr output plugin, and Banana together with example collections and dashboards, aimed at proof-of-concept work. Option 3 builds a WAR and drops it next to Solr, and the README notes this applies to Solr 5 or 4 only, since Solr 6 has a different architecture. Option 4 runs the app in any webserver that can reach Solr. That last option carries a real constraint, because you then need CORS enabled on the Solr instances you query, or a proxy that makes Banana and Solr same-origin, and the README says the proxy approach is the one typically recommended. The choice matters because it determines where you put the security boundary, and Banana runs in the client browser rather than on the server.

Copying the source into the Solr webapp is the fast first run

The quickest way to see Banana working is to serve it from Solr itself, so that the browser and Solr share an origin and CORS never enters the picture. For Solr 5 and later you run Solr once so the webapp directory exists, then copy the Banana source folder into the Solr webapp directory and open the resulting page. The README notes that running Solr first may be unnecessary for Solr 6. In the block below, the copy takes the src directory from the Banana checkout and puts it in place under the name banana, and the resulting URL is the one to open in a browser.

        cd $SOLR_HOME/server/solr-webapp/webapp
        cp -R $BANANA_HOME/src ./banana

bash

For production the README asks for one extra step, because the source tree is not what you want to serve. You build the optimized code with grunt, which produces a dist directory, and that is what gets copied to the production webserver.

        cd $BANANA_HOME
        npm install
        bower install
        grunt build
        cp -R ./dist $SOLR_HOME/server/solr-webapp/webapp/banana

bash

The build chain is old, and that is visible in the dependency list: grunt at 0.4.5, bower at 1.3.1, karma at 0.12.16 and protractor at 5.4.1, all of which predate the current npm toolchain by years.

Banana runs in the browser, so Solr must be reachable from the client

This is the operational point that catches people. The README is explicit that Banana runs within the client browser, so the hostname and port you configure have to be resolvable from the client machines, which means a fully qualified domain name rather than localhost. The two files to edit are banana/src/config.js and banana/src/app/dashboards/default.json, where you enter the hostname and port of your Solr server. That single fact drives most of the deployment guidance. Serving from inside the Solr webapp makes the two same-origin, so no CORS configuration is needed. Hosting Banana separately means either enabling CORS on every Solr instance you query or putting a proxy in front so the browser sees one origin, and the README recommends the proxy. It also means the Solr endpoint is reachable from the browser, so an unauthenticated Solr exposed to the internet is a real risk to consider before choosing the separate webserver route.

Saving dashboards in Solr requires a banana-int collection

Banana can keep dashboards in Solr itself, and doing so has a prerequisite that is easy to miss: you must first create a collection called banana-int. On Solr 6 the steps are a directory change and the solr create command with the -c flag. On Solr 5 and Solr 4 there is no such command, so you create the collection from the configuration files shipped in the repository, either the resources/banana-int-solr-5.0 directory for Solr 5 or the resources/banana-int-solr-4.5 directory for Solr 4.5. If you use SolrCloud the README starts describing a further step that the visible text does not finish, so a SolrCloud deployment needs more guidance than the README gives.

        cd $SOLR_HOME/bin
        ./solr create -c banana-int

bash

The alternative to storing dashboards in Solr is to keep them as files on disk, which is what the default dashboards in the app directory represent. Storing them in Solr is what lets a user edit a panel in the browser, save it, and share it with everyone else using the same Banana instance.

The release trail stopped in 2019 while pushes continued into 2026

Here is the maintenance picture, and it needs care. The repository is not archived and the last push was on 2026-05-28, so work has continued. The release list tells a different story: the newest tags are v1.6.26 from 2019-11-13 and v1.6.25 from 2019-08-27, with an older fusion-2.4.0 tag from 2016. The README describes the 1.6.26 release contents in detail, with heatmap improvements such as axes, axis labels, grid, ticks and a gradient legend, a hits panel with a direction option, a bettermap render fix on resize, and jshint warning fixes. The branch model explains the gap. The release branch is what production deployments should pull, with versions tagged as x.y.z, develop carries active development and the newest features, and the fusion branch serves Lucidworks Fusion releases with the same code and features as develop but different configuration. In other words, the trunk has moved for years while the tagged releases stayed put.

The licence file is one GitHub cannot classify

The project is listed under a custom licence that GitHub cannot classify, with a pointer to the LICENSE file. That is at odds with package.json, which declares the package as Apache-2.0 under the name banana-fusion, and with the NOTICE.txt file in the tree. This is a case where the two declarations disagree, and the disagreement is not something to guess about: the LICENSE file is the one that governs. Anyone planning to redistribute Banana, or to build a product on top of it, has to read that file rather than the badge. The same repository carries the usual project files for a fork of this size: a CONTRIBUTING.md, a Gruntfile.js, a build.xml for the Ant-based WAR build, a pom.xml, bower.json, package.json and a test directory. The presence of a Maven descriptor next to the npm and bower manifests shows a codebase that has grown three build systems over its life.

Where Banana is the wrong choice

The clearest case against Banana is architectural. It exists to give Solr a Kibana-shaped front end, so if your search platform is Elasticsearch or you are standardising on it, Banana is the wrong branch of the tree to be on, and you would rather fix the Solr compatibility gap in a tool that already speaks both. The second limit is the vintage of the client stack. AngularJS as the application framework, a grunt build at version 0.4.5, bower for dependency management and protractor 5.4.1 for browser tests all describe a codebase from the middle of the previous decade, and the README itself says to use the latest Chrome or Firefox when building dashboards, with Safari working except for the Export to File feature. That advice is a sign of what you are adopting. The third limit is that a forked dashboard tool inherits the security posture of its fork, and a dashboard UI that queries Solr directly from the browser needs Solr access control to be thought through carefully, particularly on the separate-webserver deployment path.

Editorial conclusion

Teams whose search stack is Solr rather than Elasticsearch, and who want Kibana-style saved dashboards without writing a Solr plugin, are the people Banana was built for. It is the wrong tool for a team that has decided to move to Elasticsearch, since Banana exists precisely to avoid that, and it is a poor base for new work because the newest tagged release is v1.6.26 from 2019-11-13 even though the last push was on 2026-05-28. Before you deploy it, check three things: that your Solr version is 6.x or at least 4.4, that the Solr endpoint is reachable from the browser or that a same-origin proxy is configured, and that the LICENSE.md terms are acceptable to your organisation, since the file carries a custom licence that GitHub cannot classify even though package.json declares Apache-2.0. Pin the release branch rather than tracking a moving target, because the README says production deployments should pull the release branch where versions are tagged.

Frequently asked questions

Official sources

1. Issues
2. lucidworks/banana on GitHub
3. README
4. Releases