Community blogs

Ronald van der Plas · Aug 10, 2026

New in Content Hub Power Extension: Cheat Sheets

I’ve released a new version of the Content Hub Power Extension, now including a new Cheat Sheets section. The first cheat sheets focus on Scripting, Triggers and Actions, giving you a quick reference while working with Sitecore Content Hub. Instead of searching through documentation or old examples, you can keep the most useful information close at hand while building and configuring your solution. This is only the start. I plan to expand the cheat sheets with more useful Content Hub topics over time. If you’re already using the Content Hub Power Extension, make sure to update to the latest version and give it a try!

Ronald van der Plas · Jul 30, 2026

Content Insights Tip #83 | Bulk vs Non-Bulk in Sitecore Content Hub: Choosing the right execution strategy

When creating an External Mass Action in Sitecore Content Hub, one of the configuration options you'll encounter is the Bulk toggle. It's easy to overlook. After all, it is just a single checkbox in the Selection component, surrounded by several other settings that appear equally important. Yet this checkbox has an impact that most people might not realise. It doesn't simply determine whether multiple assets can be processed together. Instead, it changes how Content Hub communicates with your external service and, more importantly, where the responsibility for processing those assets lives. At first glance, the difference seems straightforward. With Bulk disabled, Content Hub sends a single request for every selected asset. Enable Bulk, and those assets are grouped into a single request. While that's technically correct, it doesn't explain why Sitecore offers both options or when one approach is more suitable than the other. To answer that question, let's first look at what actually changes. Non-Bulk processing When Bulk is disabled, every selected asset results in its own HTTP request. If a user selects three assets, your endpoint is invoked three times. Each request contains information about a single asset, making every execution completely independent from the others. Request 1 { "TargetId": 34181, "TargetIdentifier": "xEYMBs3UTo6ZDN_Xp8ykgg", "context": {} } Request 2 { "TargetId": 34253, "TargetIdentifier": "o-SNrVDwTRWIzcHG0cu8VA", "context": {} } Request 3 { "TargetId": 34127, "TargetIdentifier": "hqFQTkdmQGeHDIJDzBnHRw", "context": {} } This execution model has an important consequence. Content Hub is invoking your service once for each selected asset. Your service doesn't know how many assets the user selected, because each request always contains a single asset. Bulk processing With Bulk enabled, the interaction changes. Rather than invoking your endpoint once per asset, Content Hub does a single request that contains all selected assets. { "targets": [ { "TargetId": 34181, "TargetIdentifier": "xEYMBs3UTo6ZDN_Xp8ykgg", "context": {} }, { "TargetId": 34253, "TargetIdentifier": "o-SNrVDwTRWIzcHG0cu8VA", "context": {} }, { "TargetId": 34127, "TargetIdentifier": "hqFQTkdmQGeHDIJDzBnHRw", "context": {} } ] } Notice that not only the number of HTTP requests changes, also the JSON contract itself changes. Instead of receiving a single asset, your service receives a collection of assets and becomes responsible for processing them. That distinction may appear subtle, but architecturally it is significant. An execution strategy, not a performance setting One misconception I regularly encounter is that Bulk should simply be enabled for better performance. While it often reduces the number of HTTP requests, that's not the reason why the option exists. The real question is much simpler: Where should the iteration happen? Should Content Hub invoke your service once for every asset, or should your service receive a collection of assets and decide how to process them? That decision has consequences far beyond the transport layer. It affects how you design your queues, how you prioritise work, how you handle failures, and ultimately how your application scales. Consider an AI enrichment service that supports both scheduled processing and urgent requests. Every night, editors submit hundreds of assets for transcription or metadata generation. Those requests are ideal candidates for Bulk processing because the service can optimise throughput and process the work whenever capacity becomes available. Now imagine an editor who needs a single asset enriched immediately before publishing. That request shouldn't wait behind hundreds of scheduled jobs. Instead, it can use a separate Non-Bulk action that places the work directly into a priority lane. Although both actions call the same service, they represent two completely different execution strategies. This is why the choice between Bulk and Non-Bulk should always be driven by functional requirements rather than performance alone. When Content Hub is the caller There's another architectural principle worth mentioning. It can be tempting to assume that because Content Hub initiates the request, the data it sends is always ready to process. In practice, your service should never rely on that assumption. Your endpoint should validate whether an asset is still available, whether it is in the correct lifecycle state, and whether processing it actually makes sense. Likewise, if processing the same asset twice would cause problems, your implementation should be resilient enough to handle duplicate requests gracefully. These responsibilities belong to the service, not to Content Hub. The platform is responsible for invoking your endpoint. Your responsibility is to build an endpoint that behaves correctly under all circumstances. Conclusion The Bulk toggle may be one of the smallest configuration options in Sitecore Content Hub, but it represents an important architectural decision. It determines who is responsible for iterating over assets, influences how your application handles prioritisation and scalability, and shapes the overall execution model of your integration. The next time you create an External Mass Action, don't ask yourself whether Bulk is faster. Instead, ask a different question: Where should the iteration happen? More often than not, the answer to that question will also tell you which option to choose.

