Overview of different methods to update Bottlerocket

Bottlerocket is designed to be updated in an image-based fashion. This means that updates are applied by downloading an image of the entire operating system to a different partition on disk, then switching to using that partition when the system is rebooted. This is done instead of a series of individual package updates on the current operating system partition. This is a departure from the traditional package-based Linux update model such as apt or yum, which are what you would find in Ubuntu or Amazon Linux.

Ways To Update

The update method you choose depends on the Bottlerocket variant you are using and your environment.

The ways to update Bottlerocket can be classified into two main categories: in-place updates and node replacement. In-place updates are updates that are applied to the same node (no infrastructure reprovisioning), while node replacement is when you replace an existing node with a new node that is running the updated version of Bottlerocket.

At its core, an in-place update is a call to the Bottlerocket API server using apiclient. The apiclient command can be run from the control container. There are also orchestrated systems that perform the apiclient calls for you: the ECS updater for ECS, Brupop for Kubernetes, and SSM Command Documents for both.

The following table shows whether a given update method is an in-place update or a node replacement.

In-Place UpdatesNode Replacement
apiclient commandsEKS Console
ECS updatereksctl
SSM command documents


There are many ways to update Bottlerocket, including:

It is also possible to lock your nodes to a specific release.

See a problem with this page? File an issue. All feedback is appreciated.
You can also directly contribute a change to the source file of this page on GitHub.