Community blogs

Jan Bluemink · Sep 5, 2026

Using the Sitecore Content Transfer API Locally with Docker

Ronald van der Plas · Aug 18, 2026

Content Insights Tip #84 | Sitecore moves Explorer retirement date forward to September 22

Sitecore has updated the retirement date for the Explorer application in SitecoreAI. Explorer will now be retired on September 22, 2026, earlier than previously communicated. The current Sitecore documentation still lists October 1, 2026 as the date on which Explorer will be deprecated, so this change moves the deadline forward by just over a week. Sitecore has indicated that after September 22, Explorer will no longer be available for access or use. If you are still using Explorer as part of your content management workflows, it is worth reviewing those workflows now and making sure they have been migrated before the new deadline. Page builder Content mode is the supported experience moving forward in SitecoreAI, so teams still relying on Explorer should make sure they are comfortable with the replacement before September 22.

Jan Bluemink · Aug 15, 2026

Sitecore Content and Layout Migration Part 3: Sitecore PowerShell Extensions

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.