Skip to content

TriggerMesh Installation

The TriggerMesh Cloud Native Integration Platform is composed of a set of APIs implemented as Kubernetes Custom Resource Definitions (CRDs) and a controller.

Installing TriggerMesh consists of:

  • Having a Kubernetes cluster up and running
  • Having the Knative project deployed in that cluster
  • Installing the TriggerMesh CRDs
  • Installing the TriggerMesh controller

These four steps are highlighted below. The first two steps (i.e Access to a Kubernetes cluster and installation of Knative are not described in details in this documentation). After completing those four steps you can validate your TriggerMesh installation.

Alternative Installation Options

You may also use the TriggerMesh AMI to test the platform in a AWS EC2 instance. You may also use our Helm Chart.


The Knative project is a dependency of TriggerMesh, install it using the instructions in the Knative documentation

  • A Kubernetes cluster version v1.22+
  • Knative v1.4.0+

If you are using VMware's Tanzu Community Edition, please refer to the Installation for Tanzu Community Edition.

Install the CRDs

All TriggerMersh APIs are implemented as Kubernetes CRDs, which we need to create before deploying the controller. The following kubectl apply command will create all of the CRDs.

kubectl apply -f

Install the controller

By default, the controller gets deployed in the triggermesh namespace. Deploy the controller with the following kubectl apply command:

kubectl apply -f

Verifying the installation

Upon successful creation of the CRDs and successful deployment of the controller you should see two pods running in the triggermesh namespace

$ kubectl get pods -n triggermesh
NAME                                                   READY   STATUS    RESTARTS   AGE
triggermesh-controller-5cd97f4c8f-z6r2r                1/1     Running   0          57m
triggermesh-webhook-79cd8d6f5d-gf2lj                   1/1     Running   0          57m

All event sources and targets will be available to you as new API objects. For example, you can list all AWS related sources and targets with:

$ kubectl get crds |grep triggermesh |grep aws         2021-10-06T09:01:27Z             2021-10-06T09:01:27Z             2021-10-06T09:01:27Z        2021-10-06T09:01:27Z        2021-10-06T09:01:27Z             2021-10-06T09:01:28Z               2021-10-06T09:01:28Z               2021-10-06T09:01:28Z            2021-10-06T09:01:28Z                2021-10-06T09:01:28Z                2021-10-06T09:01:29Z                 2021-10-06T09:01:29Z    2021-10-06T09:01:29Z                     2021-10-06T09:01:29Z                     2021-10-06T09:01:29Z                    2021-10-06T09:01:30Z                    2021-10-06T09:01:30Z                    2021-10-06T09:01:30Z                    2021-10-06T09:01:30Z

A handy way to start exploring the API is to use kubectl explain on a specific kind, for example the AWS SQS source like below:

$ kubectl explain awssqssources
KIND:     AWSSQSSource

     TriggerMesh event source for Amazon SQS.
   apiVersion   <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:

   kind <string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:

   metadata <Object>
     Standard object's metadata. More info:

   spec <Object>
     Desired state of the event source.

   status   <Object>
     Reported status of the event source.