Ronald van der Plas · Jun 11, 2026
Content Hub Power Extension v2.2.0 - Custom links support
Content Hub Power Extension Gets custom links support 🚀 One of the most requested improvements for the Content Hub Power Extension has just arrived! I'm excited to announce a brand-new feature: Custom Links. Why Custom Links? Every Content Hub implementation is different. While the extension already provides quick access to many commonly used Content Hub pages and tools, there are always organisation-specific pages, custom portals, dashboards, and integrations that users rely on daily. Until now, these pages weren't always available directly from the extension. With the new Custom Links feature, that's no longer a limitation. What can you do? You can now add your own links directly to the extension, allowing you to: Open custom Content Hub pages with a single click Add links to project-specific dashboards Include links to external integrations Create shortcuts to frequently used administrative pages Personalise the extension to match your own workflow In short: if there's a page you visit often, you can now add it yourself. Future-Proof by Design One of my goals for the Content Hub Power Extension is to make it useful across as many Content Hub environments as possible. Custom Links make the extension much more flexible because you're no longer limited to the pages I've included out of the box. If your organisation introduces new pages or custom functionality, you can immediately add them yourself without waiting for an extension update. Have an idea? While Custom Links provide a lot of flexibility, I still want to continue improving the core experience. If you find yourself repeatedly adding the same type of shortcut or if there's a Content Hub feature that should be available out of the box, I'd love to hear about it. Feel free to send me your feature requests, suggestions, or feedback. The best ideas often come directly from Content Hub users, and several existing features started exactly that way. Try it today The latest version of the Content Hub Power Extension is now available in the Chrome Web Store. Thank you to everyone who continues to provide feedback and help shape the extension. Your suggestions make every release better. Happy Content Hubbing! 🎉
Read post →Ronald van der Plas · Jun 11, 2026
Azure Container Apps: the missing runtime layer in composable architecture
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 I see Azure Container Apps as a strong candidate for the runtime layer in a composable headless architecture. In this model, the CMS manages content, API Management governs access, the edge layer handles delivery, and platforms like DAM, PIM, search and commerce stay focused on their own domains. Azure Container Apps fills the gap between them: the custom application layer. 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.
Read post →Ronald van der Plas · Jun 9, 2026
Content Hub Power Extension v2.0.1
Content Hub Power Extension Updated: Fresh Links, Verified Functionality and New Icons I’ve just published an update to the Content Hub Power Extension for Chrome. For those who use Sitecore Content Hub on a regular basis, you probably know the feeling: there are quite a few management pages, tools and direct links that you need during the day. The extension was originally created to make that work a little easier by putting commonly used Content Hub shortcuts directly in your browser. With this update, I gave the extension a much-needed refresh. What has been updated? The most important change is that the links have been reviewed and updated to match the current version of Sitecore Content Hub. I also verified the main functionality again, so the extension should continue to help you quickly navigate to the places you need without manually searching through the interface. Next to that, I updated the icons to better match the latest look and feel of Content Hub. The extension should now feel more aligned with the current Content Hub experience again, instead of looking like something that belongs to an older version. Why this matters This extension is not meant to be complicated. It is a small productivity helper for people who work with Content Hub often and want to save a few clicks here and there. Those small improvements add up quickly, especially when you are switching between environments, checking configuration, managing assets, or jumping into frequently used management sections. Available in the Chrome Web Store The updated Content Hub Power Extension is available in the Chrome Web Store. As always, feedback is very welcome. If there are links, shortcuts or improvements that would make the extension more useful in your daily Content Hub work, feel free to reach out.
Read post →