How does IBM Cloud Functions compare to Code Engine?

Cloud Functions is OpenWhisk-based — actions are small short-lived scripts written in supported runtimes (Node.js, Python, etc.) and orchestrated via triggers, rules, and sequences. Code Engine is container-based — you bring a container image and run it as an app or job. For tiny event-driven glue code, Cloud Functions is right; for anything beyond a single function (multi-route web apps, batch jobs with custom dependencies), Code Engine is right.

What's a 'sequence' vs. just calling one action from another?

A sequence is a declarative composition — the platform handles the chain. Calling one action from another inside your code creates an implicit dependency that the platform doesn't see, which limits observability and retry behavior. Sequences are also explicit in the dashboard, making the workflow understandable to other engineers.

IBM Cloud Functions Config Builder

ServerlessIBM Cloud

Build Cloud Functions configurations with packages, actions, triggers, rules, and sequences.

Last verified: May 2026

IBM Cloud Functions Configuration

Build Cloud Functions configurations with packages, actions, triggers, rules, and sequences for event-driven serverless workloads.

Required Fields

namespacepackages

{
  "namespace": "prod-functions",
  "resourceGroup": "prod-resources",
  "region": "us-south",
  "packages": [
    {
      "name": "data-processing",
      "description": "Data processing functions for ETL pipeline",
      "parameters": [
        { "key": "COS_BUCKET", "value": "incoming-data" },
        { "key": "COS_ENDPOINT", "value": "s3.us-south.cloud-object-storage.appdomain.cloud" }
      ],
      "actions": [
        {
          "name": "process-csv",
          "runtime": "python:3.11",
          "memory": 512,
          "timeout": 300000,
          "webAction": false,
          "parameters": [
            { "key": "MAX_ROWS", "value": "10000" }
          ]
        },
        {
          "name": "transform-json",
          "runtime": "nodejs:20",
          "memory": 256,
          "timeout": 60000,
          "webAction": true
        }
      ]
    }
  ],
  "triggers": [
    {
      "name": "cos-upload-trigger",
      "feed": "/whisk.system/cos/changes",
      "parameters": [
        { "key": "bucket", "value": "incoming-data" },
        { "key": "event_types", "value": "write" }
      ]
    },
    {
      "name": "hourly-trigger",
      "feed": "/whisk.system/alarms/alarm",
      "parameters": [
        { "key": "cron", "value": "0 * * * *" },
        { "key": "timezone", "value": "America/New_York" }
      ]
    }
  ],
  "rules": [
    {
      "name": "process-on-upload",
      "trigger": "cos-upload-trigger",
      "action": "data-processing/process-csv"
    },
    {
      "name": "hourly-transform",
      "trigger": "hourly-trigger",
      "action": "data-processing/transform-json"
    }
  ],
  "sequences": [
    {
      "name": "etl-pipeline",
      "actions": ["data-processing/process-csv", "data-processing/transform-json"]
    }
  ]
}

Generated Output

Output will appear here...

See It in Action

Your team needs to process uploaded customer files: validate, extract metadata, kick off downstream processing, notify Slack on errors. Rather than building this as a long-running service, you compose it as Cloud Functions: a COS event triggers a validation action, which is part of a sequence including metadata extraction and routing. Total infrastructure to maintain: zero — Cloud Functions scales to and from zero automatically.

What This Tool Does

IBM Cloud Functions is the OpenWhisk-based serverless runtime — packages, actions, triggers, rules, and sequences compose into event-driven systems without managing runtime infrastructure. The IBM Cloud Functions Config Builder produces complete namespace and package configurations including action runtimes, trigger feeds, and rule bindings. Output is Terraform-ready and matches the parameters expected by IBM Cloud Functions resources.

Technical Details

The builder collects namespace name, resource group, and a list of packages with their actions, triggers, rules, and sequences. Each action specifies runtime, source, memory, timeout, and parameters. The output is structured to match the IBM Cloud Functions Terraform resources where available, with a fallback to `ibmcloud fn` CLI commands for elements the provider doesn't yet support.

Common Use Cases

1Building a small event-driven workflow where a Cloud Object Storage event triggers an action that processes the object and writes metadata to Cloudant.
2Composing multiple actions into a sequence — the output of one feeds the next — for a multi-step processing pipeline.
3Setting up a scheduled trigger (alarm feed) that fires an action on a cron schedule for periodic maintenance work.
4Migrating a small AWS Lambda function to IBM Cloud Functions when the rest of the architecture is on IBM Cloud.

Common Questions

How does IBM Cloud Functions compare to Code Engine?: Cloud Functions is OpenWhisk-based — actions are small short-lived scripts written in supported runtimes (Node.js, Python, etc.) and orchestrated via triggers, rules, and sequences. Code Engine is container-based — you bring a container image and run it as an app or job. For tiny event-driven glue code, Cloud Functions is right; for anything beyond a single function (multi-route web apps, batch jobs with custom dependencies), Code Engine is right.
What's a 'sequence' vs. just calling one action from another?: A sequence is a declarative composition — the platform handles the chain. Calling one action from another inside your code creates an implicit dependency that the platform doesn't see, which limits observability and retry behavior. Sequences are also explicit in the dashboard, making the workflow understandable to other engineers.

Expert Tips

TIP

Keep actions small and focused. The OpenWhisk model rewards composition: ten small actions chained by sequences are easier to reason about than one large action with internal branching.

TIP

Use parameters bound at the package level for shared configuration. Setting an API key on each action wastes effort and risks inconsistency; setting it on the package makes it available to all actions in the package.

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.