An action is functionality defined by a charmed operator for its applications. Administrators can run actions via the client.


The administrator is the person interacting with the client. Administrators are typically the admin user, but may be other users.

Admin user

The admin user is created during the bootstrap process. This account has all privileges across all models.


An agent is a running instance of jujud. Agents perform different roles and are often described in those terms. There are controller agents, unit agents, and machine agents.

Agent binary

The jujud executable binary that’s produced at each release is known as the agent binary. Every agent is a running instance of the agent binary.


The bootstrap process establishes the controller on the cloud.

Bootstrap Constraint

A constraint placed on the bootstrap machine.

Bootstrap machine

The machine used to host the controller agent and essential infrastructure, such as juju-db, is the bootstrap machine. This is machine 0 of the controller model.


A bundle is a YAML file that describes a complete deployment. That deployment may consist of multiple charms, their applications, constraints, and relations.


A charmed operator is software that responds to hooks triggered by agents. charmed operators also define actions, relations and metrics.

There are two strategies for charmed operator writing. The recommended approach is to use the reactive charmed operator framework. An alternative strategy is to use individual scripts to respond to each charmed operator hook.

Charmed operator hook

Charmed operator hooks are an important implementation detail of how charms work. During the lifecycle of an application and its units, the controller execute files within a charm’s hooks directory.

Charmed operator hooks have access to hook tools for implementing their business logic.


The juju executable binary. Command-line client that operators interact with.

The client/server terminology originates from Juju’s technical architecture. Running a Juju sub-command, such as juju status, involves connecting to a controller agent.


Constraints are minimum specifications that operators indicate to Juju. When adding units, Juju attempts to use the smallest instance type on the cloud that satisfies all of the constraints.

Constraints are not specific to individual machines, but the whole application. Bootstrap constraints can also be applied during the bootstrap process.


The controller, sometimes referred to as the controller agent, is responsible for implementing changes that are defined by operators. The controller is central to Juju. As well as altering

The controller’s privilege level is restricted when the user’s does not have admin responsibilities.


Authentication credentials to allow Juju to interact programatically with a cloud.

Default model

The model created as part of the bootstrap process.


A Juju deployment consists of the controller model and all of the models models under its control.

The term deployment is also used in a second sense. When an operator uses Juju to deploy a product or service, the deployment covers all models that work to provide that product or service.


An instance is an machine. Normally associated with virtual hardware and tied to an instance type.

Instance type

Instance types are identifiers designated by cloud providers that relate to specifications. When adding units, Juju will attempt to pick the smallest—and therefore cheapest&mdashinstance type that satisfies the unit’s constraints.

Hook tools

Charmed operator hooks interact with the model via hook tools. They are utilities which query and set


The client binary that operators interact with on the command line.


The agent binary.


A metric is a key/value pair defined by a charm. Typically the value is numeric.

Juju polls charmed operators every 5 minutes via the collect-metrics charmed operator hook.


The model is the central abstraction provided by Juju. Models house applications, manage their relations. Models allow a set of applications to be treated as a single entity.

A digital product, such as a website or web service, typically requires several interdependent components to all be available for the product to function. A typical web application sits behind multiple caching layers and stores its data within a database. An ecommerce web application might talk to a fraud detection system, a payment gateway and perhaps also interact with an customer relationship management (CRM) and/or enterprise resource plannind (ERP) system. A Juju model encapsulates all of the components and allows you to treat them as a cohesive unit.

Consider a whiteboard drawing of a digital product. The model is the whiteboard itself, the applications are the main circles and relations are the lines between them.

The model’s main roles are to decrease the cognitive load of understanding the deployment and to allow seperate concerns to be treated differently.

All applications are affected by the model’s model-config settings.

A model maintains exclusive access to the machines that its applications’ units use.

Before Juju 2.0, models were known as environments.


A relation is a relationship between two applications. Relations are directed. One application is the provider and the other is the consumer.


A (network) space is a network partition, protected by firewall rules.

Spaces can use used as a constraint.


Storage, within Juju, means a machine-independent data volume that is provided by the cloud.

Charmed operators can be made to be storage-aware, allowing data storage that persists beyond the lifetime of any given machine.


A user of the Juju client.

Placement Directive

A placement directive specifies which unit to deploy an application to. Commonly used to deploy multiple applications in the same unit.


An external command that works with Juju. When the client subcommand Juju looks for any executable with the prefix juju-<plugin> For example, when an operator executes juju smoketest, Juju will look for an executable named juju-smoketest on your $PATH.


The term “user” has two meanings within Juju. The plain language definition of “a person interacting with Juju” is most common. A more technical definition is that of a registered user, who has access levels constrained on a per model basis. To distinguish the two senses of the word, we also use the term operator to refer to people.

The alternative meaning relates to accounts. For example, the account created the bootstrap process is known as the admin user.

First of all - anchor links do not work

Interation between applications is handled by relations.

Interation -> Interaction


A user the Juju client.

Don’t understand this line

The machine used to host the controller agent and essential infrastructure, such as juju-db,

There is no glossary term for juju-db

nstance types are identifiers designated by cloud providers that relate to specifications.
When adding units, Juju will attempt to pick the smallest—and therefore cheapest&mdashinstance type that satisfies the unit’s constraints.

remove &mdash

There are some others, but honestly, I suggest to remove this doc entirely in favour of this - Juju | Concepts and terms, I think it has a lot more focused glossary with complete info