No More 'DO NOT PUBLISH': Introducing Content Releases

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:

• Marketing wants to prepare their changes now but can't publish until launch day
• Content editors are afraid to touch anything for fear of disrupting the launch content
• Developers need to test their features with the new content but can't risk it going live
• You're drowning in spreadsheets trying to track what changes when everyone's planning another late-night deployment session

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?).

Introducing Content Releases

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:

• Group multiple content changes into coordinated releases.
• Preview and toggle stacked and individual releases to see the final result (it's like looking into the multiverse).
• Schedule precise publishing times, or just as "ASAP" or "undecided."
• Automate and integrate release logic through APIs
• Validate content and references automatically
• Roll back changes instantly if needed (requires Enterprise plan)

Content Releases as your publishing platform

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 the sales team through our form if you need more than two.

Go to our documentation to learn more about configuration, the user interface, and API.

Key Features

Content Releases comes with a range of useful features to ensure confident publishing and coordination:

• Group changes: Bundle multiple document updates into a single coordinated named release.
• Preview with confidence: See exactly how your content will look before publishing using Visual Editing in Presentation.
• Schedule precisely: Set specific dates and times for automated publishing.
• Validate everything: Ensure content and references are valid before going live.
• Track history: Keep a clear record of all content releases.
• Automate: API access enables workflow automation and custom integrations.

Who benefits? Everyone on your team

Let's look at how different teams benefit from Content Releases:

For developers:

• No more custom middleware for content scheduling
• Simplified version control that works like code deployments
• Focus on building features instead of content workflow plumbing
• API access for automation and custom integrations

For content editors:

• Prepare and preview changes ahead of time
• Schedule releases without late-night publishing sessions
• Maintain multiple content versions without conflicts
• See exactly how updates will look before going live

For product owners:

• Clear visibility into planned content changes
• Confident coordination of marketing campaigns
• Easy demonstration of upcoming changes
• Reduced risk with rollback capability

How Content Releases works

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.

Release management for Sanity Studio

Here's how it works:

1. Create a release: Give it a name and optionally set a target date.
2. Add documents: Select which documents will be part of the release.
3. Make changes: Edit the documents within the release context.
4. Preview and validate: See exactly how everything will look when published.
5. Schedule or publish: Either publish immediately or set a future date.

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:

• Work on holiday content while summer campaign changes are still pending
• Preview how content will look at any point in the future
• Maintain regular updates while preparing major launches
• Keep different teams working independently without conflicts

The system automatically handles the complexity of managing these overlapping changes, ensuring that everything appears exactly as intended when published.

Comprehensive API support

We've built Content Releases to be powerful yet flexible, with comprehensive API support that lets you integrate release management deeply into your workflows. However, this new capability brings important changes you'll want to know about.

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 Content Lake's Perspectives.

In addition, through relevant APIs, you have programmatic control over every aspect of releases:

• Create and manage releases through the Actions API.
• Preview content from multiple stacked releases using Perspectives.
• Query for specific versions of documents with GROQ.
• Listen to or trigger webhooks for changes to release states.

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 releases

Breaking changes to be aware of

Now, here's the part that requires some attention, especially if you're working with custom implementations:

• "Published" is the new default Perspective: We've changed the default perspective to published instead of raw on 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.
• New 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.
• API Version requirements: To work with Content Releases, you'll need to use the Query API version 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")
  }
`)

What about Scheduled Publishing?

Content Releases supersedes and enhances the Scheduled Publishing feature 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.

Getting Started

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. Check out our detailed documentation for instructions.