Spaces

A space is a logically separated and distinct space within an organization. Spaces cannot access content from other spaces, but you can link spaces to automatically sync data between them.

To get started, create one Drupal space to connect your Drupal site(s) to. Then create a second Content Cloud space that provides your content APIs. Link the Drupal space as a source to the Content Cloud space to automatically transfer the data model and content to your Content Cloud.

To learn more about how data models and entries are optimized and transferred between spaces, please check out the Transformations docs.

You can connect any number of Drupal sites to the service to aggregate content from multiple sites and provide it through a single content API.

This aggregation also works across multiple country sites that have different translations of the same content that will be merged to the same content automatically.

If you would like to learn more about content sharing and aggregation using Content Sync, please reach out to our support team.

Environments

Environments are separate areas in a space, but content is generally shared between them. You can publish content types and content per environment, and unless you explicitly publish content to a separate environment, it won’t be available there.

Environments can serve different purposes but are most commonly used to distinguish between different milestones of content and/or development iterations. For example:

You can create a new content staging environment and iterate on content until it’s approved and then deploy it to the main / production environment.
You can create a new development environment to work with an updated data model until you’re satisfied with the results and then deploy it to the main / production environment.

If you create the exact same entry in two environments, it will use the same data in the background, though, to optimize storage and simplify content deployments.

Environment Aliases

You can use aliases to quickly publish a different version of your content model and content entries. This makes publishing content milestones faster but also makes it easy to revert to an older version if anything goes wrong. For example:

“prod” is an alias that currently points to your “2025-spring” environment.
You have prepared the new iteration of your content in a separate “2025-summer” environment.
To publish the summer content, you point “prod” to the “2025-summer” environment.
You forgot to communicate an important content model change to one of your vendors, so a critical integration breaks.
You quickly revert the “prod” environment back to the spring content until the issue is fixed and compatibility is restored.

Note: this is an unlikely scenario to happen if you’re using our default settings that ensure automated backward compatibility.

Aliases are not enabled by default. If you are interested in this feature, please reach out to our support team.

Scopes

Data is either managed globally, per space, or per environment.

Global data

Organizations and teams are managed globally.

Organization-scoped data

Spaces are managed per organization.

Space-scoped data

Data that’s managed per space and not per environment:

This data is identical and consistent regardless of which environment is used to query it. E.g., when updating user data in one environment, it can also be queried in another environment as long as it’s related to the same content and the same user.

Environment-scoped data

Data that’s managed per environment:

All of these entries are published and revisioned per environment, but IDs are identical across environments. When you create a content in one environment and assign it a UUID (e.g., content originating in Drupal always has a UUID), it’s assigned a static entry ID. When a second environment of the same space creates a content with the same UUID, these entries are assigned the same entry ID. This makes it easy to build applications that expect to receive the same, consistent data across different environments.