Product documentation
Citrix SecurSpaces™
View PDF

Image caching

August 27, 2026
Contributed by: 
T

Pulling a workspace image is usually the largest single cost when a workspace starts. A workspace image is often more than a gigabyte, and a node that has never run that image has to download and unpack it before the workspace can begin.

Image caching removes that wait. Citrix SecurSpaces™ keeps the images you mark as cached present on workspace nodes, so a workspace scheduled onto one of those nodes starts without pulling anything.

What you need

Requirement Detail
Permission The Security permission set to Manage — the security officer role
Scope Platform-level container images only. Images defined at organization or project level cannot be cached.

Caching is unavailable if a platform administrator has disabled image management.

Cache an image version

Caching is set per version, not per image, so you can cache the tags developers actually use and leave older ones alone.

  1. In the console, go to Resources > Container Images.
  2. Select the arrow beside an image to expand its versions.
  3. In the Cached Image column, turn on the toggle for each version you want cached.

The change takes effect immediately and applies across every region.

To stop caching a version, turn the toggle off. The image is no longer kept on nodes, and the next workspace that needs it pulls it normally.

Note:

The platform default IDE image is cached automatically when it is ready and not past its deprecation date. You do not need to mark it. See IDE versions.

How images stay on the nodes

Understanding the mechanism explains both the benefit and the cost.

SecurSpaces runs a deployment whose only job is to hold the cached images. Each of its pods references every cached image, which makes Kubernetes pull those images onto whichever node the pod lands on. The pods are spread one per workspace node, and they do no work beyond existing — their presence is what keeps the images on the node.

Two consequences follow:

  • The node disk carries every cached image. Cache the versions in active use rather than the whole history of an image. A workable pattern is the current default tag and the one before it, so a rollback is also fast, with earlier versions left uncached.
  • The cache follows the workspace nodes. As the cluster scales, the deployment is resized so new nodes also receive the images.

Cached images and warm nodes

The same deployment provides warm nodes. Its size is the number of nodes currently running workspaces, plus a buffer derived from the warm node setting for the region.

That buffer is what makes the two features work together: without it, images are cached only on nodes that are already busy, and a workspace that triggers a scale-out still waits for the pull. Warm nodes keep spare capacity that already holds the images, so the first workspace of the day avoids both costs at once.

Configure the buffer under System Configuration > Regions. See Warm Nodes Configuration.

Note:

The buffer is held at zero until at least one workspace is running in a region, so an idle cluster is not kept warm for nobody.

Confirm caching is working

Two checks, from either side:

  • In the console, the Cached Image toggle is on for the version.
  • For a developer, the workspace startup log no longer shows a long pull for that image. Open it from More Actions (…) on the workspace, then Logs, and look at the Setting up container phase. See Troubleshooting.

If the pull still appears, the workspace was scheduled onto a node the cache has not reached yet, which usually means the cluster has just scaled out.

Image caching
August 27, 2026
Contributed by: 
T
August 27, 2026
Contributed by: 
T

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.