Announcing Azure Web PubSub chat in public preview
Chat is becoming a standard interaction model across customer support, collaboration, gaming, marketplaces, healthcare, financial services, and AI-powered applications. But building a production-ready chat system involves much more than opening a WebSocket connection. Teams also need to manage rooms and membership, deliver and order messages, retain conversation history, recover from connection interruptions, and enforce permissions. Today, we are excited to announce that Azure Web PubSub chat is available in public preview. Azure Web PubSub chat is a managed capability built on Azure Web PubSub. It provides chat-focused client and server APIs so developers can work directly with familiar concepts such as rooms, messages, members, users, and roles, while Azure manages the underlying real-time messaging infrastructure. Focus on the chat experience, not the messaging plumbing Azure Web PubSub already helps developers build large-scale, real-time applications. The new chat capability adds a higher-level abstraction for applications whose primary interaction model is conversation. Instead of defining custom events, message schemas, membership logic, persistence workflows, and reconnect behavior, developers can use built-in chat operations to: Create one-to-one or group rooms. Add and remove room members. Send ordered messages in real time. Retrieve persistent room message history. Apply built-in or custom roles and permissions. Reconnect clients and recover messages after temporary connection loss. These capabilities run on Azure Web PubSub infrastructure and inherit its automatic scaling, geo-replication, security, and compliance foundations. Chat-native APIs for clients and servers Azure Web PubSub chat provides two complementary ways to build. The JavaScript client SDK, available through the `@azure/web-pubsub-chat-client` npm package, connects applications to a chat hub. Clients can create rooms, exchange messages, load history, manage members, and subscribe to chat events. The Chat REST API supports trusted server-side and administrative workflows, including managing rooms, users, members, messages, roles, and permissions. This separation lets client applications deliver responsive real-time experiences while backend services retain control over identity, moderation, governance, and business rules. For example, after connecting a `ChatClient`, creating a room and sending a message takes only a few calls: const room = await client.createRoom("Project Falcon", ["bob", "carol"]); client.on("message", ({ message }) => { console.log(`${message.createdBy}: ${message.content.text}`); }); await client.sendToRoom(room.roomId, "Welcome to the project room!"); Applications can also read message history through an asynchronous iterator, making it straightforward to implement initial conversation loading or incremental history as a user scrolls. Keep chat data in your Azure Storage account Persistent chat data remains in an Azure Storage account selected by the application owner. Azure Web PubSub chat uses the Web PubSub resource's managed identity to access that storage, avoiding storage connection strings or keys in the chat configuration. The stored data includes: Messages and conversation history Rooms and room membership Users Roles and permissions Your data stays in your storage account, and the service keeps no separate copy. This model gives organizations direct ownership of their persisted chat data while the managed service handles real-time delivery and chat operations. Built-in access control with room-level flexibility Chat applications often need different privileges for participants, moderators, room owners, support agents, or automated services. Azure Web PubSub chat includes a role and permission model for these scenarios. Built-in room roles distinguish between members and operators. Both can send messages, read history, and invite members by default, while operators can also remove users. Developers can define custom user or room roles when an application needs a different permission set. Role administration is performed through the Chat REST API, keeping permission management in trusted server-side code. Reliable conversations across connections and devices Users expect chat to continue working when a laptop changes networks, a mobile connection briefly drops, or the same account is open in multiple browser tabs or devices. Azure Web PubSub chat runs on Azure Web PubSub's reliable WebSocket connection. The client reconnects and recovers automatically after an interruption, while the service fans messages out to a user's active connections. Persistent history also allows users to load earlier messages after reconnecting or joining a room later. Choose the right Web PubSub capability The new chat capability complements the existing standard Web PubSub hub. Use a chat hub when the application is centered on conversations and benefits from built-in rooms, membership, history, roles, and chat-focused APIs. Use a standard hub when the application needs full control over its protocol or supports a different real-time workload, such as telemetry, device signaling, multiplayer state, notifications, or live dashboards. Both options use Azure Web PubSub, allowing teams to select the abstraction that best fits each real-time scenario. Get started To try Azure Web PubSub chat: Create or open an Azure Web PubSub resource. Link an Azure Storage account under Persistent Storages. Add a Chat Hub and associate it with that storage. Generate a client access URL for testing. Install the JavaScript client SDK: npm install azure/web-pubsub-chat-client Connect a client, create a room, and send your first message. The portal-generated client URL is intended for experimentation. In production, issue client access URLs from an authenticated backend and derive the chat user ID from the signed-in application identity. Managed identity and Microsoft Entra ID can be used for keyless server authentication. Azure Web PubSub chat is available now in public preview. Start with the Azure Web PubSub chat overview, follow the quickstart, or explore the client SDK and REST API. We look forward to seeing the customer conversations, collaboration experiences, and AI-powered applications you build with it.Announcing public preview: Markdown for Agents in Azure App Service
Why Markdown for Agents? Web pages often contain scripts, styles, and HTML markup that are useful to browsers but add noise when the content is sent to an AI model. Markdown for Agents removes that extra markup and returns a smaller, text-focused response that is easier for agents to process and can reduce token usage. In internal testing across more than 637,000 pages, converted Markdown responses were 97 percent smaller at the median than the source HTML, with a median conversion time of 2 milliseconds. Results vary based on the page and its content. Public preview availability Markdown for Agents is available in public preview for Windows apps on Azure App Service in all public regions. The app must use an App Service plan in the Basic tier or higher. No additional authentication setup is required for Markdown conversion. Your app's existing authentication, authorization, and network access controls continue to apply. This feature is only supported on Windows App Service at this time. Support for Linux apps will come later this year. Enable Markdown for Agents During the public preview, you can enable the feature through the REST API, ARM/Bicep template, or the Azure CLI using az rest . Dedicated Azure CLI commands and portal support are planned for a future update. Azure CLI with az rest Replace the placeholders with your subscription ID, resource group, and app name: az rest --method patch --url "https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<APP_NAME>?api-version=2026-03-15" --headers "Content-Type=application/json" --body '{"properties":{"aiIntegration":{"markdown":{"enabled":true}}}}' Verify the setting: az rest --method get --url "https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<APP_NAME>?api-version=2026-03-15" --query "properties.aiIntegration.markdown" To disable the feature, send the same PATCH request with enabled set to false . ARM template Add the following property to your Microsoft.Web/sites resource using API version 2026-03-15 : "properties": { "aiIntegration": { "markdown": { "enabled": true } } } Bicep resource webApp 'Microsoft.Web/sites@2026-03-15' = { name: appName location: location properties: { serverFarmId: appServicePlanResourceId aiIntegration: { markdown: { enabled: true } } } } Request a Markdown response After enabling the feature, request an HTML page from your app with the Accept: text/markdown header: curl -i -H "Accept: text/markdown" "https://<APP_NAME>.azurewebsites.net/" A successfully converted response includes these headers: Content-Type: text/markdown; charset=utf-8 x-markdown-source: easy-markdown The response body contains Markdown generated from the page's HTML. Common content such as headings, paragraphs, links, lists, images, emphasis, and code is preserved, while script and style content is removed. Pages that cannot be safely converted may return their original HTML. Clients should check the Content-Type and x-markdown-source response headers before processing the response as Markdown. What's next Linux support is planned before the feature reaches general availability. We also plan to add dedicated Azure CLI commands and a portal experience in future updates. Share your feedback Try Markdown for Agents with your Windows App Service apps and let us know how it works for your agent scenarios. Share feedback, questions, and feature requests in the comments below.Announcing General Availability of Managed Instance on Azure App Service
Today, we are thrilled to announce the General Availability (GA) of Managed Instance on Azure App Service. Following the tremendous response to our Public Preview announcement at Ignite 2025, we've spent the past nine months working closely with customers, partners, and the community to harden the platform, expand capabilities, and validate real-world enterprise migration scenarios. Managed Instance on Azure App Service is now ready for your production workloads, backed by a full enterprise SLA. The journey from Preview to GA Since November 2025, thousands of customers have used the public preview to move workloads that were previously "stuck" on-premises or on aging Windows Server VMs. The feedback has been unmistakable: Managed Instance on Azure App Service dramatically shortens the path to the cloud for legacy and complex .NET Framework applications often removing the need for code changes entirely. Enterprises across various sectors like financial services, healthcare, manufacturing, and the public sector migrated applications that depended on GAC assemblies, COM components, Windows Services, registry configuration, and mapped network drives apps that historically required expensive re-platforming or a full rewrite. With Managed Instance on Azure App Service, these workloads now run on a fully managed PaaS platform, side-by-side with modern cloud-native apps. What's new at GA Building on the preview foundation of configuration scripts, registry adapters, storage mounts, and RDP via Azure Bastion, GA brings several important additions: Production SLA (99.95%) – Full enterprise-grade availability commitment across all supported regions. Expanded regional availability – Available in at least 8 Azure regions worldwide at GA with continued expansion planned through the remainder of 2026. Deeper Premium v4 integration – Managed Instance now takes full advantage of the Premium v4 App Service Plan tier for enhanced performance, memory-optimized SKUs, and improved price-performance. Zone redundancy – Deploy Managed Instance workloads across Availability Zones for higher resiliency without additional configuration effort. Enhanced observability – First-class integration with Azure Monitor, Application Insights, and Log Analytics, including instance-level metrics for CPU, memory and disk. Improved configuration script experience – Faster startup times, richer diagnostics when scripts fail, versioning support for configuration bundles, and streamlined rollback. Managed Identity everywhere – All secrets, storage connections, and Key Vault references at GA use Managed Identity by default, eliminating stored credentials from your deployment pipelines. Azure Policy and Defender for Cloud coverage – Governance, compliance, and threat protection controls now apply to Managed Instance the same way they apply to standard App Service workloads. Bicep, Terraform, and ARM templates – Full IaC support with new resource providers and modules for repeatable, auditable deployments. GitHub Copilot Modernization - Deep Integration with GitHub Copilot modernization for Application assessment targeting Managed Instance on App Service https://learn.microsoft.com/en-us/dotnet/azure/migration/appmod/working-with-assessment Why customers are choosing Managed Instance on Azure App Service The core value proposition remains the same and it's stronger than ever at GA: 1. Lift-and-Improve legacy applications Migrate .NET Framework apps with hardcoded file paths, COM dependencies, GAC entries, or registry access with no major code rewrites. Install custom components directly on the managed instance using configuration scripts. 2. Re-platform hard-to-modernize apps Move applications with lost source code, legacy middleware (MSMQ, SMTP servers, third-party runtimes), or tight infrastructure coupling. Managed Instance removes the blockers that historically forced these apps to stay on VMs. 3. Hybrid and regulated workloads Integrate securely with on-premises resources using VNet integration and private endpoints. Enforce data residency, Bring Your Own Storage, and Managed Identity–backed access controls to meet finance, healthcare, and government compliance requirements. 4. Incremental modernization Start with "lift and Improve" then adopt PaaS features like DevOps automation, autoscaling, deployment slots, and centralized configuration at your own pace. Future-proof your portfolio without a big-bang transformation. What customers are saying During preview, we saw real numbers: Migration timelines cut from months to weeks for apps that would otherwise have required substantial refactoring. Zero code changes for a significant share of preview workloads that previously blocked App Service adoption. Reduced infrastructure footprint as customers consolidated Windows Server VMs onto managed App Service Plans with zone redundancy and autoscaling built in. We are grateful to every preview customer whose feedback shaped this release. Pricing and licensing Managed Instance on Azure App Service is billed as a capability on top of the Premium v4 App Service Plan. There is no separate Managed Instance surcharge at GA you pay for the underlying Premium v4 compute you consume. Existing App Service reservations, savings plans, and any other Azure Benefit all apply, helping you optimize the total cost of ownership as you migrate. Getting started Getting started is straightforward: Assess your workload using Azure Migrate's updated App Service assessment, which now flags candidates ideal for Managed Instance. Create a new Web App using the Managed Instance on Azure App Service option in the Azure Marketplace, or via Bicep, Terraform, or the Azure CLI. Package your dependencies into a configuration bundle (a zip file plus a PowerShell install script) and store it in Azure Storage. Grant access via Managed Identity. Configure registry values, storage mounts, and networking to match your on-premises environment. Deploy your application using the same App Service deployment mechanisms you already know—ZIP deploy, GitHub Actions, Azure DevOps, or Visual Studio publish. Operate with confidence use RDP over Azure Bastion for deep troubleshooting when you need it, and Azure Monitor for everything else. Resources 📘 Managed Instance on Azure App Service documentation 🎥 Technical Deep Dive session recording from Build 2026 🧭 GitHub Repo with sample configuration scripts, webapp and guidance for Managed Instance on App Service workloads Looking ahead GA is a milestone, not a finish line. On our roadmap we're already working on: Deeper integration with Azure Migrate's web app discovery and assessment capabilities to help identify web apps suitable for migration to Managed Instance on App Service Enhanced migration tooling with easier dependency detection and one-click configuration bundle generation. Expanded Rollout to Azure Regions across 2026 and beyond. Continuously Release new features and capabilities to make migrations easier and faster than ever before We can't wait to see what you build and what you migrate. Managed Instance on Azure App Service is here to make your modernization journey faster, simpler, and more secure than ever. Welcome to GA. 🚀 The Azure App Service TeamMemory Dump Collection using Procdump.exe for App Service (Windows)
A memory dump is a snapshot of the contents of a computer's volatile memory (RAM) stored for analysis or debugging purposes. ProcDump is a command-line tool designed to monitor applications for CPU/Memory spikes and generate crash dumps when spikes occur. Administrators or developers can then use these dumps to pinpoint the cause of the spikes. This guide will walk you through collecting a memory dump using Procdump.exe for applications hosted on App Service (Windows).
A simpler way to deploy ZIP packages to Azure App Service from the Azure portal
We recently introduced a simpler way to deploy applications to Azure App Service for Linux by uploading a ZIP package through Kudu. The experience lets you review the package contents, choose whether to run a server-side build, and follow the deployment through its different stages. This capability is now available directly in the Azure portal through Deployment Center. To use it: Open your Linux web app in the Azure portal. Go to Deployment Center. Select Manual Deployment (Push). Choose Publish files (new) as the source. Drag and drop your ZIP file or select Browse files. You can now upload and deploy your application without navigating separately to the Kudu site. This is useful for getting started, testing an application, or performing an occasional manual deployment. For repeatable production deployments, we recommend configuring a CI/CD pipeline. To learn more about the deployment experience, including package preview, build options, progress tracking, and deployment logs, see our previous post: A simpler way to deploy your code to Azure App Service for Linux | Microsoft Community HubAnnouncing the Public Preview of the New App Service Quota Self-Service Experience
Update 10/30/2025: The App Service Quota Self-Service experience is back online after a short period where we were incorporating your feedback and making needed updates. As this is public preview, availability and features are subject to change as we receive and incorporate feedback. What’s New? The updated experience introduces a dedicated App Service Quota blade in the Azure portal, offering a streamlined and intuitive interface to: View current usage and limits across the various SKUs Set custom quotas tailored to your App Service plan needs This new experience empowers developers and IT admins to proactively manage resources, avoid service disruptions, and optimize performance. Quick Reference - Start here! Leverage the new self-service experience to increase your quota automatically. If your deployment requires quota for ten or more subscriptions, then file a support ticket with problem type Quota following the instructions at the bottom of this post. If any subscription included in your request requires zone redundancy (note that most Isolated v2 deployments require ZR), then file a support ticket with problem type Quota following the instructions at the bottom of this post. Self-service Quota Requests For non-zone-redundant needs, quota alone is sufficient to enable App Service deployment or scale-out. Follow the provided steps to place your request. 1. Navigate to the Quotas resource provider in the Azure portal 2. Select App Service (Public Preview) Navigating the primary interface: Each App Service VM size is represented as a separate SKU. If the intention is to be able to scale up or down within a specific offering (e.g., Premium v3), then equivalent number of VMs need to be requested for each applicable size of that offering (e.g., request 5 instances for both P1v3 and P3v3). As with other quotas, you can filter by region, subscription, provider, or usage. Note that your portal will now show "App Service (Public Preview)" for the Provider name. You can also group the results by usage, quota (App Service VM type), or location (region). Current usage is represented as App Service VMs. This allows you to quickly identify which SKUs are nearing their quota limits. Adjustments can be made inline: no need to visit another page. This is covered in detail in the next section. Total Regional VMs: There is a SKU in each region called Total Regional VMs. This SKU summarizes your usage and available quota across all individual SKUs in that region. There are three key points about using Total Regional VMs. You should never request Total Regional VMs quota directly - it will automatically increase in response to your request for individual SKU quota. If you are unable to deploy a given SKU, then you must request more quota for that SKU to unblock deployment. For your deployment to succeed, you must have sufficient quota in the individual SKU as well as Total Regional VMs. If either usage is at its respective limit, then you will be unable to deploy and must request more of that individual SKU's quota to proceed. In some regions, Total Regional VMs appears as "0 of 0" usage and limit and no individual SKU quotas are shown. This is an indication that you should not interact with the portal to resolve any quota-related issues in this region. Instead, you should try the deployment and observe any error messages that arise. If any error messages indicate more quota is needed, then this must be requested by filing a support ticket with problem type Quota following the instructions at the bottom of this post so that App Service can identify and fix any potential quota issues. In most cases, this will not be necessary, and your deployment will work without requesting quota wherever "0 of 0" is shown for Total Regional VMs and no individual SKU quotas are visible. See the example below: 3. Request quota adjustments Clicking the pen icon opens a flyout window to capture the quota request: The quota type (App Service SKU) is already populated, along with current usage. Note that your request is not incremental: you must specify the new limit that you wish to see reflected in the portal. For example, to request two additional instances of P1v2 VMs, you would file the request like this: Click submit to send the request for automatic processing. How quota approvals work: Immediately upon submitting a quota request, you will see a processing dialog like the one shown: If the quota request can be automatically fulfilled, then no support request is needed. You should receive this confirmation within a few minutes of submission: If the request cannot be automatically fulfilled, then you will be given the option to file a support request with the same information. In the example below, the requested new limit exceeds what can be automatically granted for the region: 4. If applicable, create support ticket If automatic quota fulfillment fails, and it recommend you Create a support request, then follow the steps given in the at the end of this post. Known issues The self-service quota request experience for App Service is in public preview. Here are some caveats worth mentioning while the team finalizes the release for general availability: Closing the quota request flyout window will stop meaningful notifications for that request. You can still view the outcome of your quota requests by checking actual quota, but if you want to rely on notifications for alerts, then we recommend leaving the quota request window open for the few minutes that it is processing. Some SKUs are not yet represented in the quota dashboard. These will be added later in the public preview. The Activity Log does not currently provide a meaningful summary of previous quota requests and their outcomes. This will also be addressed during the public preview. As noted in the walkthrough, the new experience does not enable zone-redundant deployments. Quota is an inherently regional construct, and zone-redundant enablement requires a separate step that can only be taken in response to a support ticket being filed. Quota API documentation is being drafted to enable bulk non-zone redundant quota requests without requiring you to file a support ticket. Create a support request While we are continuously improving the system to automatically process quota requests, there are certain scenarios you might need to create a support request: Automatic fulfillment request failed on quota blade. Deployment requires zone-redundancy You want to make bulk request for ten or more subscriptions When creating a support request, select your Issue type as “Service and subscription limits (quotas)” and Quota type as “Function or Web App (Windows and Linux)”. Select Next. You can then fill in your quota requirements by clicking on “Enter details”. There are 4 mandatory fields you must provide in your request: Region – Quota limits are based on region. If you are facing quota limits in one region, you can always try deployment in a geographically paired region. For example, West US 2 and West Central US are paired regions. East Asia (Hong Kong) and Southeast Asia (Singapore) are also paired regions. See Azure cross-region replication pairings for all geographies for more information. Deployment type – This is another important criterion when submitting quota request. If you are not sure which deployment type your App Service Plan is using, you can check it here on the portal: App >> App Service Plan >> Zone redundant >> Enabled\Disabled. App Service plan – Each SKU in your subscription and the region selected above, will have its own limit. Choose the SKU based on your deployment requirement. You will be able to see the current usage and the limit on that SKU. New limit – You must submit the new limit that you want for the SKU selected above. Do not add the increment value. The new limit must be higher than the existing limit. If you choose to create a support ticket, then you will interact with the capacity management team for that region. This is a 24x7 service, so requests may be created at any time. Once you have filed the support request, you can track its status via the Help + support dashboard. Note for Logic Apps You can now self-serve your Logic App quota requirements using the same App Services quotas blade. You must choose one of the Logic App SKUs (WS1, WS2, WS3) when making the request, and it will be processed in the same way App Services requests are processed. We want your feedback! If you notice any aspect of the experience that does not work as expected, or you have feedback on how to make it better, please use the comments below to share your thoughts!Orchestrate Azure Container Apps Jobs with Apache Airflow
Azure Container Apps (ACA) Jobs are a great way to run work that starts, does something, and finishes: nightly batch, data processing, ETL, ML scoring, report generation. They scale to zero, bill per execution, and run any container you give them. But the moment your "one job" becomes "a set of jobs that depend on each other," a gap appears: How do I run twenty jobs in parallel, wait for all of them, then run one more job only if they all succeeded — and retry just the one that failed? A single ACA Job can't express that on its own. What you're describing is an orchestrator, and the most widely adopted one in the data world is Apache Airflow. This post introduces two open-source templates that connect the two, so Airflow becomes the brain and ACA Jobs become the muscle. Pick the one that matches what you already run: airflow-on-aca-jobs: you already have Airflow. Drop in an operator and point it at ACA Jobs. Host nothing new. airflow-hosted-on-aca: you don't have Airflow. Get a full one running on Azure Container Apps with one command. Both use the same operator and the same DAGs, so you can start with one and move to the other later without rewriting your workflows. See Airflow orchestrate real ACA Job executions with parallel fan-out, dependency ordering, and automatic retries. Why ACA Jobs need an orchestrator A plain ACA Job is great at one thing: run this container to completion, then stop. That covers a scheduled job or a one-off task perfectly. Real pipelines need more than that: Dependency ordering: step B runs only after step A succeeds. Parallel fan-out: launch one execution per file, per store, or per partition, all at once, then wait for the whole batch. Per-task retries: if one execution in a batch of fifty fails, retry just that one, not the other forty-nine. Backfills and scheduling: re-run yesterday's pipeline, or run every night with a full history of what happened. These are the problems an orchestrator solves. Instead of building that logic yourself, you let Airflow handle the graph, the scheduling, and the retries, while ACA Jobs run the compute. You get serverless, scale-to-zero workers, and you didn't have to stand up a scheduler to get them. The operator that ties them together Both templates ship the same small plugin: an Airflow operator called AzureContainerAppsJobOperator . In a DAG it looks like any other task: report_sales = AzureContainerAppsJobOperator( task_id="report_store_sales", subscription_id="{{ var.value.azure_subscription_id }}", resource_group="{{ var.value.aca_resource_group }}", job_name="{{ var.value.aca_job_name }}", image="python:3.12-slim", command=["python", "-c", MY_PROGRAM], env_vars={"STORE_NAME": "Seattle"}, deferrable=True, ) A few things make this operator easy to work with: Per-execution overrides. It takes the ACA Job you point it at and overrides the image , command , args , and env_vars for that run. You can drive many different workloads from a single ACA Job definition, and you don't need to build or push a custom image just to try something. The example above runs the stock python:3.12-slim image with an inline program. Deferrable by default. With deferrable=True , Airflow frees its worker slot while the ACA Job runs and resumes when it finishes. That means your fan-out width is bounded by ACA, not by how many Airflow workers you have. You can launch dozens of parallel executions cheaply. No secrets required. Authentication resolves in a sensible order: an Airflow Connection if you set one, otherwise an AZURE_ACCESS_TOKEN environment variable, otherwise DefaultAzureCredential (managed identity). In Azure, the hosted template uses a managed identity so nothing sensitive is stored in Airflow at all. Because both templates share this operator, a DAG written for one runs unchanged on the other. Option 1: Bring your own Airflow (host nothing) Choose airflow-on-aca-jobs if you already run Airflow: Azure Managed Airflow, MWAA, Astronomer, or your own deployment. You keep that Airflow exactly as it is and simply teach it to talk to ACA Jobs. +------------------------------------------+ | Your Airflow (you host it, unchanged) | | runs AzureContainerAppsJobOperator | +------------------------------------------+ | | ACA Jobs REST API v +------------------------------------------+ | ACA Job (Azure Container Apps) | | | | store 1 | store 2 | ... | store N | | parallel executions -> scale to zero | +------------------------------------------+ Your existing Airflow runs the operator; ACA Jobs run the work. You host nothing new. Adoption is three small steps: Copy the operator into your Airflow's plugins/ folder. Add a DAG that uses AzureContainerAppsJobOperator . Set three Airflow Variables so the operator knows which job to drive: Airflow Variable Value azure_subscription_id your subscription id aca_resource_group the resource group holding the ACA Job aca_job_name the ACA Job name That's the whole integration. Nothing new to host, no extra scheduler or database, no custom image. ACA Jobs just become another task type Airflow can call. If you want a job to point at first, the template includes an Azure Developer CLI ( azd ) deployment that stands up a sample ACA Job for you: git clone https://github.com/hetvip2/airflow-on-aca-jobs cd airflow-on-aca-jobs azd up # deploys a sample ACA Job, prints its resource group + name Then copy airflow/plugins/ and airflow/dags/ into your Airflow, set the three Variables, and trigger the DAG. Option 2: Airflow hosted on ACA (turnkey) Choose airflow-hosted-on-aca if you don't already have an orchestrator and want one running next to your jobs. One command provisions the whole thing on Azure Container Apps: azd up | v +------------------------------------------+ | Airflow control plane on ACA | | web | scheduler | triggerer | | Postgres (metadata) + Azure Files (dags)| | Managed Identity - no secrets stored | +------------------------------------------+ | | ACA Jobs REST API v +------------------------------------------+ | ACA Job (Azure Container Apps) | | | | store 1 | store 2 | ... | store N | | parallel executions -> scale to zero | +------------------------------------------+ One command deploys the whole Airflow control plane on ACA, right next to the jobs it drives. git clone https://github.com/hetvip2/airflow-hosted-on-aca cd airflow-hosted-on-aca azd env new my-airflow azd up # prints your Airflow URL when it finishes azd up deploys a complete, working Airflow control plane on ACA: airflow-web, airflow-scheduler, and airflow-triggerer running as Container Apps on LocalExecutor, so there's no Celery or Redis to operate. A Postgres metadata database. A user-assigned managed identity with permission to call the ACA Jobs API, so the operator authenticates with no secrets stored in Airflow. A sample ACA Job for Airflow to drive out of the box. Your DAGs and plugins live on a mounted Azure Files share, so you ship new workflows by re-uploading files rather than rebuilding an image: cp my_dag.py airflow/dags/ azd hooks run postprovision # uploads dags + plugins to the share Airflow picks up the change within a minute. You now own a real orchestrator, hosted serverlessly on the same platform as your jobs. Which one should you pick? Option 1: airflow-on-aca-jobs Option 2: airflow-hosted-on-aca Best when You already run Airflow You don't have Airflow yet Setup Copy the operator + a DAG + 3 Variables azd up (one command) Who hosts Airflow You do (unchanged) Azure Container Apps Authentication Connection or short-lived token Managed identity, nothing stored Ownership Lowest: nothing new to run Turnkey: a full orchestrator you own The important part: the workload never changes. The same DAG and the same operator drive the same ACA Job executions in both. Start wherever you are today, and switch later with zero changes to your pipelines. See it end to end Picture a retailer that wants one number every night: total sales across all stores. Each store reports its own sales as a separate ACA Job execution, all running in parallel. When every store is in, a final job adds them into the company total. That one workflow exercises exactly what a plain Job can't do alone: parallel fan-out: one ACA Job execution per store, all at once dependency ordering: the roll-up runs only after every store reports per-task retries: if a store's execution fails, Airflow retries just that store, and the nightly total still lands In Airflow's Graph view you watch the store tasks light up together, then the roll-up run last. In the Azure portal you watch real executions appear under your ACA Job and scale back to zero when they finish. Same job, same DAG, whichever template you chose. Call to action If you run batch, ETL, or any multi-step work on Azure Container Apps Jobs, give one of these templates a try: Already have Airflow? Start with airflow-on-aca-jobs. Need an orchestrator? Start with airflow-hosted-on-aca. Both are open source, deploy with azd up , and share the same operator so you can move between them freely. Try them out and let us know what you orchestrate.