Ronald van der Plas · Jul 30, 2026

Content Insights Tip #82 | Monitor your GitHub Copilot AI credit usage

GitHub Copilot has become an important part of our development workflow in Visual Studio Code. What started as inline code completion has developed into a capable coding agent that can analyse repositories, edit multiple files and execute increasingly complex development tasks. Like many digital services, AI tools were initially priced aggressively to encourage rapid adoption. Now that developers and organisations are becoming increasingly dependent on them, prices and usage limits are gradually increasing. Running these models remains expensive, so it is unlikely that AI usage will become cheaper or less restricted in the near future. That makes it more important than ever to create awareness around token consumption and reduce unnecessary usage. Before we can prevent tokens from being wasted, we first need insight into how many credits we are consuming and which activities are responsible. For developers using GitHub Copilot Business or Enterprise through their employer, reaching a limit will not usually result in a personal bill. It can, however, prevent you from continuing to use Copilot Chat, Agent Mode and other AI-powered features until additional credits become available or the allowance resets. Fortunately, GitHub provides several ways to monitor your usage. Check your Copilot usage in GitHub Open your personal GitHub settings and navigate to: Profile picture → Settings → Copilot → Features. You can also open the page directly: github.com/settings/copilot/features. The Usage section shows how much of your included AI Credit allowance has already been consumed. This is the official usage information connected to your account, so it should be your main reference when checking how close you are to your limit. For professional Copilot plans, inline suggestions and Next Edit Suggestions do not consume AI Credits. The relevant usage comes primarily from features such as Copilot Chat, Agent Mode, Copilot CLI and other model-driven interactions. Check your usage from Visual Studio Code You can also view your current usage without leaving Visual Studio Code. Click the Copilot icon in the status bar to see the limits applying to your account and when they reset. This is useful after a long Agent Mode session or when using more capable reasoning models. A single task may involve several model calls, large amounts of repository context and multiple sub-agents behind the scenes. The built-in indicator tells you how much usage remains, but it does not necessarily explain which sessions consumed those credits. Understand where your credits are going For more details, you can install the third-party Copilot Cost & Token Tracker extension for Visual Studio Code. The extension reads the Copilot agent logs stored locally by Visual Studio Code and creates a dashboard showing: Estimated AI Credits per session Usage broken down by model Input, output and cached tokens Main-agent and sub-agent calls Aggregated usage over time This can help identify why one session consumed considerably more than another. Perhaps Copilot repeatedly loaded a large amount of context. Maybe it used a powerful model for a relatively simple task, created several sub-agents or kept retrying an unsuccessful approach. The extension should be treated as a diagnostic tool rather than an official billing overview. It only sees the sessions available in your local Visual Studio Code logs and calculates its results using its own pricing information. A useful distinction is: GitHub shows how close you are to your actual limit. The extension helps explain which local sessions consumed your credits. As with any third-party extension used in a professional environment, check whether your organisation permits its installation. My thoughts Usage-based pricing is understandable. A short coding question and an autonomous agent working across an entire repository clearly do not require the same amount of computing power. However, we are paying for the tokens consumed, not for the value of the result. An agent can use a large amount of context, call several tools and generate thousands of tokens, only to produce a solution that does not compile or completely misunderstands the problem. Those tokens cost exactly the same as tokens that resulted in a perfect solution. I would like to have the option to rate the value of an AI response. Was it useful, partly useful or completely useless? When a solution is terrible, should we really pay the full price for the tokens used to create it? In practice, this would be difficult to implement fairly. The model provider has already incurred the infrastructure costs, the quality of an answer is subjective, and a refund system would be easy to abuse. LLM providers also cannot guarantee that every answer will be correct. I therefore do not expect a thumbs-down button to return our AI Credits anytime soon. Still, it is an interesting thought. AI providers already ask us to rate their answers because that feedback helps improve their models. Perhaps future usage dashboards should not only show how many tokens we consumed, but also help us understand whether those tokens produced something valuable.

