Composable headless architectures give us a lot of freedom.
We can choose the CMS that fits our content model. We can use a DAM for assets, a PIM for product information, a commerce platform for transactions, a search engine for discovery, and a modern frontend framework such as Astro, Next.js or Remix for delivery.
That flexibility is exactly why composable architecture is so powerful. But it also introduces a practical question that is often underestimated:
Where do we run the custom application layer that connects all of this together?
In traditional DXP architectures, a lot of that responsibility lived inside the platform itself. The CMS was often also the rendering engine, the integration layer, the preview environment and sometimes even the place where custom business logic slowly started to grow.
In a composable architecture, we deliberately move away from that model. That means we need a different runtime strategy. For me, the latest Azure Container Apps announcements at Microsoft Build ’26 make that discussion a lot more interesting.
Composable architecture needs more than a CMS and a frontend
When we talk about composable DXP or headless architecture, we often focus on the big platform choices: CMS, DAM, PIM, commerce platform, search engine, frontend framework, API gateway, Firewall, CDN and more.
Those are important choices, but the architecture is not complete until we answer where the connective tissue lives.
A modern composable platform needs webhook receivers, cache revalidation logic, content indexing workers, scheduled synchronisation jobs, preview tooling, integration services and operational tools. That custom layer is what makes the composable architecture work in practice. It should not all live inside the CMS. It should not all live in the frontend. And it does not always need full Kubernetes complexity.
This is where Azure Container Apps fits very naturally.
Azure Container Apps as the application runtime
That could be an Astro frontend, a .NET Experience API, a Node.js webhook receiver, a background job that updates a search index, or a small internal tool that helps the platform team operate the environment.
The important point is this:
Azure Container Apps gives teams a way to run containerised workloads without immediately taking on the full operational weight of Kubernetes. For many composable DXP projects, that is exactly the middle ground we need.
Frontends, BFFs and Experience APIs
One of the clearest use cases is hosting the frontend and the Experience API. In a headless setup, the frontend should not need to understand every backend system in detail. It should not have to talk directly to the CMS, DAM, PIM, commerce engine, personalisation engine and search platform. That is where a BFF or Experience API becomes useful. The Experience API can shape data specifically for the channel. It can combine content, navigation, personalisation context, feature flags, search results and backend data into a clean contract for the frontend.
In this model, Azure Container Apps can host the public frontend, the Experience API, internal APIs and supporting services that should not be publicly exposed.
This creates a clean separation of responsibilities:
- The CMS remains focused on content.
- API Management remains focused on governance.
- The frontend remains focused on rendering.
- The Experience API remains focused on composition.
- Azure Container Apps provides the runtime.
Jobs for the operational glue
Composable platforms are event-heavy. A content item is published. A page needs to be revalidated. A CDN cache entry needs to be purged. A search index needs to be updated. An asset changes in the DAM. Product information changes in the PIM. These are not always long-running services, often they are finite tasks.
They start, do the work, and stop.
That is where Azure Container Apps Jobs become very relevant. For a composable headless architecture, I would look at Jobs for things like:
- processing CMS publish events
- mapping content changes to affected pages
- triggering selective page revalidation
- purging cache entries
- updating search indexes
- synchronising data between platforms
This part of the architecture is easy to underestimate. The website can be beautifully headless. The CMS can be clean. The frontend can be fast. But if publishing, revalidation, indexing and cache invalidation are fragile, the platform will still feel unreliable.
Composable architecture needs operational glue. Container Apps Jobs give that glue a proper runtime.
Why this matters
For architects, Azure Container Apps is becoming more relevant as a strategic runtime choice. Composable architecture is not only about selecting SaaS platforms. It is also about designing the custom application layer around those platforms. That layer needs to support frontends, APIs, workers, jobs, integrations, preview tooling, observability, security and increasingly AI-assisted workflows.
Kubernetes can solve many of these problems, but it also introduces complexity. Traditional App Service can solve some of them, but it does not always fit the mixed workload reality of composable platforms as naturally.
Azure Container Apps sits in a useful space between these options.
For developers, the value is practical. You can build a stack that fits the problem. A frontend in Astro or Next.js. An API in .NET or Node.js. A worker in Python. A job in whatever containerised runtime makes sense. You package it as a container and deploy it. That sounds simple, but it changes the development flow.
A team does not need a completely separate hosting model for every small integration. A developer does not need a full Kubernetes setup just to build a webhook receiver. And a project does not need to force logic into the frontend just because there is no obvious place to put it.
My conclusion
The Azure Container Apps announcements at Build ’26 are important because they strengthen a part of composable architecture that is often underdefined: the runtime layer. Composable headless platforms need more than a CMS and a frontend. They need a place to run Experience APIs, workers, revalidation logic, integrations, preview services and operational automation.
For me, Azure Container Apps is already one of the best fits for this runtime layer. The latest Build ’26 announcements make that position even stronger, especially with the added focus on AI agents, isolated execution and more flexible ways to run modern application workloads. Not because it replaces the rest of the architecture. But it gives teams a practical, scalable, container-based runtime for the custom logic that makes a composable platform work.
And that is exactly the kind of runtime layer modern composable platforms need.