See also: How to manage controllers

Controller state storage changes starting with Juju 4:

Starting with Juju 4, Juju will replace MongoDB with Dqlite. In a production setting, make sure to specify an external object store provider for blob storage.

See more

A Juju controller has two basic persistent storage needs: database access and blob storage. MongoDB satisfied both. However, Dqlite will only satisfy the former – for blob storage the Juju controller will require an external object store.

By default, Juju will use the filesystem of the controller’s supporting infrastructure. However, you can also use object-store-related controller configuration keys to specify any object store (highly recommended in a production setting!) you want, so long as it is S3-compatible (e.g., AWS S3, MicroCeph, MinIO, etc.), either during bootstrap or later.

Also, Juju will apply default S3 policy permissions, but you are free to change them, so long as they satisfy the following as a minimum (at least, during model creation):

   "Version" : "2012-10-17",
   "Statement" : [
         "Effect" : "Allow",
         "Action" : [ 
         "Resource" : "arn:aws:s3:::*"
         "Effect" : "Allow",
         "Action" : [ 
         "Resource" : "arn:aws:s3:::*"

In software design, a controller is an architectural component responsible for managing the flow of data and interactions within a system, and for mediating between different parts of the system. In Juju, it is defined in the same way, with the mention that:

  • It is set up via the bootstrap process.

  • It refers to the initial controller unit as well as any units added later on (for machine clouds, for the purpose of high-availability) – each of which includes
  • It is responsible for implementing all the changes defined by a Juju user via a Juju client post-bootstrap.
  • It stores state in an internal MongoDB database.

Contributors: @simonrichardson, @tmihoc

Last updated a month ago. Help improve this document in the forum.