Ronald van der Plas · Jul 22, 2026

Content Insights Tip #81 | Connect Your AI Coding Agent to Vercel with MCP

Vercel has released an official MCP server that connects supported AI tools directly to your Vercel projects. It is currently available in beta on all Vercel plans and supports tools including Claude Code, Codex CLI, Cursor, ChatGPT and VS Code with GitHub Copilot. What does Vercel MCP do? MCP stands for Model Context Protocol. It allows AI assistants to connect to external tools and data sources. Vercel MCP uses OAuth to grant your AI assistant access to the Vercel projects associated with your account. Once connected, your agent can: Search the Vercel documentation List and inspect projects View recent deployments Retrieve failed build logs Search runtime logs Investigate production and preview errors The runtime log tools can filter by environment, log level, status code, source and time range. You could, for example, ask: Find the latest failed deployment for this project and analyse the build logs. Or: Show me the production errors from the last hour and identify the most likely cause. How is this different from the Vercel Plugin? The Vercel Plugin and Vercel MCP complement each other, but they solve different parts of the same problem. The plugin mainly improves what your AI coding agent knows about Vercel. It adds platform-specific context, skills, specialist agents and commands for areas such as Next.js, deployments, caching, performance and environment variables. Vercel MCP goes a step further by connecting the agent to your actual Vercel environment. Instead of only understanding how the platform works, the agent can retrieve information about your projects, deployments and logs. In other words, the plugin helps your agent understand Vercel, while MCP enables it to work with the Vercel environment you use. For SitecoreAI projects with a Next.js frontend, combining both could be particularly useful. The plugin helps the agent understand the frontend platform, while MCP provides information about what is happening after that frontend has been deployed. Connecting your coding agent Vercel provides a general installer that detects supported AI coding tools: npx add-mcp https://mcp.vercel.com For Codex CLI, you can add it directly: codex mcp add vercel --url https://mcp.vercel.com The client will open an OAuth flow in your browser, where you authorise access to your Vercel account. Keep access in mind The connected AI system receives the same level of Vercel access as the user who authorises it. That makes the authentication step more than a simple technical formality, because the permissions granted to the agent determine what it can inspect and potentially change. For that reason, Vercel recommends keeping human confirmation enabled for tool execution. This allows the developer to review an action before the agent carries it out, which is especially important when working with production environments. A sensible way to begin is by using Vercel MCP for read-oriented tasks. Let the agent investigate failed deployments, analyse build and runtime logs, inspect project configuration and search the Vercel documentation. These scenarios already provide considerable value without immediately giving the agent responsibility for making changes. My thoughts Vercel MCP looks like a useful addition to the AI-assisted development workflow. Giving an agent direct access to deployment information, runtime logs and project configuration removes a great deal of manual context gathering. It allows the assistant to work with what is actually happening in your Vercel environment, rather than relying only on the code and information you provide manually. At the same time, that convenience makes it important to think carefully about access. An agent can only be as safe as the permissions it has been given. So human confirmation should remain enabled, particularly when production environments are involved. When security is a primary concern, it may be worth authorising the MCP connection through a dedicated Vercel account with fewer privileges. That account could be limited to the projects and actions the agent genuinely needs. This follows the principle of least privilege and reduces the potential impact if the tooling behaves unexpectedly or is influenced by untrusted input. Vercel MCP has the potential to become a valuable part of the development toolkit, but it should be introduced with the same care as any other integration that receives access to your environments. Source: Use Vercel's MCP server

Ronald van der Plas · Jul 14, 2026

Content Insights Tip #80 | Give your AI coding agent better Next.js knowledge for SitecoreAI

