See also:

A Juju (network) space is a logical grouping of subnets that can communicate with one another.

A space is used to help segment network traffic for the purpose of:

  • Network performance
  • Security
  • Controlling the scope of regulatory compliance

Spaces can be specified as constraints—to determine what subnets a machine is connected to—or as bindings—to determine the subnets used by application relations.


Space support

From the point of view of Juju, space support by the various providers falls into one of three situations.

Spaces inherited from the substrate

The first situation is when spaces are inherited from the substrate. This is the case for MAAS, as described below.


The concept of spaces is native to MAAS and its API can be used to modify the space/subnet topology. As such, Juju does not permit the editing of spaces in a MAAS model. MAAS spaces and subnets are read and loaded into Juju when a new model is created.

If spaces or subnets are changed in MAAS, they can be reloaded into Juju via the reload-spaces command.

The reload-spaces command does not currently pull in all information. This is being worked upon. See LP #1747998.

For other providers, reload-spaces will fall back to refreshing the known subnets if subnet discovery is supported. One scenario for this usage would be adding a subnet to the AWS VPC that Juju is using, then issuing the command so that the new subnet is available for association with a Juju space.

Subnets inherited from the substrate

The second situation is when subnets are inherited from the substrate, to be grouped into spaces at the discretion of the Juju administrator. This is the case for EC2, OpenStack and Azure, and LXD, as described below.


Machines on Amazon EC2 are provisioned with a single network device. At this time, specifying multiple space constraints and/or bindings will result in selection of a single intersecting space in order to provision the machine.

OpenStack and Azure

The OpenStack and Azure providers support multiple network devices. Supplying multiple space constraints and/or bindings will provision machines with NICs in subnets representing the union of specified spaces.


LXD will automatically detect any subnets belonging to bridge networks that it has access to. It is up to the Juju user to define spaces using these subnets.

Subnets discovered progressively

The third situation is when subnets are discovered progressively, as machines are added. This is the case for the Manual provider, as described below.


The Manual provider space support differs somewhat to other providers. The reload-spaces command does not discover subnets. Instead, each time a manual machine is provisioned, its discovered network devices are used to update Juju’s known subnet list.

Accordingly, the machines to be used in a manual cloud must be provisioned by Juju before their subnets can be grouped into spaces. When provisioning a machine results in discovery of a new subnet, that subnet will reside in the alpha space.

Listing spaces and subnets

Spaces can be viewed with the spaces command. This example comes from a new AWS model.

juju spaces
Name   Space ID  Subnets
alpha  0

Similarly for subnets.

juju subnets
    type: ipv4
    provider-id: subnet-9b4ed4fc
    provider-network-id: vpc-54a7112e
    status: in-use
    space: alpha
    * us-east-1c
    type: ipv4
    provider-id: subnet-eca389a6
    provider-network-id: vpc-54a7112e
    status: in-use
    space: alpha
    * us-east-1a

Modifying spaces

For non-MAAS providers, all subnets are initially in a default “alpha” space. Juju operators are able to create, rename, or delete spaces, and move subnets between them.

Spaces are created with the add-space command. The following command creates a new space called “db-space” and associates the subnet with it.

juju add-space db-space
added space "db-space" with subnets

Subnets can be moved between spaces with the move-to-space command.

juju move-to-space db-space
Subnet moved from alpha to db-space

Spaces can be renamed.

juju rename-space db-space public-space
renamed space "db-space" to "public-space"

Deleting a space will cause any subnets in it to move back to the “alpha” space.

juju remove-space public-space
removed space "public-space"

Using spaces


Space names are valid values for the controller configuration items:

  • juju-ha-space
  • juju-mgmt-space

A space name can also be specified for the value of default-space in model-configuration.


Spaces can be specified as constraints or bindings to affect application deployments and machine provisioning.

Space constraints affect what subnets a machine is connected to.

A binding associates a space with an application endpoint. This restricts traffic for the endpoint to the subnets in the space.

Endpoint bindings can be changed after deployment using the juju bind command.

By default, endpoints are bound to the space specified in the default-space model configuration value. The default for this setting is “alpha”.

I’ve just given this page a refresh, but I couldn’t find a concise definition of an application “endpoint” in the docs, which is a deficiency. We should create such a doc and include a link in the bindings section.

@manadart This page has it.

Concepts and terms

1 Like

The link takes us to “Basic juju concepts” page. Would be great to link to a page where an “application end-point” is specifically defined. There’s a mention of an application end-point here:, though perhaps it could also be explicitly defined either there or on a separate page?

1 Like

We do have this doc on endpoints: . I’ll add a link to it at the top of this doc.