Content Releases lets teams bundle changes, preview, and publish with confidence—turning messy content updates into a structured, reliable process.
Even Westvang
Co-founder and product person at Sanity
Published
Picture this: Your team is preparing for next month's major product launch. The marketing team must update the homepage, product pages, and documentation. Meanwhile, your content editors must keep publishing regular blog posts and updates. Your developers are building new features and want to coordinate the content changes with their code deployments.
The content choreography of this multi-dimensional scheduling dance quickly feels overwhelming:
Does this sound familiar? We've seen teams resort to spreadsheets, late-night publishing sessions, and document titles that say "DO NOT PUBLISH UNTIL THURSDAY."
We have been there, too. That's precisely why we built Content Releases. All the documents and this blog post are published as releases (because the proof is in the eating of the pudding, right?).
Today, we're making Content Releases available on the Growth plan and above, a powerful new feature in the Sanity Content Operating System that simplifies everything related to timed and bundled content changes.
Content Releases enables teams to:
Content Releases is a platform feature, which means that it's available as a user interface, APIs, and data models. You can build sophisticated release workflows that integrate with your existing tools and processes. For example, you can trigger releases based on e-commerce inventory updates, coordinate content deployment with feature flags, or sync releases across multiple Sanity projects.
Content Releases is available for everyone on the Growth plan and up. It includes 2 concurrent releases per organization. Contact your Sanity representative or if you need more than two.
Go to our documentation to learn more about configuration, the user interface, and API.
Content Releases comes with a range of useful features to ensure confident publishing and coordination:
Let's look at how different teams benefit from Content Releases:
For developers:
For content editors:
For product owners:
For technical leaders:
Content Releases introduces a simple but powerful concept: the ability to group multiple document changes into a single unit that can be previewed, validated, and published, and unpublished together – giving you complete control over your content's lifecycle.
Here's how it works:
What makes Content Releases especially powerful is the concept of release layering. You can plan multiple releases, each building on top of the other. This means you can:
The system automatically handles the complexity of managing these overlapping changes, ensuring that everything appears exactly as intended when published.
We've built Content Releases to be powerful yet flexible, with comprehensive API support that lets you integrate release management deeply into your workflows. These new capabilities brings important changes you'll want to know about.
Through relevant APIs, you have programmatic control over every aspect of releases:
A key part of this release is our enhanced , which makes publishing in the studio a true platform feature. This addresses many long-standing issues by providing a unified, reliable approach to content operations throughout the content lifecycle. The Actions API gives developers precise control over the entire publishing process, from draft creation to scheduling and coordination.
Think of Content Releases as adding a new dimension to your content—instead of just "published" and "draft," we now have an entire spectrum of possible future states. To support this, we've made your releases queryable using .
We've also added some powerful new GROQ functions to help you work with releases:
sanity::versionOf()
for finding specific document versions sanity::partOfRelease()
to check if a document is in a release releases::all()
to get a list of all releasesNow, here's the part that requires some attention, especially if you're working with custom implementations:
v2025-02-19
of the query API. This means your queries will only return published content by default—a safer approach that prevents accidentally exposing draft and versioned content. version
ID paths: Content Releases introduces a new versions.**
prefix for document IDs. If you've been relying on checking document paths (like drafts.**
), you'll want to update your code to use Perspectives instead. 2025-02-19
or later. This version includes all the new functionality and breaking changes.Here's a practical example of how this might affect your queries:
// Old way of querying for published docs on authenticated requests
*[_type == "post" && !(_id in path("drafts.**"))]
// New way (with Content Releases):
const client = createClient({
projectId: 'your-project-id',
dataset: 'production',
apiVersion: '2025-02-19', // Required for Content Releases
useCdn: false, // Disable for real-time preview
perspective: 'published' // Default, shows only published content
})
// Want to preview multiple releases? Here's where the magic happens! 🪄
const previewClient = createClient({
projectId: 'your-project-id',
dataset: 'production',
apiVersion: '2025-02-19',
useCdn: false,
perspective: ['rel-summer', 'rel-winter'] // Stack multiple releases!
})
// Now you can query and see exactly how content will look
// when both releases are published
const result = await previewClient.fetch(`
*[_type == "post"] {
title,
content,
"inRelease": sanity::partOfRelease("rel-summer")
}
`)
Content Releases supersedes and enhances with a more powerful, coordinated approach to content management. While Scheduled Publishing focuses on timing individual document updates, Content Releases introduces comprehensive version control and scheduling for document groups, complete with preview capabilities and API support.
We recommend transitioning to Content Releases for more robust content coordination. You can even simplify your content models by removing custom scheduling fields, as the platform now handles this natively through the Content Releases API.
Scheduled Publishing will continue to work, but you'll see a notification about running both systems simultaneously. You can turn this warning off by adding the following configuration:
// ./sanity.config.ts|js
import {defineConfig} from 'sanity'
defineConfig({
// ....
scheduledPublishing: {
enabled: true,
showReleasesBanner: false
}
)
Content Releases is enabled by default for new projects, while Scheduled Publishing requires explicit opt-in through your studio configuration.
Content Releases is now available and enabled by default on the newest Studio version. To get started, update your Sanity Studio dependencies and enable releases in your configuration. .
For a seamless experience with Content Releases, make sure your front-end is configured to use the 2025-02-19 Query API version to enable previewing capabilities. This ensures your presentation layer will correctly display content from your releases.