N9 Applications and charmed operators

An application is typically a long-running service that is accessible over the network. Applications are the centre of a Juju deployment. Everything within the Juju ecosystem exists to facilitate them.

It’s easiest to think of the term “application” in Juju in the same way you would think of using it day-to-day. Middleware such as database servers (PostgreSQL, MySQL, Percona Cluster, etcd, …), message queues (RabbitMQ) and other utilities (Nagios, Prometheus, …) are all applications. The term has a special meaning within the Juju community, however. It is broader than the ordinary use of the term in computing.

A Juju application is more than a software application

Juju takes care of ensuring that the compute node that they’re being deployed to satisfies the size constraints that you specify, installing them, increasing their scale, setting up their networking and storage capacity rules. This, and other functionality, is provided within software packages called charmed operators.

Alongside your application, Juju executes charm code when triggered. Triggers are typically requests from the administrator, such as:

“The configuration needs to change”
command juju config
description The spark charm provides the ability to dynamically change the memory available to the driver and executors
example juju config spark executor_memory=2g
“Please scale-up this application”
command juju add-unit
description The postgresql charm can detect when its scale is more than 1 and automatically switches itself into a high-availability cluster
example juju add-unit --num-units 2 postgresql
“Allocate a 20GB storage volume to the application unit 0”
command juju add-storage
description The etcd charm can provide an SSD-backed volume on AWS to the etcd application with
example juju add-storage etcd/0 data=ebs-ssd,20G

The Juju project uses an active agent architecture. Juju software agents are running alongside your applications. They periodically execute commands that are provided in software packages called charmed operators.

Differences between a stock software application and a Juju application

A. Applications are scale-independent

An application in the Juju ecosystem can span multiple operating system processes. An HTTP API would probably be considered a Juju application, but that might bundle together several other components.

Some examples:

  • A Ruby on Rails web application might be deployed behind Apache2 and Phusion Passenger.
  • All workers within a Hadoop cluster are considered a single application, although each worker has its unit.

A Juju application can also span multiple compute nodes and/or containers.

Within the Juju community, we use the term machine to cover physical hardware, virtual machines and containers.

To make this clearer, consider an analogy from the desktop. An Electron app is composed of an Internet browser, a node.js runtime and application code. Each of those components is distinct, but they exist as a single unit. That unit is an application.

A final iteration of scale-independence is that Juju will maintain a record for applications that have a scale of 0. Perhaps earlier in the application’s life cycle it was wound down, but the business required that the storage volumes were to be retained.

B. Applications are active

Applications automatically negotiate their configuration depending on their situation. Through the business logic encoded within charmed operators, two applications can create user accounts and passwords between themselves without leaking secrets.

C. Applications are responsive

Juju applications can indicate their status, run actions and provide metrics. An action is typically a script that is useful for running a management task.

Application management tasks

Common application and charm management tasks are summarised below. The most important ones are Deploying applications and Managing relations.

Configure applications

Applications can have their configuration options set during, or after, deployment. The Configuring applications page explains how this is done.

Credentials and application trust

Some applications may require access to the backing cloud to fulfil their purpose. In such cases, the credential associated with the current model would need to be shared with the application. See section Trusting an application with a credential for details.

Deploy applications

The Deploying applications page covers an array of methods for getting your applications deployed.

The Deploying applications - advanced page contains more advanced use cases.

See the Deploying charms offline page for guidance when deploying in a network-restricted environment.

Applications can be deployed and configured as a collection of charmed operators. This subject is treated on the Charmed bundles page.

Display information for deployed applications

Once an application is deployed it is possible to display information on it. This is done with the show-application command. For example, you could deploy an application with:

juju deploy postgresql pgsql

After it is deployed, you can get information about it:

juju show-application pgsql

Sample output:

  charm: postgresql
  series: bionic
  channel: stable
  principal: true
  exposed: false
  remote: false
    coordinator: ""
    data: ""
    db: ""
    db-admin: ""
    local-monitors: ""
    master: ""
    nrpe-external-master: ""
    replication: ""
    syslog: ""

Relate applications

When an application requires another application to fulfil its purpose they need to be logically linked together. In Juju, such a link is called a relation . The Managing relations page explains this important concept.

Remove applications

Removing an application is a simple process. See the Removing things page for guidance.

Scale applications

Juju horizontally scales applications up and down by adding and removing application units. See the Scaling applications page for details.

Upgrade an application

Upgrading an application in Juju means to upgrade the application’s charm. See the Upgrading applications page for in-depth coverage.

Related Concepts


Actions are charm-specific code which can be called at will from the command line. Working with actions page provides full coverage of the subject.

Application groups

Application groups allow an administrator to manage groups of the same application by providing custom application names during deployment. See the Application groups page for details.

Application high availability

Application high availability pertains to the distribution of units over availability zones. See the Application high availability page for full information.

Application metrics

Metrics for applications can be collected for model-level assessment of application utilisation and capacity planning. See the Application metrics page to learn more.


Constraints are used to specify minimum requirements for the machine that will host an application. See page Using constraints for details.


A Juju resource is additional content/files that a charm can make use of, or may even require to run. See the Working with resources page for details.


Certain applications can benefit from advanced storage configurations and if a charm exists for such an application Juju can declare such requirements both at deploy time and during the lifetime of the application. See the Using storage page for more detail.

I think it’s worth explicitly adding: or “charms”.

This command is named “add-storage”, whereas the others above have the "juju " prefix. Perhaps change to “juju add-storage” for consistency.

Missing “the” before “charmed operator”.

I guess strictly speaking they are “bits”, as in 0’s and 1’s … but this lingo seems a bit informal for this context. Perhaps “pieces of code” or “functions”?

All the other sections have at least a sentence or paragraph, whereas this is just a link. Expand?

1 Like