Reference

Welcome to Juju Reference docs – our cast of characters (tools, concepts, entities, and processes) for the Juju story!

When you install the juju CLI, and give Juju access to your cloud (which can be any cloud from our long list of supported clouds, Kubernetes or otherwise), your Juju client bootstraps a controller into the cloud.

The controller serves the Juju API. You can also interact with it via the Juju dashboard, the Terraform Provider for Juju , Python Libjuju , or JAAS . However you access it, the controller talks to clouds to provision infrastructure for you, and to Charmhub to retrieve charms for you.

If you can access a Juju controller, you are a Juju user. Depending on your access level, you can add further clouds to the controller, or create workspaces known as models, etc., and eventually use the clouds and the charms to deploy, configure, scale, upgrade, etc., applications, or to integrate applications within and between workspaces models and clouds. Possibilities are endless – for example, you can deploy PostgreSQL on a Charmed Kubernetes that’s on a Charmed OpenStack that’s on a bare metal cloud such as MAAS, and then integrate it with an observability stack, to get a cloud-native, observed database on a resource-optimized private cloud with little effort and time.

You don’t have to worry about the infrastructure – the Juju controller agent takes care of all of that automatically for you, with sensible defaults. But, if you care, Juju also lets you manually control availability zones, machines, subnets, spaces, secret backends, storage, SSH keys, etc.

Whatever you provision contains a Juju agent, which is constantly in contact with the controller agent to realize the state you declare to the controller using your Juju client. It does this through workers, a well-known pattern for watching and reacting to changes in state whose asynchronous nature ensures that your cloud operations run smoothly and in parallel.