Mastering GitHub Copilot Budgets: How to Prevent Surprise Overages Without Blocking Devs
July 30, 2026The Microsoft AI and Agent Platform — The Platform Behind Intelligent Agents
July 30, 2026
Azure Container Apps Jobs are a good fit for batch processing, ETL, machine learning, reports, and other tasks that run to completion. But when those tasks have dependencies, retries, or fan-out, you still need an orchestrator.
Many teams already have one. The community-maintained Bring Your Own Orchestrator collection provides 13 templates that connect existing workflow engines to Azure Container Apps Jobs. The collection is also listed in the Microsoft Azure Container Apps template index.
The idea is simple:
- Your orchestrator manages schedules, dependencies, retries, and workflow history.
- Azure Container Apps Jobs runs each containerized task and reports the result.
You keep the control plane your team knows while ACA Jobs provides the execution layer.
How it works
Each integration follows the same flow:
- The orchestrator authenticates to Azure.
- It starts an ACA Job execution.
- It waits for that execution to succeed or fail.
- It uses the result to continue, retry, or stop the workflow.
Your orchestrator —> Azure Container Apps Job
^ |
+—- execution result —+
The templates package this flow in the native model of each platform: an Airflow operator, a Temporal Activity, an Argo workflow template, a Camunda service task, or visual actions in Logic Apps and n8n.
The workload container stays independent of the orchestrator that launched it.
Choose the orchestrator that fits the workflow
There is no single best orchestrator for every workload. The useful question is which control plane matches the way your team models work.
| When this describes your team | Start with | Why |
|---|---|---|
| You already operate Airflow | Airflow on ACA Jobs | Adds an ACA Jobs operator without replacing your Airflow deployment |
| You need a complete Airflow environment | Airflow hosted on ACA | Deploys the Airflow control plane and the ACA Jobs integration |
| Your workflows are Kubernetes-native and run from AKS | Argo Workflows | Uses Argo workflow templates and AKS workload identity |
| You model long-running business processes in BPMN | Camunda 8 | Connects Camunda service tasks to ACA Job executions |
| You use JSON-defined microservice workflows | Conductor | Uses Conductor workers and native FORK_JOIN workflows |
| You need durable replay, heartbeats, and resilient retries | Temporal | Keeps Temporal as the durable control plane while ACA Jobs runs the workload |
| You build asset-centric Python data pipelines | Dagster | Uses Dagster resources, ops, and dynamic mapping |
| You build general Python flows and task automation | Prefect | Uses Prefect tasks, flows, and mapped execution |
| You prefer visual automation and SaaS integrations | n8n | Provides visual workflows for starting and observing ACA Jobs |
| You use Azure-native data pipelines | Azure Data Factory and Fabric | Provides pipeline definitions for Azure data integration workflows |
| You need connector-rich application integration | Logic Apps Standard | Uses stateful workflows, connectors, and native control flow |
| You want Azure-native, code-first durable orchestration | Durable Functions | Uses durable orchestrations, activities, retries, and fan-out/fan-in |
| You already operate a Dapr-enabled workflow host | Dapr Workflow | Demonstrates Dapr Workflow directing external ACA Job workloads |
The Bring Your Own Orchestrator catalog keeps this comparison current and links to deployment instructions for every option.
Before production
The existing-orchestrator templates are designed around managed identity, scoped Azure RBAC, failure handling, and native fan-out/fan-in examples. Their fan-out samples default to five shards and accept configurations from 1 to 50.
Treat higher shard counts as configuration support, not a throughput guarantee. Test them against your Azure quotas, orchestrator limits, and downstream systems.
Two template-specific boundaries are worth calling out:
Dapr Workflow is a preview architecture
Azure Container Apps Jobs do not host Dapr sidecars. The Dapr workflow runtime must run in a separate Dapr-enabled host and start ACA Jobs through Azure Resource Manager. The template is therefore labeled preview architecture.
Fabric still needs a native workspace run
The Azure Data Factory path has live validation. The included Fabric pipeline is structurally validated but still needs a native run in a Fabric workspace.
Each repository README documents its validation scope and limitations.
Get started
- Open the template catalog.
- Choose the orchestrator your team already uses.
- Review that template’s prerequisites and validation notes.
- Deploy the sample ACA Job with
azd up. - Run the single-job example, then test fan-out and failure behavior.
For example, if Airflow is already your standard:
git clone https://github.com/hetvip2/airflow-on-aca-jobs
cd airflow-on-aca-jobs
azd up
The exact setup differs by orchestrator, but the target remains ACA Jobs.
Try the templates
- Compare all 13 orchestrator templates and choose the control plane that matches your team.
- Review the Azure Container Apps Jobs documentation for triggers, permissions, and platform limits.
- Browse the ACA community template collections to find the collection in the Microsoft Azure Container Apps repository.
Closing thoughts
Using Azure Container Apps Jobs should not require an orchestrator migration. Keep the workflow engine your team already trusts and use ACA Jobs for containerized task execution.
Explore all 13 options in the Bring Your Own Orchestrator to Azure Container Apps Jobs collection.
References
- Azure Container Apps Jobs overview
- Azure Container Apps Jobs management API
- Managed identities in Azure Container Apps
- Azure Developer CLI documentation
- Bring Your Own Orchestrator template catalog
- Azure Container Apps community template collections