finos · magniloquency · Feb 10, 2026 · Feb 10, 2026 · Feb 11, 2026 · Feb 11, 2026
diff --git a/.github/actions/run-test/action.yml b/.github/actions/run-test/action.yml
@@ -55,7 +55,13 @@ runs:
       run: |
         uv pip install --system -r examples/applications/requirements_applications.txt
         uv pip install --system -r examples/ray_compat/requirements.txt
+        readarray -t skip_examples < examples/skip_examples.txt
         for example in "./examples"/*.py; do
+          filename=$(basename "$example")
+          if [[ " ${skip_examples[*]} " =~ [[:space:]]${filename}[[:space:]] ]]; then
+            echo "Skipping $example"
+            continue
+          fi
           echo "Running $example"
           python $example
         done

diff --git a/.gitignore b/.gitignore
@@ -34,3 +34,6 @@ CMakeFiles/
 .vs/
 src/scaler/protocol/capnp/*.c++
 src/scaler/protocol/capnp/*.h
+
+orb/logs/
+orb/metrics/
diff --git a/README.md b/README.md
@@ -250,6 +250,8 @@ The following table maps each Scaler command to its corresponding section name i
 | `scaler_worker_adapter_native`       | `[native_worker_adapter]`       |
 | `scaler_worker_adapter_fixed_native` | `[fixed_native_worker_adapter]` |
 | `scaler_worker_adapter_symphony`     | `[symphony_worker_adapter]`     |
+| `scaler_worker_manager_orb`          | `[orb_worker_adapter]`          |
+| `scaler_worker_adapter_ecs`          | `[ecs_worker_adapter]`          |
 
 ### Practical Scenarios & Examples
 
@@ -466,6 +468,26 @@ where `deepest_nesting_level` is the deepest nesting level a task has in your wo
 workload that has
 a base task that calls a nested task that calls another nested task, then the deepest nesting level is 2.
 
+## ORB (AWS EC2) integration
+
+A Scaler scheduler can interface with ORB (Open Resource Broker) to dynamically provision and manage workers on AWS EC2 instances.
+
+```bash
+$ scaler_worker_manager_orb tcp://127.0.0.1:2345 --image-id ami-0528819f94f4f5fa5
+```
+
+This will start an ORB worker adapter that connects to the Scaler scheduler at `tcp://127.0.0.1:2345`. The scheduler can then request new workers from this adapter, which will be launched as EC2 instances.
+
+### Configuration
+
+The ORB adapter requires `orb-py` and `boto3` to be installed. You can install them with:
+
+```bash
+$ pip install "opengris-scaler[orb]"
+```
+
+For more details on configuring ORB, including AWS credentials and instance templates, please refer to the [ORB Worker Adapter documentation](https://finos.github.io/opengris-scaler/tutorials/worker_adapters/orb.html).
+
 ## Worker Adapter usage
 
 > **Note**: This feature is experimental and may change in future releases.

diff --git a/docs/source/index.rst b/docs/source/index.rst
@@ -30,6 +30,7 @@ Content
    tutorials/worker_adapters/index
    tutorials/worker_adapters/native
    tutorials/worker_adapters/fixed_native
+   tutorials/worker_adapters/orb
    tutorials/worker_adapters/aws_hpc/index
    tutorials/worker_adapters/common_parameters
    tutorials/compatibility/ray

diff --git a/docs/source/tutorials/compatibility/ray.rst b/docs/source/tutorials/compatibility/ray.rst
@@ -6,7 +6,7 @@ Ray Compatibility Layer
 Scaler is a lightweight distributed computation engine similar to Ray. Scaler supports many of the same concepts as Ray including
 remote functions (known as tasks in Scaler), futures, cluster object storage, labels (known as capabilities in Scaler), and it comes with comparable monitoring tools.
 
-Unlike Ray, Scaler supports both local clusters and also easily integrates with multiple cloud providers out of the box, including AWS EC2 and IBM Symphony,
+Unlike Ray, Scaler supports both local clusters and also easily integrates with multiple cloud providers out of the box, including ORB (AWS EC2) and IBM Symphony,
 with more providers planned for the future. You can view our `roadmap on GitHub <https://github.com/finos/opengris-scaler/discussions/333>`_
 for details on upcoming cloud integrations.
 

diff --git a/docs/source/tutorials/configuration.rst b/docs/source/tutorials/configuration.rst
@@ -199,6 +199,8 @@ The following table maps each Scaler command to its corresponding section name i
      - ``[fixed_native_worker_adapter]``
    * - ``scaler_worker_adapter_symphony``
      - ``[symphony_worker_adapter]``
+   * - ``scaler_worker_manager_orb``
+     - ``[orb_worker_adapter]``
    * - ``scaler_worker_adapter_ecs``
      - ``[ecs_worker_adapter]``
    * - ``python -m scaler.entry_points.worker_adapter_aws_hpc``

diff --git a/docs/source/tutorials/examples.rst b/docs/source/tutorials/examples.rst
@@ -15,6 +15,14 @@ Shows how to send a basic task to scheduler
 .. literalinclude:: ../../../examples/simple_client.py
    :language: python
 
+Submit Tasks
+~~~~~~~~~~~~
+
+Shows various ways to submit tasks (submit, map, starmap)
+
+.. literalinclude:: ../../../examples/submit_tasks.py
+   :language: python
+
 Client Mapping Tasks
 ~~~~~~~~~~~~~~~~~~~~
 

diff --git a/docs/source/tutorials/worker_adapters/common_parameters.rst b/docs/source/tutorials/worker_adapters/common_parameters.rst
@@ -1,7 +1,7 @@
 Common Worker Adapter Parameters
 ================================
 
-All worker adapters in Scaler share a set of common configuration parameters for connecting to the cluster, configuring the internal web server, and managing worker behavior.
+All worker adapters in Scaler share a set of common configuration parameters for connecting to the cluster and managing worker behavior.
 
 .. note::
     For more details on how to configure Scaler, see the :doc:`../configuration` section.

diff --git a/docs/source/tutorials/worker_adapters/index.rst b/docs/source/tutorials/worker_adapters/index.rst
@@ -46,6 +46,11 @@ AWS HPC
 
 The :doc:`AWS HPC <aws_hpc/index>` worker adapter allows Scaler to offload task execution to cloud environments, currently supporting AWS Batch. It is ideal for bursting workloads to the cloud or utilizing specific hardware not available locally.
 
+ORB (AWS EC2)
+~~~~~~~~~~~~~
+
+The :doc:`ORB <orb>` worker adapter allows Scaler to dynamically provision workers on AWS EC2 instances. This is ideal for scaling workloads that require significant cloud compute resources or specialized hardware like GPUs.
+
 Common Parameters
 ~~~~~~~~~~~~~~~~~
 
@@ -56,5 +61,6 @@ All worker adapters share a set of :doc:`common configuration parameters <common
 
     native
     fixed_native
+    orb
     aws_hpc/index
     common_parameters
diff --git a/docs/source/tutorials/worker_adapters/orb.rst b/docs/source/tutorials/worker_adapters/orb.rst
@@ -0,0 +1,132 @@
+ORB Worker Adapter
+==================
+
+The ORB worker adapter allows Scaler to dynamically provision workers on AWS EC2 instances using the ORB (Open Resource Broker) system. This is particularly useful for scaling workloads that require significant compute resources or specialized hardware available in the cloud.
+
+This tutorial describes the steps required to get up and running with the ORB adapter.
+
+Requirements
+------------
+
+Before using the ORB worker adapter, ensure the following requirements are met on the machine that will run the adapter:
+
+1.  **orb-py and boto3**: The ``orb-py`` and ``boto3`` packages must be installed. These can be installed using the ``orb`` optional dependency of Scaler:
+
+    .. code-block:: bash
+
+        pip install "opengris-scaler[orb]"
+
+2.  **AWS CLI**: The AWS Command Line Interface must be installed and configured with a default profile that has permissions to launch, describe, and terminate EC2 instances.
+
+3.  **Network Connectivity**: The adapter must be able to communicate with AWS APIs and the Scaler scheduler.
+
+Getting Started
+---------------
+
+To start the ORB worker adapter, use the ``scaler_worker_manager_orb`` command.
+
+Example command:
+
+.. code-block:: bash
+
+    scaler_worker_manager_orb tcp://<SCHEDULER_EXTERNAL_IP>:8516 \
+        --object-storage-address tcp://<OSS_EXTERNAL_IP>:8517 \
+        --image-id ami-0528819f94f4f5fa5 \
+        --instance-type t3.medium \
+        --aws-region us-east-1 \
+        --logging-level INFO \
+        --task-timeout-seconds 60
+
+Equivalent configuration using a TOML file:
+
+.. code-block:: bash
+
+    scaler_worker_manager_orb tcp://<SCHEDULER_EXTERNAL_IP>:8516 --config config.toml
+
+.. code-block:: toml
+
+    # config.toml
+
+    [orb_worker_adapter]
+    object_storage_address = "tcp://<OSS_EXTERNAL_IP>:8517"
+    image_id = "ami-0528819f94f4f5fa5"
+    instance_type = "t3.medium"
+    aws_region = "us-east-1"
+    logging_level = "INFO"
+    task_timeout_seconds = 60
+
+*   ``tcp://<SCHEDULER_EXTERNAL_IP>:8516`` is the address workers will use to connect to the scheduler.
+*   ``tcp://<OSS_EXTERNAL_IP>:8517`` is the address workers will use to connect to the object storage server.
+*   New workers will be launched using the specified AMI and instance type.
+
+Networking Configuration
+------------------------
+
+Workers launched by the ORB adapter are EC2 instances and require an externally-reachable IP address for the scheduler.
+
+*   **Internal Communication**: If the machine running the scheduler is another EC2 instance in the same VPC, you can use EC2 private IP addresses.
+*   **Public Internet**: If communicating over the public internet, it is highly recommended to set up robust security rules and/or a VPN to protect the cluster.
+
+Publicly Available AMIs
+-----------------------
+
+We regularly publish publicly available Amazon Machine Images (AMIs) with Python and ``opengris-scaler`` pre-installed.
+
+.. list-table:: Available Public AMIs
+   :widths: 15 15 20 20 30
+   :header-rows: 1
+
+   * - Scaler Version
+     - Python Version
+     - Amazon Linux 2023 Version
+     - Date (MM/DD/YYYY)
+     - AMI ID (us-east-1)
+   * - 1.14.2
+     - 3.13
+     - 2023.10.20260120
+     - 01/30/2026
+     - ``ami-0528819f94f4f5fa5``
+
+New AMIs will be added to this list as they become available.
+
+Supported Parameters
+--------------------
+
+.. note::
+    For more details on how to configure Scaler, see the :doc:`../configuration` section.
+
+The ORB worker adapter supports ORB-specific configuration parameters as well as common worker adapter parameters.
+
+Orb Template Configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*   ``--image-id`` (Required): AMI ID for the worker instances.
+*   ``--instance-type``: EC2 instance type (default: ``t2.micro``).
+*   ``--aws-region``: AWS region (default: ``us-east-1``).
+*   ``--key-name``: AWS key pair name for the instances. If not provided, a temporary key pair will be created and deleted on cleanup.
+*   ``--subnet-id``: AWS subnet ID where the instances will be launched. If not provided, it attempts to discover the default subnet in the default VPC.
+*   ``--security-group-ids``: Comma-separated list of AWS security group IDs.
+*   ``--allowed-ip``: IP address to allow in the security group (if created automatically). Defaults to the adapter's external IP.
+*   ``--orb-config-path``: Path to the ORB root directory (default: ``src/scaler/drivers/orb``).
+
+Common Parameters
+~~~~~~~~~~~~~~~~~
+
+For a full list of common parameters including networking, worker configuration, and logging, see :doc:`common_parameters`.
+
+Cleanup
+-------
+
+The ORB worker adapter is designed to be self-cleaning, but it is important to be aware of the resources it manages:
+
+*   **Key Pairs**: If a ``--key-name`` is not provided, the adapter creates a temporary AWS key pair.
+*   **Security Groups**: If ``--security-group-ids`` are not provided, the adapter creates a temporary security group to allow communication.
+*   **Launch Templates**: ORB may additionally create EC2 Launch Templates as part of the machine provisioning process.
+
+The adapter attempts to delete these temporary resources and terminate all launched EC2 instances when it shuts down gracefully. However, in the event of an ungraceful crash or network failure, some resources may persist in your AWS account.
+
+.. tip::
+    It is recommended to periodically check your AWS console for any orphaned resources (instances, security groups, key pairs, or launch templates) and clean them up manually if necessary to avoid unexpected costs.
+
+.. warning::
+    **Subnet and Security Groups**: Currently, specifying ``--subnet-id`` or ``--security-group-ids`` via configuration might not have the intended effect as the adapter is designed to auto-discover or create these resources. Specifically, the adapter may still attempt to use default subnets or create its own temporary security groups regardless of these parameters.
diff --git a/examples/readme.md b/examples/readme.md
@@ -17,6 +17,8 @@ Ensure that the scheduler and cluster are set up before running clients.
     Shows how to send a nested task to scheduler
 - `simple_client.py`
     Shows how to send a basic task to scheduler
+- `submit_tasks.py`
+    Shows various ways to submit tasks (submit, map, starmap)
 - `task_capabilities.py`
     Shows how to use capabilities to route task to various workers
 - `ray_compat/`

diff --git a/examples/skip_examples.txt b/examples/skip_examples.txt
diff --git a/examples/submit_tasks.py b/examples/submit_tasks.py
@@ -0,0 +1,67 @@
+"""
+This example demonstrates various ways to submit tasks to a Scaler scheduler.
+It shows how to use the Client to:
+1. Submit a single task using .submit()
+2. Submit multiple tasks using .map()
+3. Submit tasks with multiple arguments using .map() and .starmap()
+"""
+
+import argparse
+import math
+
+from scaler import Client, SchedulerClusterCombo
+
+
+def square(value: int):
+    return value * value
+
+
+def add(x: int, y: int):
+    return x + y
+
+
+def main():
+    parser = argparse.ArgumentParser(description="Submit tasks to a Scaler scheduler.")
+    parser.add_argument("url", nargs="?", help="The URL of the Scaler scheduler (e.g., tcp://127.0.0.1:2345)")
+    args = parser.parse_args()
+
+    cluster = None
+    if args.url is None:
+
+        print("No scheduler URL provided. Spinning up a local cluster...")
+        cluster = SchedulerClusterCombo(n_workers=4)
+        address = cluster.get_address()
+    else:
+        address = args.url
+
+    try:
+        print(f"Connecting to scheduler at {address}...")
+
+        # Use the Client as a context manager to ensure proper cleanup
+        with Client(address=address) as client:
+            print("Submitting a single task using .submit()...")
+            future = client.submit(square, 4)
+            print(f"Result of square(4): {future.result()}")
+
+            print("\nSubmitting multiple tasks using .map()...")
+            # client.map() works like Python's built-in map()
+            results = client.map(math.sqrt, range(1, 6))
+            print(f"Results of sqrt(1..5): {list(results)}")
+
+            print("\nSubmitting tasks with multiple arguments using .map()...")
+            # You can pass multiple iterables to map() for functions with multiple arguments
+            results_add = client.map(add, [1, 2, 3], [10, 20, 30])
+            print(f"Results of add([1,2,3], [10,20,30]): {list(results_add)}")
+
+            print("\nSubmitting tasks with multiple arguments using .starmap()...")
+            # starmap() takes an iterable of argument tuples
+            results_starmap = client.starmap(add, [(5, 5), (10, 10)])
+            print(f"Results of starmap(add, [(5,5), (10,10)]): {list(results_starmap)}")
+    finally:
+        if cluster:
+            cluster.shutdown()
+    print("\nAll tasks completed successfully.")
+
+
+if __name__ == "__main__":
+    main()
diff --git a/pyproject.toml b/pyproject.toml
@@ -52,6 +52,10 @@ graphblas = [
 aws = [
     "boto3",
 ]
+orb = [
+    "orb-py~=1.1; python_version >= '3.10'",
+    "boto3; python_version >= '3.10'",
+]
 all = [
     "nicegui[plotly]==2.24.2; python_version == '3.8'",
     "nicegui[plotly]==3.6.1; python_version >= '3.9'",
@@ -63,6 +67,7 @@ all = [
     "numpy==2.2.6; python_version >= '3.10'",
     "uvloop; platform_system != 'Windows'",
     "boto3",
+    "orb-py~=1.1; python_version >= '3.10'"
 ]
 
 [dependency-groups]
@@ -99,6 +104,7 @@ scaler_worker_manager_baremetal_fixed_native = "scaler.entry_points.worker_manag
 scaler_worker_manager_symphony = "scaler.entry_points.worker_manager_symphony:main"
 scaler_worker_manager_aws_raw_ecs = "scaler.entry_points.worker_manager_aws_raw_ecs:main"
 scaler_worker_manager_aws_hpc_batch = "scaler.entry_points.worker_manager_aws_hpc_batch:main"
+scaler_worker_manager_orb = "scaler.entry_points.worker_manager_orb:main"
 
 [tool.scikit-build]
 cmake.source-dir = "."

diff --git a/src/run_worker_manager_orb.py b/src/run_worker_manager_orb.py
@@ -0,0 +1,5 @@
+from scaler.entry_points.worker_manager_orb import main
+from scaler.utility.debug import pdb_wrapped
+
+if __name__ == "__main__":
+    pdb_wrapped(main)()
diff --git a/src/scaler/cluster/cluster.py b/src/scaler/cluster/cluster.py
@@ -34,6 +34,7 @@ def __init__(self, config: ClusterConfig):
         self._logging_paths = config.logging_config.paths
         self._logging_config_file = config.logging_config.config_file
         self._logging_level = config.logging_config.level
+        self._deterministic_worker_ids = config.deterministic_worker_ids
 
         # we create the config here, but create the actual adapter in the run method
         # to ensure that it's created in the correct process

diff --git a/src/scaler/config/section/cluster.py b/src/scaler/config/section/cluster.py
@@ -53,6 +53,10 @@ class ClusterConfig(ConfigClass):
     )
     worker_config: WorkerConfig = dataclasses.field(default_factory=WorkerConfig)
     logging_config: LoggingConfig = dataclasses.field(default_factory=LoggingConfig)
+    deterministic_worker_ids: bool = dataclasses.field(
+        default=False,
+        metadata=dict(short="-dwi", action="store_true", help="enable deterministic worker id generation"),
+    )
 
     def __post_init__(self):
         if self.worker_names.names and len(self.worker_names.names) != self.num_of_workers: