Only Gold and Platinum subscriptions, running version 2.4.6 or later, have access to uploading custom plugins. All subscription levels, including Standard, can upload scripts and dictionaries.
There are several cases where you might need your own files to be made available to your Elasticsearch cluster’s nodes:
To facilitate this, we make it possible to upload a zip file that contains the files you want to make available. Uploaded files are stored using Amazon’s highly available S3 service. This is necessary so we do not have to rely on the availability of third-party services such as the official plugin repository when provisioning nodes.
Files you upload are expected to be a zip file. Also, you need to choose whether your uploaded file should be treated as a plugin or as a bundle.
A plugin is a zip file that is installable as a plugin using Elasticsearch’s plugin tool. When configuring the node of your cluster, that is exactly what we do. We invoke the
install-tool with the URL of the uploaded zip file. This makes it easy for you to test that your uploaded zip file works locally: just see if you can run
bin/plugin --url file:///path/to/plugin --install plugin-name yourself.
Elasticsearch’s plugin tool assumes that the uploaded zip file contains binaries. If it finds any source code, it will fail with an error message, causing provisioning to fail. Make sure you upload binaries, and not source code.
A bundle’s entire content is made available to the node. This is useful to make custom dictionaries, scripts, etc. available.
Bundles are not installed as plugins. If you need to upload both a custom plugin and custom dictionaries, you will need to upload the plugin and dictionary separately.
Selected plugins/bundles are downloaded and provided when a node starts. Changing a plugin does not change it for nodes already running it. See Updating Plugins and Bundles.
With great power comes great responsibility: Your plugins can extend your cluster with new functionality, but also make it break. Be careful. We obviously cannot guarantee that your custom code works.
You cannot edit or delete a custom plugin after it has been uploaded. To remove it from your cluster, you can disable the plugin and update your cluster configuration.
Uploaded files cannot be bigger than 20 MB, i.e. 20971520 bytes.
It is important that plugins and dictionaries that you reference in mappings and configurations are available at all times. If you try to upgrade Elasticsearch and for example de-select a dictionary that is referenced in your mapping, the new nodes will be unable to recover the cluster state and function. This is true even if the dictionary is referenced by an empty index you do not actually use.
We expect the scripts will be under
/scripts and dictionaries under
/dictionaries in the root of your zipped bundles.
Here is an example of two bundles which contain a script and a dictionary of synonyms.
$ tree . . └── scripts └── test.groovy
test.groovy can be referred in queries as
$ tree . . └── dictionaries └── synonyms.txt
synonyms.txt can be used as
synonyms.txt in the
synonyms_path of the
You must upload your files before applying them to your cluster configuration.
- Log into the Elastic Cloud Console.
- From the top menu, go to the Plugins page.
- Click New plugin.
- Complete the Name and description fields, including the Elasticsearch version.
- Click Save.
- Under Plugin file, choose the file to upload.
When the files are available in the console, you can simply select them when creating a new cluster. For existing clusters, you’ll need to reconfigure them to use the new files.
- Log into the Elastic Cloud Console.
- Go to the Clusters page and select a cluster.
- On the Configuration page for your cluster, select the custom file.
- Click Update.
While you can update the zip file for any plugin or bundle, this will not update the files on nodes that are already using the plugin or bundle. These are downloaded and made available when a node is started.
For example, to upgrade a plugin or provide a new dictionary, we recommend creating a new plugin/bundle, make your new files available there, and select it when you re-configure your cluster. With this approach, you do not change something you know works, so you can easily roll back if your new files do not work as you expect.