How to install Elastic Stack 9.4.6 released

What happened

Version 9.4.6 of the Elastic Stack was released today, and Elastic recommends that you upgrade to this latest version. The publisher is explicit that 9.4.6 is the build to run rather than remaining on the previous versions 9.4.5, and the announcement frames the drop as a maintenance release you should take, not a feature tour you can postpone.

The Elastic Blog summary does not enumerate tickets in the post itself. For details of the issues that have been fixed and a full list of changes for each product in this version, you are told to refer to the release notes. The 9.4.6 release contains fixes for potential security vulnerabilities, and Elastic points readers to the related discussion on discuss.elastic for that security context. Treat those two sources as the only authoritative change list for this cut.

Elastic published Elastic Stack 9.4.6 as the current recommended stack build. The only versions named in the announcement are 9.4.6 as the new release and 9.4.5 as the previous line you are being asked to leave. Nothing in the public summary claims a new major series, a new minor series, or a new product family. What shipped is a patched stack: the same 9.4 product set, with fixes applied, including fixes for potential security vulnerabilities.

Because the blog post defers the inventory of fixes to the release notes, do not assume a product was untouched just because it is not named in the short announcement. Open the 9.4.6 notes for each product you actually run and confirm whether that product has a 9.4.6 artifact. If a product in your cluster has a 9.4.6 build, plan to take it. If a product has no 9.4.6 artifact in the notes, leave that product on its current 9.4.5 build until the notes say otherwise. The stack recommendation is still 9.4.6 over 9.4.5 for every product that did ship a 9.4.6 package.

How it works

The security language is the other shipped fact that should change your calendar. A release that contains fixes for potential security vulnerabilities is an upgrade you schedule, not an upgrade you park behind a feature freeze. Pair the notes with the discuss.elastic thread referenced in the announcement so operators and security owners are reading the same advisory text.

Builders who already standardized on 9.4.5 should treat 9.4.6 as a patch of the same minor line, not as a redesign of cluster topology, index mappings, or client APIs. The announcement does not describe new APIs, new default settings, or new required configuration keys. What changed is the recommended binary: stop installing 9.4.5, start installing 9.4.6, and move running 9.4.5 nodes onto 9.4.6.

That still has work attached. Pin installers, container tags, Helm values, configuration management versions, and golden images to 9.4.6 so a rebuild does not silently pull 9.4.5. Update any internal runbook that still says to stay on 9.4.5. If your pipeline verifies a stack version string in tests or in a smoke check, change the expected string to 9.4.6 after the upgrade, not before, so a half-migrated environment fails closed.

Because the 9.4.6 release contains fixes for potential security vulnerabilities, builders who produce downstream images should rebuild those images from 9.4.6 and retire images that still embed 9.4.5. Do not leave a 9.4.5 node in a mixed cluster as a long-term state. Mixed running is a rolling-upgrade tactic, not the destination. The destination Elastic recommends is 9.4.6.

Why it matters

Read the per-product 9.4.6 release notes before you change application code. If the notes for a product you ship against list a behavioral fix, add a regression check for that behavior. If they do not, do not invent a code change. The announcement gives you a version target and a security reason to move, not a list of breaking builder APIs.

Start by reading the 9.4.6 release notes for every product in your deployment and by reading the security discussion Elastic linked from the announcement on discuss.elastic. Confirm that 9.4.6 is the version you intend to install and that you are leaving 9.4.5. Snapshot Elasticsearch data and save Kibana saved objects, keystore files, certificates, and elasticsearch.yml, kibana.yml, and related config so you can roll back to 9.4.5 if the new process will not start. Record the current cluster health and node version list so you can prove every node left 9.4.5.

For a new install, download the 9.4.6 packages or images for the products you need, not 9.4.5. Install Elasticsearch 9.4.6 first, apply your existing config and keystore, start the node, and confirm it reports 9.4.6. Install Kibana 9.4.6 against that cluster next, then install or replace any remaining stack products that have a 9.4.6 build, always using 9.4.6 artifacts. Do not mix a fresh 9.4.6 Elasticsearch with a leftover 9.4.5 Kibana on a greenfield install.

For an upgrade from 9.4.5, take the snapshot first, then upgrade Elasticsearch nodes to 9.4.6 before Kibana and before ingest. On a multi-node cluster, use a rolling upgrade: exclude or stop one 9.4.5 node, install 9.4.6 on that node, start it, wait until the cluster is green or yellow in the state you accept, then repeat until no 9.4.5 Elasticsearch node remains. After Elasticsearch is entirely on 9.4.6, upgrade Kibana from 9.4.5 to 9.4.6. Then upgrade Logstash, Beats, Elastic Agent, and any other stack product you run that has a 9.4.6 package, one product family at a time, replacing 9.4.5 with 9.4.6. Restart each upgraded process and confirm the version string is 9.4.6.

Who is affected

On a single-node lab, stop the 9.4.5 processes, install 9.4.6 over the same config and data paths, and start Elasticsearch 9.4.6 before Kibana 9.4.6. Do not delete data directories as part of a 9.4.5 to 9.4.6 patch. After every node and product is on 9.4.6, run a search, an index write, and a Kibana login, and confirm monitoring no longer reports 9.4.5. Keep the 9.4.5 packages available until that verification passes so a rollback is a process swap, not a scavenger hunt.

If you install from a package repository, point the repository at the 9.4.6 artifacts and upgrade with the same package manager you used for 9.4.5. If you install from containers, change the image tag to 9.4.6 and roll the workload so old 9.4.5 containers exit. If you install from archives, unpack 9.4.6 beside the 9.4.5 directory, copy config and keystore, and switch the service unit to the 9.4.6 path. In every channel the version you install must be 9.4.6.

The announcement recommends 9.4.6 over the previous versions 9.4.5 and does not describe a cross-major jump. Compatibility work is therefore about not mixing leftover 9.4.5 binaries with 9.4.6, not about inventing a new major-version migration. The common failure is upgrading Kibana to 9.4.6 while Elasticsearch is still on 9.4.5, or the reverse. Keep Elasticsearch on 9.4.6 first, then Kibana 9.4.6, then ingest.

Clients, ingest pipelines, and plugins that were accepted on 9.4.5 should be rechecked against the 9.4.6 notes for each product. If a plugin is version-locked to 9.4.5, obtain a 9.4.6 build of that plugin before you cut over or you will start Elasticsearch 9.4.6 and watch it refuse the old plugin. Do not assume a 9.4.5 plugin loads. Config files from 9.4.5 are the right starting point for 9.4.6, but after the upgrade, look for deprecation log lines instead of assuming silence.

What to watch next

Because the 9.4.6 release contains fixes for potential security vulnerabilities, a node left on 9.4.5 is not a compatible peer you can keep for capacity. Finish the roll. If you must pause, pause between Elasticsearch nodes during a rolling upgrade, not with Kibana on a different version than Elasticsearch. Refer to the release notes when a product behaves differently after the upgrade; the blog summary will not name the issue for you.

Watch the cluster until every product you run reports 9.4.6 and nothing still reports 9.4.5. Watch logs for failed plugin loads, certificate errors, and repeated restarts after the binary change. Watch that snapshots taken before the upgrade still restore, so a return to 9.4.5 remains possible if 9.4.6 will not stay up.

Watch the 9.4.6 release notes and the discuss.elastic security thread after you cut over, in case Elastic adds follow-up guidance for the same vulnerabilities. Watch your own installers so a later provision does not pull 9.4.5 from a cached image or an unpinned package. The recommendation from Elastic is already stated: run 9.4.6, not 9.4.5, and use the notes plus the security discussion for the detail the announcement itself does not list.