When building a SitecoreAI headless frontend with Next.js, your AI coding agent needs to understand more than just React and TypeScript. Vercel has released an official plugin that provides coding agents with Vercel and Next.js-specific context, skills, specialist agents and slash commands. Install it with: npx plugins add vercel/vercel-plugin The plugin currently supports tools including Claude Code, OpenAI Codex, Cursor, GitHub Copilot, Grok Build and Kimi Code. It adds 28 skills covering subjects such as: Next.js App Router and Server Components React and Next.js performance Caching and cache invalidation Environment variables Deployment and CI/CD Vercel Functions Security and firewall configuration AI SDK and AI Gateway For example, you can explicitly activate the Next.js knowledge using: /vercel-plugin:nextjs The plugin is lightweight by default, automatically adding session context only in empty directories or detected Vercel and Next.js projects. Although it does not teach your agent how SitecoreAI works, it can significantly improve its understanding of the surrounding Next.js frontend. Combined with project-specific instructions and SitecoreAI skills, this creates a much stronger baseline for AI-assisted Sitecore development. More information is available in the Vercel Plugin documentation. Happy Codin'!

Ronald van der Plas · Jul 6, 2026

Automatically transcribing Sitecore Content Hub videos with Azure AI Video Indexer

Video accessibility is one of those topics that sounds simple until you need to support it at scale. For a single video, creating subtitles manually is manageable. For a larger video library, the process quickly becomes repetitive and error-prone. Someone needs to download the video, send it to a transcription service, wait for the results, upload the subtitle file, add the correct metadata, link it to the original video, and make sure it is ready for publishing. That is exactly the kind of process I like to automate. In this post, I want to walk through an architecture for automatically transcribing videos from Sitecore Content Hub with Azure AI Video Indexer. The implementation started with a Sitecore-provided (by Jeroen Feyaerts of Sitecore Professional Service) C# coding sample. That sample demonstrated the core integration flow. I then refactored and extended it into a more production-oriented implementation with Azure Functions, queue-based throttling, callback handling and a clearer separation between Content Hub, Azure AI Video Indexer and the integration layer. The goal is simple: Take a video asset from Sitecore Content Hub, generate subtitles with Azure AI Video Indexer, and store the generated subtitle back in Content Hub as a managed asset related to the original video. This is not AI for the sake of AI. It is a practical DAM automation that improves accessibility and removes manual work from the content process. The problem Sitecore Content Hub is a great place to manage video assets, metadata, renditions, relations and publishing workflows. But subtitles often still end up as a separate process. That separation creates a few problems. The challenge is that manual subtitle creation does not scale well. Someone has to manage the transcription process outside of the DAM, which already introduces extra work and coordination. On top of that, different people may create and upload subtitles in different ways, using different naming conventions, metadata structures and storage locations. That may be manageable for a handful of videos, but once you are dealing with hundreds or thousands of existing assets, the process quickly becomes inconsistent, hard to govern and difficult to maintain. The solution The solution starts with a simple idea: use Content Hub as the starting point, let Azure AI Video Indexer do the transcription work, and bring the generated SRT file back into Content Hub as a managed asset. A video in Content Hub already has metadata, renditions, lifecycle state and relationships to other assets or content. If subtitles are generated outside of that model and stored somewhere else, the result is disconnected from the DAM. That is what I wanted to avoid. The Azure Function acts as the orchestration layer between Content Hub and Azure AI Video Indexer. It finds the video in Content Hub, submits it for transcription, and handles the result when Video Indexer is done. When a video needs subtitles, the Function looks for the MP4 rendition. That rendition is used deliberately. The original video file can be very large, and sending that file to Azure AI Video Indexer would increase data transfer, processing time, and potentially cost. The MP4 rendition provides a more controlled version of the video that is still suitable for analysis. Azure AI Video Indexer downloads the MP4 rendition and uses both the audio and visual information to generate the transcription. The Function only passes the rendition URL, so it does not need to temporarily download, store and re-upload the video itself. Because video indexing can take time, the process is asynchronous. After submission, the workflow continues when Azure AI Video Indexer calls the configured callback endpoint. From that callback, the Function uses the original Content Hub asset identifier to connect the result back to the source video, downloads the generated SRT file, and uploads it into Content Hub as a related subtitle asset. The value is in closing the loop: the video starts in Content Hub, Azure AI Video Indexer generates the transcription, and the resulting SRT returns to the managed asset model. Two lanes: bulk and priority For bulk processing, the integration uses an Azure Storage Queue. Existing video libraries can contain hundreds or thousands of assets, so sending everything directly to Azure AI Video Indexer would be risky. The queue gives control over throughput, and a scheduled Azure Function can process the work at a safe pace. Single assets can take a different path. When an editor needs subtitles for a video that is about to be published, that asset should not have to wait behind a large archive backfill. For that scenario, the integration supports a priority lane that submits the video directly to Azure AI Video Indexer. The queue is the safe path for bulk processing. The priority lane is the fast path for urgent single-asset processing. It may bypass the waiting queue, but it should never bypass validation, logging, duplicate detection or state tracking. Important caveat: idempotency One important production caveat is idempotency. A queue helps to control throughput, but it does not automatically prevent duplicate work. The same video can still be triggered multiple times through bulk processing, manual actions or retries. To handle that, the integration should keep a small technical job state outside of Content Hub. In this case, Azure Table Storage is a good fit: it is simple, fast and enough to track whether a transcription job already exists for a specific asset, language and indexing preset. That gives the integration a quick decision point before adding work to the queue or submitting a video to Azure AI Video Indexer. The queue remains responsible for transport and throttling, while Table Storage helps prevent duplicate processing. Do not turn Content Hub into a workflow log The job state is important, but that does not mean every technical status update should be written back to Content Hub. During a large backfill, constantly updating assets with statuses like queued, submitted, processing or retrying would create unnecessary API traffic. It would also make Content Hub responsible for the technical orchestration state, which is not the role I want it to play in this architecture. Content Hub should be updated when there is a meaningful content outcome: the generated SRT asset is created, related to the original video and moved into the right lifecycle state. The detailed processing state belongs in Azure Table Storage and Application Insights. Content Hub should contain the managed result, not every internal step of the integration. Closing thoughts The core API flow is only one part of this solution. The real architectural value is in the operational choices around it: how to process large video libraries safely, how to let urgent assets jump the queue, how to prevent duplicate work, and how to avoid unnecessary pressure on Content Hub. That separation of responsibilities is what makes the architecture practical. Content Hub manages the assets, metadata, lifecycle and relations. Azure AI Video Indexer generates the transcription. Azure Functions orchestrate the workflow. Azure Storage Queue controls bulk throughput. Azure Table Storage helps with idempotency and fast decision-making. At the same time, Content Hub users should still have visibility. For a bulk transcription run, the Azure Function could create a Content Hub task that shows the functional progress to editors and asset managers. That task is for visibility only. The actual orchestration remains in Azure, where the queue, Table Storage and Functions control the workflow. That is where a simple API integration becomes a reliable content workflow: practical, targeted and useful. Not a generic AI demo, but a focused automation that improves accessibility, reduces manual work and fits naturally into the Sitecore Content Hub ecosystem.

