Overview of the ArtemisCloud Operator Custom Resource Definitions

In general, a Custom Resource Definition (CRD) is a schema of configuration items that you can modify for a custom Kubernetes object deployed with an Operator. By creating a corresponding Custom Resource (CR) instance, you can specify values for configuration items in the CRD. If you are an Operator developer, what you expose through a CRD essentially becomes the API for how a deployed object is configured and used. You can directly access the CRD through regular HTTP curl commands, because the CRD gets exposed automatically through Kubernetes.

Main broker CRD

You deploy a CR instance based on this CRD to create and configure a broker deployment.

  • The broker_activemqartemis_crd file in the crds directory of the Operator installation archive (Kubernetes CLI installation method)

Address CRD

You deploy a CR instance based on this CRD to create addresses and queues for a broker deployment.

  • The broker_activemqartemisaddress_crd file in the crds directory of the Operator installation archive (Kubernetes CLI installation method)

Scaledown CRD

The Operator automatically creates a CR instance based on this CRD when instantiating a scaledown controller for message migration.

  • The broker_activemqartemisscaledown_crd file in the crds directory of the Operator installation archive (Kubernetes CLI installation method)

Additional resources

Overview of the ActiveMQ Artemis Operator sample Custom Resources

The AMQ Broker Operator archive that you download and extract during installation includes sample Custom Resource (CR) files in the deploy/crs directory. These sample CR files enable you to:

  • Deploy a minimal broker without SSL or clustering.

  • Define addresses.

The broker Operator archive that you download and extract also includes CRs for example deployments in the deploy/examples directory, as listed below.


Basic broker deployment.


Broker deployment with persistent storage.


Deployment of clustered brokers.


Deployment of clustered brokers with persistent storage.


Broker deployment with SSL security.


Broker deployment with SSL security and persistent storage.


Use of asynchronous I/O (AIO) with the broker journal.


Address and queue creation.

Operator deployment notes

This section describes some important considerations when planning an Operator-based deployment

  • Deploying the Custom Resource Definitions (CRDs) that accompany the ActiveMQ Artemis Operator requires cluster administrator privileges for your Kubernetes cluster. When the Operator is deployed, non-administrator users can create broker instances via corresponding Custom Resources (CRs). To enable regular users to deploy CRs, the cluster administrator must first assign roles and permissions to the CRDs. For more information, see Creating cluster roles for Custom Resource Definitions in the Kubernetes documentation.

  • When you update your cluster with the CRDs for the latest Operator version, this update affects all projects in the cluster. Any broker Pods deployed from previous versions of the Operator might become unable to update their status. To fix this issue for an affected project, you must also upgrade that project to use the latest version of the Operator.

  • You cannot create more than one broker deployment in a given Kubernetes project by deploying multiple broker Custom Resource (CR) instances. However, when you have created a broker deployment in a project, you can deploy multiple CR instances for addresses.

  • If you intend to deploy brokers with persistent storage and do not have container-native storage in your Kubernetes cluster, you need to manually provision Persistent Volumes (PVs) and ensure that these are available to be claimed by the Operator. For example, if you want to create a cluster of two brokers with persistent storage (that is, by setting persistenceEnabled=true in your CR), you need to have two persistent volumes available. By default, each broker instance requires storage of 2 GiB.

    If you specify persistenceEnabled=false in your CR, the deployed brokers uses ephemeral storage. Ephemeral storage means that that every time you restart the broker Pods, any existing data is lost.

    For more information about provisioning persistent storage in Kubernetes, see: