Collectively, we have a lot of experience with users suffering unexpected issues because they have not configured important settings. In previous versions of Elasticsearch, misconfiguration of some of these settings were logged as warnings. Understandably, users sometimes miss these log messages. To ensure that these settings receive the attention that they deserve, Elasticsearch has bootstrap checks upon startup.
These bootstrap checks inspect a variety of Elasticsearch and system settings and compare them to values that are safe for the operation of Elasticsearch. If Elasticsearch is in development mode, any bootstrap checks that fail appear as warnings in the Elasticsearch log. If Elasticsearch is in production mode, any bootstrap checks that fail will cause Elasticsearch to refuse to start.
There are some bootstrap checks that are always enforced to prevent Elasticsearch from running with incompatible settings. These checks are documented individually.
Development vs. production modeedit
By default, Elasticsearch binds to
localhost for HTTP
and transport (internal) communication. This is
fine for downloading and playing with Elasticsearch, and everyday
development but it’s useless for production systems. To form a cluster,
Elasticsearch instances must be reachable via transport communication so
they must bind transport to an external interface. Thus, we consider an
Elasticsearch instance to be in development mode if it does not bind
transport to an external interface (the default), and is otherwise in
production mode if it does bind transport to an external interface.
Note that HTTP can be configured independently of transport via
this can be useful for configuring a single instance to be reachable via
HTTP for testing purposes without triggering production mode.
We recognize that some users need to bind transport to an external
interface for testing their usage of the transport client. For this
situation, we provide the discovery type
single-node (configure it by
single-node); in this situation, a node
will elect itself master and will not form a cluster with any other
If you are running a single node in production, it is possible to evade
the bootstrap checks (either by not binding transport to an external
interface, or by binding transport to an external interface and setting
the discovery type to
single-node). For this situation, you can force
execution of the bootstrap checks by setting the system property
true (set this in Setting JVM options, or
-Des.enforce.bootstrap.checks=true to the environment
ES_JAVA_OPTS). We strongly encourage you to do this if you
are in this specific situation. This system property can be used to
force execution of the bootstrap checks independent of the node