Jeroen Breuer · Jul 2, 2026

Monitoring a Sitecore XM/XP migration inside Sitecore Pages

Running Sitecore XM/XP and SitecoreAI side by side during migration makes it hard to know which platform serves a page. Here's a small Marketplace app that shows it live, right inside Sitecore Pages.

Ronald van der Plas · Jul 2, 2026

AI agents need a safe place to act

The Microsoft announcement of Azure Container Apps Sandboxes caught my attention, especially because Mo Cherif from SitecoreAI is quoted in it. For me, that is more than a nice Sitecore mention. It is an architectural signal. AI is moving from suggestion to action. Agents are no longer only helping us write text or generate code snippets. They can inspect repositories, call tools, run scripts, interact with APIs and eventually support real DXP work such as content assembly, personalisation, campaign optimisation, and workflow automation. Source document by Microsoft The real risk The risk is not only the AI model itself. The bigger risk is often the environment around it. An MCP server can expose powerful tools. A local model can still access files or credentials if we connect it to the wrong runtime. A rogue skill, plugin or prompt injection can influence what an agent executes. So the key question is not only: Can the agent do this? The better architectural question is: Where is the agent allowed to do this, what can it access, and how do we contain the blast radius if something goes wrong? The solution direction The answer is a controlled execution layer. A simple model could be: In practice, that means we should run AI-generated code in isolated environments, give agents only the tools they need, restrict filesystem, network and secret access, log what happens, validate the output and keep human approval for destructive actions or production changes. This is where sandboxed execution becomes interesting. Not because it magically solves AI security, but because it gives agents a safe place to work. Why this matters for DXP For DXP platforms, this matters a lot. A modern DXP touches content, assets, customer data, analytics, campaigns, APIs and frontend applications. Agents can add real value there, but only if we design the guardrails around them. My takeaways AI agents must be allowed to help, but they should not automatically inherit unlimited trust. Running AI locally is not automatically safe if the tools around it still have broad access. Sandboxed execution, policy, observability and controlled promotion will become important building blocks for serious agentic DXP architectures. That is why I like this direction. It moves the conversation from “what can AI generate?” to “where can AI safely act?”

