The New Elastic Cloud Console

The Elastic Cloud console is your window into Elastic Cloud and all of your managed Elasticsearch clusters and associated Kibana instances, which we collectively call “deployments.” You can spin them up, shut them down and scale them out, and deal with any other housekeeping issues you’d expect to find in a managed cloud service.

The current Elastic Cloud console has been with us from the very beginning. Over that time we’ve collected a lot of feedback, and we’re happy to say that a new version is here to address it.

The new console brings a raft of user experience improvements. Improved navigation makes dealing with multiple deployments easier. Accessibility features such as keyboard navigation and Accessible Rich Internet Applications (ARIA) support comes courtesy of EUI, Elastic’s new design language and component library. All the user research and design effort that went into Elastic Cloud Enterprise is now reflected in Elastic Cloud too.


Sharing is caring

Elastic Cloud Enterprise (ECE), our on-premise orchestration product, has its own console. It covers much of what the Elastic Cloud Console does, minus a few things (like billing details) and plus a few others (like managing the infrastructure that Elastic Cloud provides for you).

In fact, Elastic uses a version of the ECE console to administer Elastic Cloud. With Elastic Cloud Enterprise you’re using the same tool we use to provide managed Elasticsearch to thousands of customers.

The “old” Elastic Cloud console, as we now get to call it, runs a Backbone-based UI and a Python-based API. The ECE console is newer, with a React-based UI and a Scala-based API. Technical differences aside, there’s significant overlap between the two consoles:ucv2venn.png

All of this hums along quite nicely, with one major exception: delivering new features. Something like the upcoming customizable deployment templates feature will be implemented in ECE, but it’s also something we want to add in a curated form to Elastic Cloud. We would have needed to do significant work on the Elastic Cloud console to support the customizable deployment templates concept, splitting our attention and time.

The obvious solution to this was to embrace our inner laziness and leverage the code we’d already written in ECE. So, we decided to rewrite the Elastic Cloud console entirely, this time basing it off the ECE codebase.

Diving (a bit) deeper

The ECE console is a fairly typical React+Redux project. Simplified, the structure looks like this:


The actions, components and reducers are the basic building blocks of a React+Redux app. Our webpack entry point is app.js. It imports configuration data, like feature flags, from config.js, and a react-router configuration from routes.js.

The routes file is what maps URLs to React components, so that a single-page app doesn’t look like a single page. It also acts as a sort of manifest. It imports the main page-level components, in order to map URLs to them; those page components import smaller components, and so on.

When webpack bundles the source code for an entry point, this tree of import statements is walked and every referenced file is included in the bundle. Files that aren’t imported are simply left out.

To date, we have generated two apps from this structure: the ECE console and our Elastic Cloud administration tool. Via environment variables, config.js sets various application-level feature flags. For example, we set flags to control whether we show region names throughout the UI. Elastic Cloud supports multiple cloud providers and regions within them. In ECE, your own private infrastructure — even if it lives in the cloud — supplants both concepts. Therefore, the region names flag is set to true for the administration tool and false for ECE.

This flag-based approach has worked to date because the differences between those two applications are very granular. They occur frequently but deep in the component tree.

The relationship between the ECE console and the Elastic Cloud console is the opposite. Many components are shared verbatim between the two, but there are large chunks that live only in one or the other. In this situation, it makes sense to fork the app at the top.

We introduced the following structure:


The actions, components and reducers that are shared between both the admin and user consoles still live in the root. Those that are only relevant to one or the other live in their respective app/ directory.

The major upshot is evident from the routes files. Simplified again, they look like this:


import Deployments
  from '../../components/Deployments'
  Platform from './components/Platform'
<Route path='/'>
  <Route path='deployments'
    component={ Deployments } />
  <Route path='platform'
    component={ Platform } />


import Deployments
  from '../../components/Deployments'
import Account
  from './components/Account'
<Route path='/'>
  <Route path='deployments'
    component={ Deployments } />
  <Route path='account'
    component={ Account } />

The admin console imports a Platform section from within the app/adminconsole directory, and the user-facing console imports an Account section from within the app/userconsole directory. But they both import the same Deployments section from the root. When webpack builds one app or the other, only the relevant source will be bundled.

To tell webpack which app to build we derive the correct entry point from an environment variable. We have another to specify whether the build should consider itself destined for Elastic Cloud or ECE. The end result is that we can generate three different apps from the combination of two environment variables:

CLOUD_APP SAAS Results in...
adminconsole false Elastic Cloud Enterprise
adminconsole true Elastic Cloud administration tool
userconsole true Elastic Cloud console

In addition to the better user experience and greatly enhanced accessibility features of the new Elastic Cloud console, this change lays important groundwork for the future. We’re excited to be able to bring new features to Elastic Cloud and ECE in tandem, starting with the customizable deployment templates feature in the coming weeks.

We’ll be switching over to the new Elastic Cloud console in a few days. If you want a sneak peek before then, just head over to We’d love to hear your thoughts. You can email us at

  • We're hiring

    Work for a global, distributed team where finding someone like you is just a Zoom meeting away. Flexible work with impact? Development opportunities from the start?