The Compose App manifest is a YAML file that defines your app’s configuration. This is where you configure a list of tasks and other app-level concerns. Each task can be individually configured for things like retry behavior and HTTP trigger behavior, cron schedules and more.Documentation Index
Fetch the complete documentation index at: https://docs.goldsky.com/llms.txt
Use this file to discover all available pages before exploring further.
App properties
| Property | Type | Required | Description |
|---|---|---|---|
name | string | Yes | Unique app identifier used for API calls. Must start with a lowercase letter, end with a letter or digit, and contain only lowercase letters, digits, and hyphens. |
api_version | string | For deploy | Pins your app to a Compose runtime version. Required by goldsky compose deploy; optional for local dev. Use "stable" if unsure — see Release channels below. |
secrets | array(string) | No | Names of secrets you’ve set for this app (see Secrets) |
env | ENV | No | Environment-specific variables |
tasks | Tasks[] | Yes | List of tasks in your app (must contain at least one task) |
Release channels
api_version pins your app to a Compose runtime version. You can use one of the release channels, or pin to a specific version:
"stable"— the current stable runtime. This is the recommended value for production apps."preview"— the latest pre-release runtime. Use this if you want early access to features that haven’t made it intostableyet. Expect more frequent changes.- A specific semver version (e.g.
"0.3.0") — pin to an exact runtime version. Useful when you want full control over when your app picks up runtime changes. Do not include avprefix. See the changelog for available versions.
api_version is older than the CLI, goldsky compose deploy will warn you and prompt before continuing. Pass -f to skip the prompt.
Basic example
ENV variables
You can set env variables in your manifest, which are injected into your task’s env context property. Env configuration is namespaced by environment, and only the values for the current environment are injected. Currently there are two environments:local, used when running your compose app locally, and cloud, used when your app is running after goldsky compose deploy — see the deploy guide for more.
Values must be strings. For anything sensitive (API keys, private keys), use secrets instead.
Example
Task configuration
Compose apps are made up of tasks, each task in thetasks array defines an executable unit of work and references a typescript file, see Task Authoring for
more details. Tasks can be triggered by HTTP requests from your app,
blockchain events, cron schedules, etc. See more about triggers below. Tasks can also trigger other tasks via the callTask context function
within the task code.
Name validation
App names must start with a lowercase letter, end with a letter or digit, and contain only lowercase letters, digits, and hyphens (e.g.my-app-1).
Task names must start with a letter (or underscore followed by a letter/digit) and contain only letters, digits, and underscores (e.g. fetch_prices, _internal_task).
Task properties
| Property | Type | Required | Description |
|---|---|---|---|
name | string | Yes | Unique task identifier used for API calls |
path | string | Yes | File path to the task module |
triggers | array(object) | No | List of triggers that will run the task. Each trigger type can only appear once per task. |
retry_config | object | No | Task-level retry behavior |
Triggers
Triggers are what runs your Compose tasks, these can be HTTP calls, onchain events, or cron jobs. For more information, see Triggers.Example
If you provide no triggers in your manifest then tasks can only be executed by other tasks.
Retry configuration
When specifying
retry_config, all three fields (max_attempts, initial_interval_ms, backoff_factor) are required. You cannot provide only some of them.- If a task fails, Compose waits
initial_interval_msbefore retrying - Each subsequent retry interval is multiplied by
backoff_factor - Example with above config: 1000ms → 2000ms → 4000ms
- After
max_attemptsfailures, the task is marked as permanently failed - The default retry behaviour is 0 retries (1 attempt, no retries)