Ronald van der Plas · Jun 30, 2026

Keeping Azure Container Apps secure without blind production updates

In my previous post, I wrote about Azure Container Apps as a runtime layer for composable headless architectures. One question that came up afterwards was very practical: How do you keep the container images running in Azure Container Apps secure and up to date? That is an important question. Once you run frontends, APIs, workers, jobs and integrations as containers, the security of those workloads depends heavily on the images you deploy. But there is an important nuance. The goal is not to automatically update production every time a new image is available. The goal is to automate the image lifecycle while keeping production promotion controlled. Security automation should help you move faster. It should not silently replace production with an unvalidated runtime. Containers are not patched in place A container image can become vulnerable even when your own application code has not changed. A CVE can be found in the operating system layer. A base image can receive a security update. A framework or package dependency can become vulnerable. That means container image security is not a one-time deployment task. It is a continuous process. The principle is simple: You do not patch a running container. You rebuild the image, validate it, and promote a new version. Microsoft Defender for Cloud can help detect vulnerable images and make security findings visible. The actual remediation still belongs in your delivery process. More background: view and remediate vulnerabilities for registry images. Do not use latest in production One of the easiest ways to create production risk is to deploy with a mutable tag such as latest. It looks convenient, but it reduces traceability. If production runs:my-app:latest. Which build is that? Which commit created it? Which scan result belongs to it? Which version is actually running? It can also create inconsistent runtime behaviour. New replicas may pull the new meaning of latest, while existing replicas still run the previous image behind the same tag. For production, use a unique image tag or deploy by digest: myregistry.azurecr.io/my-app:build-1042 or: myregistry.azurecr.io/my-app@sha256:... The architectural point: production should point to an exact image version, not to whatever a mutable tag happens to mean at startup time. Microsoft has more details here: image tag best practices. Automate rebuilds, not production replacement When a CVE is detected, automation should do the repetitive work. It should rebuild the image. It should scan the image. It should sign the image. It should deploy the image to staging. It should run tests. But production should not be silently replaced. A patched image can still break the application. The base image may behave differently. The runtime may have changed. A package update may introduce a breaking change. So the split should be clear:Automatic: detect → rebuild → scan → sign → deploy to staging → test Controlled: approve → deploy exact image to production → monitor → rollback if needed For rebuild automation, Azure Container Registry Tasks can help, especially when base images are updated: ACR Tasks and base image updates. For production control, use the approval mechanisms of your delivery platform: Azure DevOps approvals and checks GitHub deployment environments The important architectural point is that the build process should not automatically have the right to update production. Use revisions where they fit Azure Container Apps has a useful deployment concept: revisions. When you deploy a new image, Azure Container Apps can create a new revision. For HTTP workloads, that revision can be tested, routed to and rolled back from. That makes it useful for controlled rollout patterns such as blue-green deployments or gradual traffic shifting. More background: Azure Container Apps revisions Traffic splitting in Azure Container Apps Architecturally, this means you do not have to think in terms of “replace the app”. You can think in terms of “introduce a new revision”. That is especially useful under security pressure. You can move quickly, but still keep production controlled. Be careful with workers and jobs One caveat is important. Not every Container App should be rolled out in the same way. Traffic splitting works well for HTTP workloads because incoming traffic can be routed between revisions. For workers, queue consumers and integrations, that is different. If two worker revisions are active at the same time, both may consume messages. That can be fine, but only if the worker is designed for it. For Container Apps Jobs, the model is different again. Jobs are updated directly and do not use the same revision-based rollout model. More background: application lifecycle management in Azure Container Apps. The architectural rule is simple: A frontend, an API, a worker and a scheduled job may all run on Azure Container Apps, but they do not all need the same release strategy. Sign and promote exact images In more mature environments, I would also include image signing. This helps prove which image was approved and promoted. Be aware that Docker Content Trust is being phased out in Azure Container Registry. Microsoft is moving towards the Notary Project and Notation. More background: transition from Docker Content Trust to Notary Project. The architectural point is simple: Production should run an exact, traceable, validated image. Not a moving tag. Not whatever was latest at the time. Not an image that skipped the release process. My conclusion Keeping Azure Container Apps secure is not about magically updating running containers. It is about rebuilding, validating and promoting exact image versions through a controlled process. Automate the parts that should be automated: detect → rebuild → scan → sign → deploy to staging → test Control the parts that affect production: approve → deploy exact image to production → monitor → rollback if needed That is the balance I would aim for. Move fast on CVEs. But do not turn security automation into blind production automation.

