Community blogs

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.

Jeroen Breuer · May 27, 2026

How I let Cursor build an Azure Search provider for Umbraco Search

I wanted to build an Azure Search provider for Umbraco and let Cursor do the heavy lifting. This is what that looked like from the first prompt to the final commit.

Ronald van der Plas · May 21, 2026

SitecoreAI Goes Framework-Agnostic

Last year, at SUGCON Europe, Liz Nelson spoke with us about the future of Sitecore XM Cloud, now called SitecoreAI. One of the things to me that stood out was the ambition to make Sitecore development more framework-agnostic. At this moment we only had a proper Next.js SDK and a start into a .NET SDK. The future of a framework-agnostic SitecoreAI is now. Sitecore has released documentation for framework-agnostic Sitecore development. The key message is simple: you can build a Sitecore site without using a dedicated Sitecore SDK. Sitecore manages the content, your application retrieves it through APIs, and your front end renders it using the framework or language of your choice. Sitecore has supported headless development for a while, but in practice, the front-end story was still closely connected to a specific SDKs and implementation patterns. With this new direction, teams get more freedom to use the technology that best fits their architecture, skills, hosting model, and long-term strategy. This definitely opens the door for other frameworks like Astro and Go. To the outside world this change doesn't seem like a big deal, but front-end developers are already framework agnostic. Since a headless CMS, should be headless and therefor not tied to a specific framework. This move brings SitecoreAI closer to the expectations of modern front-end teams: API-first, flexible, and less dependent on one specific framework or SDK. The CMS should manage content, structure, authoring, and experience capabilities. The front end should be free to evolve. My conclusion In my opinion, this is a good development and something that can help SitecoreAI adoption beyond the existing Sitecore community. For teams outside that ecosystem, framework support can be a deciding factor. If SitecoreAI does not fit their technology stack, they will look at other platforms. By becoming more framework agnostic, SitecoreAI lowers that barrier and gives teams more freedom to choose the front-end technology that best fits their project. At the same time, I would not describe SitecoreAI as purely headless. Sitecore itself positions it as a hybrid headless CMS, and that makes sense to me. The frontend is decoupled, but SitecoreAI can still pass layout and component information through its APIs. So while it is API-first and now framework-agnostic, it remains experience-driven rather than headless by content-only. And that is exactly where Sitecore makes the difference. It does not just expose content through APIs; it also preserves the authoring experience, page composition, and marketer control that have always been important strengths of the platform. That said, as AI becomes more involved in building front ends, the exact framework may become less important. What will matter more are strong APIs, clear content models, and flexible platform boundaries to build on. That is why this is an important step: not just toward more framework choice, but toward a more open, AI-ready future for SitecoreAI.

Ronald van der Plas · Apr 20, 2026

Vercel Security Incident (April 2026)

The recent security incident at Vercel highlights a growing reality: modern composable architectures introduce new attack surfaces, especially when external platforms, AI tooling and CI/CD pipelines intersect. In this case, the breach originated from a compromised third-party AI tool connected via Google Workspace OAuth, which enabled unauthorised access to internal Vercel systems and affected a subset of customers. (The Verge) For teams running SitecoreAI (XM Cloud) with a head application hosted on Vercel, this is particularly relevant. Your frontend layer, often holding environment variables, API tokens, and integration logic, can become a high-value target. Immediate actions to take (Recommendations by Vercel) While we continue to take actions to protect Vercel systems and customers, here are best practices you should follow: Review the activity log for your account and environments for suspicious activity. You can review activity logs in the dashboard or via the CLI. Review and rotate environment variables. If any of your environment variables contain secrets (API keys, tokens, database credentials, signing keys) that were not marked as sensitive, those values should be treated as potentially exposed and rotated as a priority. Take advantage of the sensitive environment variables feature going forward, so that secret values are protected from being read in the future. Investigate recent deployments for unexpected or suspicious looking deployments. If in doubt, delete any deployments in question. Ensure that Deployment Protection is set to Standard at a minimum. Rotate your Deployment Protection tokens, if set. For help rotating your secrets or other technical support, contact us through vercel.com/help. Final thought This breach is not about Vercel alone; it’s about the increasing dependency on interconnected tooling in modern architectures. We should increasingly automate our deployments, this include automatic key rotations as well. This is a good test to see how much time it will take to rotate keys, either automatically or manually ;). For Sitecore teams, the takeaway is clear: treat your head application platform with the same security rigour as your CMS and backend systems, because in a composable world, security is only as strong as your weakest link.