One-shot batch workload in Code Engine

This workload consists of a finite number of tasks.

Supply all tasks when you create the fleet. Workers and instances are created immediately, and tasks are started when they are ready. When the last task completes, the fleet enters the standby state; it can then be canceled. You control how many tasks run in parallel and how many workers are deployed by defining the fleet's maximum scaling parameter (Maximum container slots, --scale-max). Use this approach when your batch of tasks needs a dedicated fleet configuration, for example a specific set of environment variables.

Example: An image-processing job that renders 10,000 frames. You create the fleet with all task indexes, and it runs to completion.

Scheduled batch workload in Code Engine

This workload consists of tasks that are scheduled on a regular basis. All tasks can be processed using the same fleet configuration.

You keep one fleet around indefinitely and add a new batch of tasks on a schedule. You control how many tasks run in parallel and how many workers are deployed by defining the fleet's maximum scaling parameter (Maximum container slots, --scale-max). For example, every morning a job collects the work that queued up in the last 24 hours and submits it in one call. Between batches, the fleet sits idle, with no pending tasks. The gap between batches is predictable and long enough so that keeping workers available is not worthwhile.

Example: A payment processor receives transaction files from external partners throughout the day. Each file is deposited into Cloud Object Storage under a path such as input/2026-08-30/. Every morning, a scheduled Code Engine job adds tasks to the fleet to process the previous day's files. Workers boot, process every object under that path, and then scale to zero until the next morning.

Continuous, latency-sensitive workload in Code Engine

This workload consists of tasks that arrive unpredictably throughout the day — triggered by user actions, sensor readings, or other real-time events. All tasks can be processed using the same fleet configuration. Waiting for a new worker to boot each time a task arrives would add unacceptable latency. Instead, use options Minimum container slots or --scale-min, Spare container slots or --scale-spare, and Scale-down delay or --scale-down-delay to keep a pool of warm workers ready at all times so that task processing can start immediately.

Example: A fraud-detection fleet that evaluates transactions as they arrive. New tasks must start processing within seconds. Therefore, when idle, the fleet keeps workers running for at least 10 concurrent task slots (Minimum container slots: 10, --scale-min 10). At any point in time, 5 slots are kept free (Spare container slots: 5, --scale-spare 5), so an incoming burst of up to 5 tasks starts immediately. When tasks arrive faster than spare capacity allows, new workers are provisioned until 5 free slots are available or the maximum number of 100 instances is reached (Maximum container slots: 100, --scale-max 100). When activity drops, workers remain available for 10 minutes before scaling down (Scale-down delay: 10, --scale-down-delay 600).

Automatic scaling

With a fleet, you can take advantage of large scale parallelism to complete large, compute-intensive tasks. Code Engine automatically scales the worker nodes in your fleet to meet resource requirements most efficiently. You can let Code Engine determine the profiles of the workers that are deployed, or you can choose a specific profile, such as a GPU type. In either case, Code Engine automatically scales the number of workers for the greatest level of efficiency.

The number of workers deployed is based on the number of tasks to complete, the resources required for an instance of your code, and the setting of scaling parameters; for more detail, see Configuring fleet scaling. By adjusting these settings, you can scale your fleet to complete as few as 1 or as many as several million tasks.

For example, imagine you have 4 tasks to complete. Each instance of code requires 1 vCPU and 2 GB memory, for a total requirement of 4 vCPU and 8 GB memory. If you set the maximum number of concurrent instances to 2, Code Engine can deploy 1 worker node with 2 vCPU and 4 GB memory to run 2 instances at one time. If you set the maximum to 4, Code Engine can deploy 2 worker nodes to run all 4 instances simultaneously. The second scenario finishes more quickly but requires more workers. Keep in mind that worker nodes of various profiles might be deployed in many combinations.

Automatic scaling is not available for GPUs. To deploy GPUs for a fleet, you must specify the type of GPU worker to deploy.

Task and instance specification

When deploying a fleet, you can specify the number of tasks to complete and the number of instances to run at a time. You can also choose to create a fleet with some tasks or even without any tasks and add more tasks later. Fleets can work on many tasks in parallel by starting multiple instances concurrently. All instances are created with the same amount of vCPU and memory as in the fleet's specification. Additionally, you can create a task specification file to provide specific commands and arguments for each task or to create custom task indexes.

Task storage in COS

You can use a COS bucket to provide the tasks for your fleet by specifying a persistent data store and subpath when you create the fleet. Each object in the COS bucket represents a single task.

Isolation

Unlike batch jobs, fleets provide single-tenant isolation. Your fleet workers are not shared with other users.

Retries

Each fleet instance runs to completion. However, in case of an error, Code Engine restarts the instance. You can limit the maximum number of retries to avoid restarting failed instances.

Status

A fleet is in the Running status when at least one task is being processed. When the fleet is no longer running, it is in the Standby status. You can also cancel a fleet.

For more information, see Understanding the status of your fleet.

Worker profile

You can optionally choose the profile for your fleet worker. If you do not specify a profile, Code Engine picks a profile for you.

Code Engine fleets support the following profile families:

Some profiles may not be available in all VPC network zones. You can use the following CLI command to list worker profiles supported by Code Engine serverless fleets in a region.

ibmcloud ce fleet worker profiles

• If you want to know zonal availability and capacity of certain profiles, such as H100 and L40s, open a support case and select "Virtual Private Cloud (VPC)" as the topic.
• If you need a certain VPC profile which is not supported by fleets today, open a support case and select "Code Engine" as the topic.