Traditional content staging servers have had their day. At DrupalCon Chicago 2026, Tag1's Peta Hoyes and Ray Stuart (presenting for Fabian Franz) made that case and showed exactly what replaces them. Their session, Workspaces is Revolutionizing Drupal Core: Unlock True Enterprise Content Management in Drupal, covered the core architecture, live demos, and a Q&A with the room.

We have expanded and organized the questions from that session into a standalone reference on how Workspaces works for enterprise content teams.

Getting Started: What Workspaces Is and How to Turn It On

Q. What is Workspaces?

A. Workspaces is enterprise content staging built into Drupal core. It lets a privileged user preview a large set of changes exactly as a site visitor will see them, then publish the whole set at the click of a button. Instead of maintaining a separate staging site, each workspace is an isolated set of staged changes that layers on top of your live site. You stage, collaborate, and publish without touching production until you are ready.

Workspaces has been stable in Drupal core since version 10.3 (June 2024) and ships with every Drupal 11 installation. It is no longer experimental. It is core infrastructure, and it is free and open source.

Q. How do you get started?

A. Core Workspaces turns on with a single command that most Drupal teams already know:

drush en workspaces

For enterprise use, you also want Workspaces Extra (WSE), which installs the same way most contributed modules do:

composer require drupal/wse

That is a low barrier to entry for enterprise capability out of the box.

Q. What does WSE (Workspaces Extra) add on top of core?

A. If core workspaces are content branches, WSE is closer to the full deployment pipeline you already have for code. WSE adds scheduled publishing, preview links for external stakeholders, rollback of an entire published workspace, access control, menu staging, task monitoring, and the ability to move content between workspaces when needed. WSE Config stages configuration changes alongside content, and WSE Theme lets you preview an entirely different theme staged in a workspace.

Q. I already know git. How should I think about Workspaces?

A. If you understand feature branches, you already understand Workspaces. The mental model maps almost exactly:

• Your Drupal site is the repository.
• A workspace is a branch.
• Live is the main branch.
• Saving content is a commit.
• Previewing a workspace is your working copy.
• Publishing is a merge.

The workflow is the same one developers take for granted: create a branch for your campaign, make your changes, preview the complete state, get approval, then publish. Content teams simply have not had this tooling until now. As the session put it, if your dev team would not ship code without branches, why would your content team ship content without workspaces?

The Core Problem: Why Enterprise Teams Still Struggle with Content Management

Q. What do we mean by true enterprise content management?

A. For a CMS to truly meet enterprise requirements, it needs to provide tools for both creating content and managing the end-to-end governance of that content. Content governance covers everything from procedures to technology that a complex organization needs to make sure its content meets its standards for brand, legal compliance, and accessibility. There can be a lot of content stakeholders with diverse concerns. Strong content governance is what stops all of that from devolving into chaos.

Drupal has been working toward this in core for a long time: granular user roles, workflows, content moderation in Drupal 8. With Workspaces in core, Drupal has closed another major governance gap. Content staging and review in the CMS.

Q. Why is content staging and review in context more important than ever?

Modern enterprise websites are composable. Content comes from multiple systems, dynamically laid out in the CMS, with edits and updates automatically propagating across the site. The governance of large-scale changes (adding new products, migrating a department, launching a campaign) needs to happen in the context of the overall site, with all the pieces of the puzzle present. Until Workspaces, Drupal hasn't had a clean solution for that.

Q. What about the impact on the people who need to manage content?

A. External staging sites mean content managers work in two or more places. And what most content managers do not love is remembering which autogenerated subdomain from a git branch ID is the one they are supposed to be updating. Workspaces keeps everything inside a single Drupal installation.

The Reality of Modern Drupal: Complexity Behind the Scenes

Q. What happens when you need to stage more than one set of updates at a time?

A. More staging usually means more problems. With traditional staging servers, each parallel workstream typically means another environment, another subdomain, another database sync, and another deployment pipeline to track. Workspaces eliminates that. Each workspace is isolated, teams can work in parallel, and there is no artificial limit on concurrent campaigns or content initiatives. Tag1 has tested workspaces with more than a thousand entities changed in a single workspace.

Q. If changes are happening on live while I work in a workspace, can I pull those changes in?

A. Think of a workspace as a shallow copy. Only the changes you explicitly make are tracked in the workspace. If someone modifies different content directly on live, those changes are not in your workspace and will not be overridden when you publish. Your workspace only ever contains what you put there. The one edge case is the same entity being modified in both places, which Workspaces intentionally prevents (see the collaboration section below).

Governance and Control: Who Sees What, and When?

Q. How do you deal with permissions for users who should not see work happening in workspaces?

A. Each workspace is isolated with granular permissions. Design, content, legal, and translation teams can work in parallel workspaces without visibility into each other's work unless it is deliberately shared.

Q. Can previews be shared with external reviewers, including anonymous users, and how does that work with permissions?

A. Yes. WSE preview links handle this. Create a dedicated role with preview access, assign it to the reviewer, and share the link. The reviewer does not need a full Drupal account, so this works for anonymous users too. The workflow is straightforward: prepare the role, generate the preview link, share it.

Infrastructure and Performance: Will This Break What Already Works?