Ronald van der Plas · Jun 25, 2026

Dutch Sitecore MVPs now featured on SUGNL

Today, I launched another new section on the SUGNL website: Dutch Sitecore MVPs. This page celebrates the Sitecore MVPs from the Netherlands and brings them together in one place. The MVP community has always played an important role in sharing knowledge, helping others, and strengthening the Sitecore ecosystem. With this new page, I wanted to make it easier to discover who the Dutch MVPs are and give them a visible place on the SUGNL website. You can check out the page here: https://www.sugnl.net/dutch-mvps The page currently shows the Dutch Sitecore MVPs for 2026 and includes a year filter, so you can also look back at previous years. The data is fetched from the official Sitecore MVP directory, which means the page stays close to the source while presenting the information in a way that fits the SUGNL community website. For me, this is another small step in making SUGNL more useful as a central place for the Dutch Sitecore community. We now have events, community blogs, and a dedicated overview of Dutch Sitecore MVPs. Step by step, the platform is becoming a better place to discover people, knowledge, and activity within the community. If you spot something that can be improved or have ideas for the page, feel free to reach out or contribute through the SUGNL GitHub repository.

Jeroen Breuer · Jun 17, 2026

My Codegarden 2026 highlights

A summary of my Codegarden 2026 highlights.

Ronald van der Plas · Jun 17, 2026

Discover Community blogs on SUGNL

Today I launched a new feature on the SUGNL website: Community Blogs. The idea is simple: bring articles and updates from people in the SUGNL community together in one place. There is already a lot of great content being shared by people in the Dutch Sitecore community, but it is often spread across personal blogs and different websites. With this new page, we want to make that content easier to discover and give community members another way to share their knowledge. You can check out the new feature here: https://www.sugnl.net/community-blogs The page is powered by RSS feeds, so new posts can automatically appear on the SUGNL website once a blog has been added. If you have a blog and would like to be included, please reach out to me directly. I can either add your feed for you or help you get added to the GitHub repository so you can contribute it yourself. The relevant file can be found here: https://github.com/rvdplas/sugnl/blob/main/lib/blogFeeds.ts SUGNL is a community initiative, so this is another small step toward making the platform more open, useful, and community-driven. If you write about Sitecore, composable architecture, frontend development, content platforms, AI, or anything else that could be interesting for the SUGNL community, feel free to join in.

Jan Bluemink · Jun 11, 2026

Sitecore Content Migration Part 2: Sitecore Commander

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! 🎉

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.

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.

Ronald van der Plas · Jun 9, 2026

SUGNL is back — and the website is now open source

On 21 May 2026, we hosted the first SUGNL session in a long time. The turnout was good, the atmosphere was great, and it was fantastic to see the Sitecore community in the Netherlands come together again. That evening confirmed what we hoped for: there is still a lot of energy around SUGNL. With that in mind, we are moving forward and taking the next steps to bring the community back to life. As part of that, we have made the SUGNL website available in an open GitHub repository. This allows the community to help build and improve the website together. Whether you want to contribute code, improve content, fix small issues, or suggest new ideas, you are very welcome to participate. SUGNL is all about the community, so we would love the website to become a community effort as well. Take a look at the repository, join in, and help us make the SUGNL platform better step by step. #bettertogether

Jeroen Breuer · Jun 2, 2026

Umbraco OpenID Connect example with lightweight external members

The Umbraco OpenID Connect example has been updated to Umbraco 17.4.2 with support for lightweight external members . This stores members from an external provider as a minimal record instead of a full content entity.

Jan Bluemink · May 31, 2026

Sitecore Content and Layout Migration Part 1: Layout Manager Pro

Jeroen Breuer · May 29, 2026

Umbraco MVP 2026!

Woohoo! Proud to receive my seventh Umbraco MVP award in 2026, marking another year of sharing, building, and community-driven progress.