# Triggers

# Overview

Triggers define how Applications are run. While you can always run an Application manually, Triggers allow you to run Applications automatically on a schedule or in response to some event.

This section will walk you through:

  1. Creating Triggers for your Application
  2. Detail on the types of Triggers CloudWright supports

# Creating a Trigger

To create a Trigger, click on the "Edit" button within the "Triggers" section of the editor sidebar:

Trigers Editor

Then click on the "New Trigger" button.

We'll cover the types of Triggers you configure in the following section.

# Types of Triggers

CloudWright supports the following types of Triggers:

# Cron

Cron Triggers run your Application on a fixed schedule (for example, every minute, or every Tuesday at 4:00 PM). After you create the Trigger and publish, your Application will automatically be run on the schedule you specify.

The Cron Trigger configuration page looks like this:

Configure Cron Trigger

The Name is just a label for the Trigger that will show up in various parts of the CloudWright UI.

You can select from a list of pre-configured Schedules (like "Once every minute"), or use your own custom cron string. On GCP, use 5-part cron syntax. For AWS, use 6-part syntax, with the added part being a the year. crontab.guru is a useful online tool to generate a cron string for you.

The Inputs section allows you to configure a fixed set of inputs that will be passed to your Application on each run.

You can have multiple Cron Triggers for a single Application. Each Trigger can have its own set of inputs.

Cron Triggers are backed by cloud-native products (Cloud Scheduler in the case of GCP, and CloudWatch Events on AWS), meaning they're battle-tested.


HTTP Triggers create a URL that will run your Application when called. The output of your Application will be returned as the response to the HTTP request. There's a lot you can do with this Trigger, so let's list some examples before diving in:

  1. Create a lightweight API endpoint.
  2. Create embeddable webpages that render graphs from live data.
  3. Handle a request from a browser form.

The HTTP Trigger configuration page looks like this:

Configure HTTP Trigger

The HTTP Endpoint Address shows us the auto-generated URL we can use to call our Application.

Under Settings, we see the several mechanisms CloudWright exposes to control access to your Application:

Unauthenticated Public Access does what it says on the label -- it allows anyone with an Internet connection to call your function. While this can be useful, make sure it's what you want before enabling!

IP Controls allow you to restrict access to lists or ranges of IP Addresses using CIDR Notation. In this example, we're allowing traffic from and any IP in the range --

IP Controls Example

With Token Authentication, you can generate long-lived tokens that allow a user to authenticate with your Application. These should be passed as Bearer Tokens in the HTTP request (i.e., in a header of the form Authorization: bearer <token>). If you add or remove tokens, you must publish your Application for the change to take effect.