# Kibana: Deploy without Ruby / Warbler / Gems / Java etc **URL:** \ **Category:** Elasticsearch\ **Created:** [October 28, 2014, 4:54am UTC](https://discuss.elastic.co/t/kibana-deploy-without-ruby-warbler-gems-java-etc/20454 "2014-10-28T04:54:04Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Ben\_Walding](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ben_walding/32/1156_2.png) [@Ben\_Walding](https://discuss.elastic.co/u/Ben_Walding)\ **Post date:** [October 28, 2014, 4:54am UTC](https://discuss.elastic.co/t/kibana-deploy-without-ruby-warbler-gems-java-etc/20454/1 "2014-10-28T04:54:04Z")
In Kibana 3, it was possible to deploy Kibana as a set of static files. In Kibana 4, the default mode is to deploy using a full stack of Ruby code on top of Warbler and JRuby etc. It seems from my experimentation that this is not really required beyond - automatically populating the /config endpoint with some configuration settings - creating an Elasticsearch proxy (presumably to avoid dealing with CORS and XSS limitations) - enumerating plugins (for reference I got Kibana 4 working in a static deployment by fixing a few pathing issues and adding CORS support to ES) While having a preconfigured stack that launches from a single command is awesome, it also bloats the deployment requirement for more sophisticated deployment. What I'd like to know is if the general development direction is that more dynamic configuration will be done in the Ruby code - creating an ever increasing requirement on the Ruby stack in the future? e.g. Generating a plugin manifest could easily be done using a bash / js script - it does not need a full Ruby stack. Thanks, Ben -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/f316bdf1-01d4-4e20-8037-a36baf650263%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/f316bdf1-01d4-4e20-8037-a36baf650263%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Nick\_Zadrozny](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nick_zadrozny/32/1150_2.png) [@Nick\_Zadrozny](https://discuss.elastic.co/u/Nick_Zadrozny)\ **Post date:** [October 28, 2014, 4:43pm UTC](https://discuss.elastic.co/t/kibana-deploy-without-ruby-warbler-gems-java-etc/20454/2 "2014-10-28T16:43:12Z")
As an Elasticsearch hosting provider, I share Ben’s questions here. We currently host Kibana 3 for our customers alongside their hosted ES clusters. Our customers find this to be useful, since we’re able to offer a zero-deploy, zero-configuration experience that already handles all the CORS and authentication and such. We’d like to continue providing that, and my current plan is to do a bit of work with Kibana 4 to extract the static assets, but it would be nice to get some official word from ES, Inc on the expected future trajectory for Kibana’s deployment story. A bit of consideration for static deploys would be really preferable to maintaining a de facto fork. (Thanks for all the hard work, etc; I’m looking forward to getting Kibana 4 out the door on Bonsai!) On Mon, Oct 27, 2014 at 11:54 PM, Ben Walding [bwalding@cloudbees.com](mailto:bwalding@cloudbees.com) wrote: > In Kibana 3, it was possible to deploy Kibana as a set of static files. > In Kibana 4, the default mode is to deploy using a full stack of Ruby code > on top of Warbler and JRuby etc. > It seems from my experimentation that this is not really required beyond > > - automatically populating the /config endpoint with some configuration > settings > - creating an Elasticsearch proxy (presumably to avoid dealing with CORS > and XSS limitations) > - enumerating plugins > (for reference I got Kibana 4 working in a static deployment by fixing a > few pathing issues and adding CORS support to ES) > While having a preconfigured stack that launches from a single command is > awesome, it also bloats the deployment requirement for more sophisticated > deployment. > What I'd like to know is if the general development direction is that more > dynamic configuration will be done in the Ruby code - creating an ever > increasing requirement on the Ruby stack in the future? > e.g. Generating a plugin manifest could easily be done using a bash / js > script - it does not need a full Ruby stack. > Thanks, > Ben > -- > You received this message because you are subscribed to the Google Groups "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/f316bdf1-01d4-4e20-8037-a36baf650263%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/f316bdf1-01d4-4e20-8037-a36baf650263%40googlegroups.com). > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/1414514591571.35f10e72%40Nodemailer](https://groups.google.com/d/msgid/elasticsearch/1414514591571.35f10e72%40Nodemailer). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 12:53am UTC](https://discuss.elastic.co/t/kibana-deploy-without-ruby-warbler-gems-java-etc/20454/3 "2017-07-06T00:53:24Z")