Umbraco Compose Enters the Picture

Umbraco Compose became public in February 2026, after months of discussion among partners and teams already working close to the platform. Rather than arriving with a broad announcement or a change in publishing direction, Compose appeared as a focused cloud service aimed at preparing data for use by Umbraco-based websites, apps, and search services.

The timing reflects how Umbraco platforms are being used today. Content continues to be managed through the CMS, yet a growing share of information shown on those sites is prepared elsewhere. Product catalogues are often maintained by commercial groups. Reference data is updated in shared tools. Pricing tables and structured lists are changed outside the CMS before being published on the website. Compose was introduced to deal with that reality rather than to redefine how content teams work.

What Umbraco showed during the Winter Keynote

During the Winter Keynote, Umbraco’s CTO Philipp spent time walking through how Compose fits into everyday platform work. The examples focused on catalogue and reference data prepared outside the CMS and then used during page editing.

Editors continued creating pages in Umbraco the same way they already do, writing copy, placing components, and selecting related items as part of the page build. Instead of copying values or tracking updates manually, they selected prepared entries where the content is edited. The walkthrough stayed away from feature lists and focused on how this approach avoids extra changes to page building, publishing, and content updates when data is maintained elsewhere.

What Umbraco Compose does in day to day work

Compose works as a preparation layer. Data connects into it from sources such as spreadsheets, internal services, or APIs. That data is then exposed through GraphQL so delivery channels can request what they need in a consistent format.

Editors do not move their work into a new tool. Pages, media, and publishing continue inside Umbraco CMS. External data appears as selectable entries during editing, which reduces follow-up work and lowers the chance of inconsistencies across pages.

This separation between preparation and delivery is where Compose fits. Websites and apps ask for prepared data rather than adapting to each source directly, which limits how often delivery work needs revision.

Platforms that connect directly to each data source often require repeated changes in front-end code, search ingestion, and integration logic as ownership changes. Over time, this increases coordination work during updates.

Compose centralises data preparation. Sources connect once, and websites and search tools request prepared output in a consistent format. Updates stay contained in the preparation layer, which reduces follow-up work during campaigns and catalogue changes.

Why does it draw attention?

From a planning point of view, Compose reduces how often delivery channels need adjustment. Without a preparation layer, every new data source tends to affect front-end code, search ingestion, and integration logic. Over time, that effort adds up and begins to influence roadmap discussions.
Compose concentrates that work in one place. Data sources connect once, and delivery channels rely on prepared output rather than source-specific logic. For organisations that expect internal tools to change more often than public platforms, this approach supports longer planning cycles.

How websites and search use the same prepared data?

Search experiences often require their own ingestion paths, separate from the website. That separation introduces duplication and additional maintenance, especially when content and catalogue data change on different schedules.

Compose allows search tools to consume the same prepared data used by the website. Content and structured data appear together because they share one preparation path. Filtering and linking become easier to maintain, since changes happen at the preparation stage rather than being repeated across integrations.

For catalogue-driven sites and campaign-heavy platforms, this reduces coordination work during updates and shortens the time between data changes and public visibility.

How editorial responsibility works with Compose

Compose follows the same responsibility model used elsewhere in Umbraco. Editors decide what is published. Prepared data appears during editing, and selection happens before anything reaches a public page.

During the keynote, Umbraco also showed usage records inside the backoffice. These records support follow-up and accountability rather than automated publishing. Content owners continue deciding what goes live, while platform teams retain visibility into how preparation tools are used.

Cost and planning conversations

Umbraco Compose pricing is based on ingestion activity. There are no user-based limits and no charges tied to schema size. Cost increases when data is prepared or updated, not when traffic grows or additional editors join.

For organisations planning campaigns or catalogue updates, this allows forecasting based on how often data changes rather than how the site is structured.

Where Compose fits in an Umbraco roadmap

Compose is most relevant once a site depends on several data sources or supports more than one delivery channel. Content-only sites with limited external inputs may see little immediate benefit, while platforms coordinating work across groups often recognise the value earlier.

The decision usually comes down to how much effort is spent adjusting delivery whenever data ownership changes.

A partner view

At Phases, our work with Umbraco platforms often involves reviewing how data is prepared and how that work affects delivery over time, especially on platforms used by several departments. As an Umbraco Contributing Gold Partner, this has included regular reviews of catalogue updates, reference data, and editorial workflows to understand where delivery effort increases as data ownership evolves.

That experience supports organisations that want to review whether their current platform structure would benefit from adding Compose, particularly where several internal groups contribute information that reaches public pages and search. Walking through existing data flows and past delivery changes provides a factual basis for deciding whether Compose fits into the roadmap and how it can be introduced without creating additional work for editors or delivery teams.

Get Started