Q. If I have a CDN or Varnish cache, will Workspaces need anything extra?

A. No. There are no changes to your anonymous content delivery. The active workspace is live 100 percent of the time for anonymous users, so the workspace system is invisible to them. The same caching setup that works for your anonymous visitors keeps working. The only thing to confirm is that your configuration is appropriate for the content editors using the site, which is standard practice.

Q. How about performance?

A. This is the most important architectural property of Workspaces. When the active workspace is live, which it is 100 percent of the time for anonymous users, the workspace system is invisible, and your production site performs exactly as if Workspaces did not exist. That has been true since the architecture was first built in the Content Preview System (CPS) in 2014, and it is why Workspaces has run on some of the highest-traffic sites in the world for over a decade. Inside a workspace there is some overhead, but that is editorial traffic, a tiny fraction of your total load. Editors get a full-site preview, and visitors get full production speed.

Content Safety and Security

Q. If public files are uploaded inside a workspace, are they accessible to users who know the URL?

A. Yes. File entities in Drupal aren't revisionable, so the Workspaces module can't scope a file to a workspace the way it scopes nodes. The moment a file is uploaded to public://, it's written to the default live storage in sites/default/files and served directly by the web server, with no Drupal access check in the request path.

So even when the node or media entity that references the file lives only in an unpublished workspace, the file itself is already on disk and reachable at its direct URL by anyone who has or guesses it. Publishing state doesn't gate it. Public means public, and only the obscurity of the filename keeps it from being found.

If the file needs to stay private until publish, use a private:// file field, which routes downloads through Drupal so access checks apply, or a module like File Unpublish, which keeps public files of unpublished media entities inaccessible until the entity is published.

Configuration Management: The Gray Area Teams Care About

Q. How does WSE Config interact with Drupal's configuration export/import system?

A. Once a workspace is published, whatever is live is what you would export, the same as always. For sites that manage configuration directly on the site rather than exporting it to code, this is largely a non-issue. For sites with strict configuration management workflows, WSE Config is still maturing (the session described it as almost production ready), so test it in a non-production environment before you rely on it in production.

Collaboration and Conflict Management

Q. What happens when two people edit the same content in different workspaces?

A. They cannot, and that is deliberate. Once an entity is modified in a workspace, it is tracked there, and another editor cannot modify it in a different workspace. This is a feature, not a limitation. Automatic merging of structured content fields, entity references, and media relationships leads to data corruption, and every system that has attempted it has run into fundamental issues.

Workspaces takes the same approach as a well-run development team: coordinate through communication. Shared workspaces let teams collaborate, content ownership keeps responsibilities clear, and WSE lets you move content between workspaces when needed. If content is locked, discarding the change frees it again. The absence of automatic merging is a safety guarantee: your workspace will never contain content you did not put there.

Q. How does Workspaces handle deleted content?

A. Deleting content in a workspace is a special case, because the content needs to disappear from your workspace preview while staying visible on the live site until you publish. Workspaces solves this with the Trash module. Within the workspace, deleted content drops out of listings, views, and search results, but on the live site it remains visible until publish. Content deleted in a workspace stays recoverable until you publish, and this integration also removes an older constraint so that any entity type can participate in workspaces, not just those with a publication status.

Content Moderation and Workflows

Q. How does Workspaces work with content moderation and Drupal's workflows?

A. Workspaces integrates with Drupal's core Workflows module. You can move an entire workspace through workflow states such as draft, review, approved, and published, so the whole collection of changes moves through the approval process as a unit. Your legal team reviews the complete workspace, your content manager approves the entire set, and when it reaches the publish state the whole workspace deploys atomically. The Content Moderation and Workspaces integration is nearly complete, with one remaining issue to resolve in core, and the simplified content workflow initiative will make the two work together for more complex scenarios where different entities need different approval paths.

Ecosystem and Future Considerations

Q. Does it work with Canvas?

A. Yes. Workspaces is compatible with Canvas. The implementation differs, because Workspaces aligns with the Layout Builder approach rather than Canvas's own, but the two work together.

Q. Why is Workspaces a good fit for AI content generation?

A. Workspaces gives AI content generation the boundary it needs. AI content tools are scaling quickly, and Drupal's AI module integrates dozens of providers with automators that can bulk-populate fields, generate summaries, and translate content. But AI is non-deterministic: it can hallucinate and produce errors. Workspaces provides the natural safety architecture. Think of a workspace like a pure function: everything inside is safe and reversible with no side effects. An AI agent can generate content, edit fields, and populate entire sections inside a workspace, and nothing touches live until a human reviews the changes and publishes. The workspace diff makes that review straightforward. The result is governed automation, where AI helps and humans stay in control.

Q. What is on the roadmap?

A. The architecture is sound, and the remaining work is about closing the last gaps and proving the system in the wild. Content Moderation and Workspaces are nearly integrated, with one issue left in core. WSE Config, which stages configuration changes alongside content, is almost production ready. WSE Theme lets you preview an entirely different theme staged in a workspace. What the system needs most now is real-world testing: try it with your contrib modules, test it with your custom entity types, and report bugs when you find them. Every production deployment proves the architecture.

Workspaces is stable, it is in core, and it is the right architecture for content governance at scale, including AI content generation.