Workflows

Workflows let you create backend automation beside the app code in a workspace.

Use the workflow deployment page to review use cases, trigger choices, failure checks, application templates, and the production decision path before implementing the manifest below.

Workflow adios.yaml

A workflow manifest describes triggers, shared context, secrets, and ordered steps. In a workflow-only repository you can name the file adios.yaml. In an application repository, keep the app runtime manifest at the project root and store workflow manifests under a directory such as workflows/.

workflow_id: daily-market-brief
title: Daily market brief
team_id: team-local
enabled: true
version: "1"

triggers:
  - type: cron
    cron: "0 13 * * 1-5"
    timezone: America/New_York
    concurrency: forbid
  - type: webhook
    event: market.brief.requested

context:
  market_api_url: https://api.example.com
  symbols:
    - AAPL
    - MSFT
    - NVDA

secrets:
  MARKET_DATA_API_KEY: secret://MARKET_DATA_API_KEY

steps:
  - step_id: fetch-prices
    name: Fetch prices
    kind: http
    command:
      method: GET
      url: "{{ .context.market_api_url }}/quotes?symbols=AAPL,MSFT,NVDA"
      headers:
        Authorization: "Bearer secret://MARKET_DATA_API_KEY"

  - step_id: select-close
    name: Select close prices
    kind: data-json
    dependencies:
      - fetch-prices
    command:
      from_step: fetch-prices
      path: ".quotes"

  - step_id: publish-brief
    name: Publish brief
    kind: http
    dependencies:
      - select-close
    command:
      method: POST
      url: https://dashboard.example.com/api/market-briefs
      body:
        source: adios-workflow
        quotes: "{{ index .steps \"select-close\" \"value\" }}"

Use secret://NAME for values that should come from Adios secrets. Step templates can read the workflow context, trigger payload, request data, and previous step outputs.

Common trigger types are webhook, event, cron, and schedule. Common platform step kinds are http, data-json, wait, bash, python, sql, email, s3, and request-parser. For local CLI testing, start with http, data-json, wait, bash, and python steps.

Create

Use the workflow builder or the AI agent to create workflows for:

• deployment gates
• scheduled database backups
• webhook transforms
• security reviews
• cleanup and maintenance jobs
• approval-based operations

Create or apply this manifest from the workflow builder, the AI agent, or the workflow CLI. The local CLI runner is useful for simple development checks, but it supports a subset of platform step kinds.

adios workflow deploy ./workflows/daily-market-brief.yaml

Trigger

Workflows can start from:

• webhook requests
• internal events
• cron or scheduled triggers
• manual runs from the UI or CLI

Execute

Workflow steps can call HTTP endpoints, transform JSON data, wait, request approval, or run exec steps. Exec steps run commands or scripts as tracked workflow steps, with logs, status, inputs, outputs, and errors attached to the run.

Inspect

Each run records step state and output so the Web IDE can show what happened after the original request has ended. Use this for long-running jobs, deploy reviews, backups, and operational automation.