Citrix Secure Developer Spaces™

Sharing Data Between Users

Secure Developer Spaces provides two mechanisms for making external data available inside workspaces: Data Buckets and Mount Points. Both allow teams to share datasets, files, and artifacts across workspaces within a project, but they differ in how data is stored, synchronized, and accessed.

This guide explains how each option works and when to use it.

At a glance

  Data Buckets Mount Points
How data reaches the workspace Snapshot copied to the cluster Live connection to external storage
Real-time collaboration No — changes require a manual publish cycle Yes — changes are immediately visible to all connected workspaces
Data duplication Yes — each snapshot is replicated onto the cluster No — data stays in the external storage
Versioning Built-in — a new version is created each time data is published from a workspace Not built-in — use external storage versioning if needed
Supported storage providers Amazon S3, Azure Blob Storage, Google Cloud Storage Azure File Storage
Setup required Import a bucket (Project Owner) Platform Admin enables the feature; Project Owner creates Mount Points
Best for Reproducible experiments, versioned datasets, point-in-time references Large shared datasets, real-time collaboration, terabyte-scale data

Data Buckets

A Data Bucket connects an external S3-compatible storage location to the platform. When a Data Bucket is attached to a workspace, the platform creates a point-in-time snapshot of the bucket contents and replicates it to the cluster. The snapshot is mounted as a folder in the workspace file system.

How it works

  1. A Project Owner imports a Data Bucket by providing a name, bucket URL, and storage provider.
  2. A developer attaches the Data Bucket to a workspace during workspace creation.
  3. The platform replicates the bucket contents to the cluster and mounts the snapshot as a folder.
  4. If the developer modifies data in a read-write bucket and publishes the changes, the platform creates a new version of the snapshot.

When to use Data Buckets

  • Reproducibility matters. Each snapshot is versioned so that you can return to a known state of the data at any time.
  • Datasets are small to moderately sized. Snapshots duplicate data onto the cluster, so replication time and disk usage scale with dataset size.
  • Isolation is preferred. Each workspace gets its own copy of the data. Changes in one workspace do not affect others until explicitly published.

Limitations

  • Replication can take a long time for large datasets.
  • Snapshots consume cluster disk space proportional to the data size.
  • Changes are not shared in real time — other users see updates only after a new version is published.

Mount Points

A Mount Point connects external file-based storage directly to the workspace file system without copying data to the cluster. The workspace reads from and writes to the external storage in real time.

How it works

  1. A Platform Admin enables Mount Point storage types under System Configuration > Integrations.
  2. A Project Owner creates a Mount Point by specifying the storage provider, connection details, default mount path, and access permissions.
  3. A developer attaches the Mount Point during workspace creation. The mount path can be customized, and a source sub-path can be specified to mount a specific subdirectory.
  4. The external storage is mounted at the specified path (for example, /mnt/shared-data). All workspaces connected to the same Mount Point see the same files in real time.

When to use Mount Points

  • Real-time collaboration. Multiple developers need to read or write shared files simultaneously, and changes must be visible immediately.
  • Large datasets. Data is too large to replicate efficiently — terabytes of ML training data, model artifacts, or shared experiment results.
  • Avoiding data duplication. You want to reduce cluster disk usage by keeping data in the external storage rather than copying it onto the cluster.

Limitations

  • Requires a Platform Admin to enable the feature before Project Owners can create Mount Points.
  • No built-in versioning — if you need point-in-time snapshots, manage them in the external storage provider.
  • Available for Azure file-based and blob-based storage only in this release.
  • Not supported in multi-region configurations.

Choosing between the two

Use the following questions to guide your decision:

  1. Do multiple developers need to see each other’s changes in real time? Yes → Mount Points. Data Buckets require a manual publish cycle to share updates.

  2. Do you need built-in versioning to reproduce past states of the data? Yes → Data Buckets. Each publish creates a versioned snapshot. Mount Points do not automatically version data.

  3. Is the dataset very large (hundreds of GB or more)? Yes → Mount Points. They avoid the time and disk cost of replicating data to the cluster.

  4. Do you need each developer to work on an isolated copy of the data? Yes → Data Buckets. Each workspace has its own snapshot, independent of other workspaces.

  5. Are you using Amazon S3 or Google Cloud Storage? Data Buckets support these providers today. Mount Points currently support only Azure storage.

Both options can be used within the same project. For example, a team might use a Mount Point for a shared training-data directory and a Data Bucket for versioned experiment results.

Sharing Data Between Users