Triggers

Triggers in Heim decides how the application should be executed and under what premise.
We currently doesn’t support a mix of different triggers in a single Heim-application, but you can have multiple of the same trigger type in an application if it contains Cron- or Http-triggers.

You also have a limitation of how many applications you can have with a Cron or Job-trigger as well, and this Organization-limits can be found under your Organization in Heim-portal.

Http Trigger

An HTTP trigger is a way to invoke an application through HTTP requests. It creates a publicly accessible endpoint that responds to web requests. HTTP triggers are typically used for webhooks, API endpoints, and serverless functions that need to respond to incoming HTTP requests.

Method: The HTTP method (GET, POST, PUT, PATCH, DELETE, or ALL) Path: The URL path where the trigger is accessible (e.g., /api/webhook) Full URL: Combines with the deployment domain (e.g., https://asgdfs55sd4gs.cloud.heim.dev/api/webhook)

HTTP triggers include Cross-Origin Resource Sharing (CORS) configuration to control browser-based access:

Allowed Origins: List of domains permitted to access the endpoint (e.g., https://upcloud.com)
Allowed Headers: HTTP headers that can be included in requests (e.g., Content-Type, Authorization)

Example http trigger configuration:

[[trigger]]
type = 'http'
path = '/test/api/*'
method = 'GET'

This will create a HTTP trigger that will trigger on the HTTP method GET and on the path /test/api/*. The * means is a wildcard which means it will trigger on any path following the initial path of /test/api/.

Cron Trigger

CRON triggers are ideal for any task that needs to run automatically on a predictable schedule without manual intervention.

Required fields:

schedule: Cron-expression 6-digit representation see description below.
timeout: execution-timeout in seconds, max allowed value is bounded Organization-limits

Common Use Cases:

Scheduled reports: Generate and send reports daily, weekly, or monthly
Data cleanup: Run maintenance tasks at off-peak hours
Batch processing: Process accumulated data at regular intervals
Automated backups: Schedule regular data backups
Periodic checks: Monitor external services or APIs at set times

Cron Expression (6-digit representation): The schedule is defined using five space-separated fields that determine when the trigger fires:

Second (0-59): Which second of the minute
Minute (0-59): Which minute of the hour
Hour (0-23): Which hour of the day
Day (1-31): Which day of the month
Month (1-12): Which month of the year
Weekday (0-7): Which day of the week (0 and 7 are both Sunday)

Each field can contain:

A specific value (e.g., 5 for “at 5”)
An asterisk * meaning “every” (e.g., “ in the minute field means “every minute”)
Ranges (e.g., 1-5)
Lists (e.g., 1,3,5)
Step values (e.g., */15 for “every 15 minutes”)

Example cron trigger configuration:

[[trigger]]
type = 'cron'
schedule = '0 */2 * * * *'
timeout = 60

Job Trigger

Job triggers are a work-load that only gets executed on-command, so each execution gets queued up either by API or through Heim-portal.
This is also the only executable that accepts regular command-line arguments for each execution.
Limited to maximum queue-size and how many executions you are allow per month.

Required fields:

timeout: execution-timeout in seconds, max allowed value is bounded Organization-limits
allow_parallel: if you allow running multiple instance of queued jobs on the same node, for most use-cases this will be true.

Common Use Cases:

Off-loaded request: For images-transforms performed after a user sets a profile picture and the images is not needed directly.

Example job trigger configuration:

[[trigger]]
type = 'job'
allow_parallel = true
timeout = 60

Long-Running Trigger

Example long-running trigger configuration:

[[trigger]]
type = 'long-running'