# Controller See also: [How to manage controllers](https://documentation.ubuntu.com/juju/4.0/howto/manage-controllers.md#manage-controllers) 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 boostrap process. - It refers to the initial controller [unit](https://documentation.ubuntu.com/juju/4.0/reference/unit.md#unit) as well as any units added later on (for machine clouds, for the purpose of [high-availability](https://documentation.ubuntu.com/juju/4.0/reference/high-availability.md#high-availability)) – each of which includes - a [unit agent](https://documentation.ubuntu.com/juju/4.0/reference/agent.md#unit-agent), - [`juju-controller`](https://charmhub.io/juju-controller) charm code, and - a [controller agent](https://documentation.ubuntu.com/juju/4.0/reference/agent.md#controller-agent) running, among other things, the Juju API server and an in-process embedded [Dqlite](https://canonical.com/dqlite) [database](https://documentation.ubuntu.com/juju/4.0/reference/database.md#database).

- It is responsible for implementing all the changes defined by a Juju [user](https://documentation.ubuntu.com/juju/4.0/reference/user.md#user) via a Juju client post-bootstrap. - It stores state in the internal Dqlite [database](https://documentation.ubuntu.com/juju/4.0/reference/database.md#database). ## Controller storage A Juju controller has two basic persistent storage needs: [database](https://documentation.ubuntu.com/juju/4.0/reference/database.md#database) access and blob storage. By default, Juju will use the filesystem of the controller’s supporting infrastructure.