Manage workspace toolchains

Last published : Oct 20, 2026
A toolchain manager lets each project declare the language runtimes and tools it needs in a file in its own repository, so one base container image serves many teams. Citrix SecurSpaces™ documents two:
Neither is built into the platform. Both are ordinary tools you install in a base image, and both work because of the same platform behavior, described below.
Related information
Build and manage custom workspace images for SecurSpaces

Choose between Mise and Nix

Mise Nix
Configuration file mise.toml flake.nix
Typical first start 10–60 seconds 30–120 seconds
What persists by default Tools install under /home/developer, which persists The Nix store is at /nix, which does not persist unless you add a volume
Reproducibility Pinned tool versions Fully pinned dependency closures through flake.lock
Learning curve Low. Familiar to anyone who has used asdf or nvm. Higher. Requires learning the Nix language.
Choose Mise when you want per-project tool versions with minimal setup, and your teams are comfortable pinning versions in a simple file.
Choose Nix when you need bit-for-bit reproducible environments and are prepared to configure a persistent volume for /nix and to invest in the Nix language.

Platform behavior both rely on

Only /home/developer persists

The workspace container is recreated from its image on every start. /home/developer is a persistent volume and survives; everything else does not. See What persists in a SecurSpaces workspace.
This is what makes a toolchain manager practical: tools download once and remain on subsequent starts.

Files written during the image build are hidden

A persistent volume is empty when it is first created, and mounting it hides anything the image build wrote to that path. Installing tools into /home/developer in a Dockerfile therefore has no effect at runtime.
Install to a system path such as /usr/local, and use a first-start script for anything that must live in the home directory.

First-start scripts

Scripts in /usr/bin/strong_network_startup/ in the image run once, on first start, after /home/developer exists.
The platform records that they have run by creating /home/developer/.strong_network_init. Because that marker lives on the persistent volume, the scripts run again for any workspace with a new volume, and again if the marker is deleted.
These are distinct from the startup scripts configured in the console, which run on every start. See Startup scripts.

Certificates when a network policy is attached

When a workspace has a network policy attached, its outbound traffic is routed through the SecurSpaces egress proxy, and the proxy's certificate is appended to the system trust store at /etc/ssl/certs/ca-certificates.crt.
The platform also configures several ecosystems that keep their own trust store:
Ecosystem Configured
npm cafile
pip global.cert
yarn strict-ssl disabled
Node.js NODE_EXTRA_CA_CERTS
Python requests REQUESTS_CA_BUNDLE
Java The certificate is imported into the JDK keystore
VS Code http.proxyStrictSSL disabled
Tools that read the system trust store, including Mise and Nix, work without further configuration. A tool that ships its own CA bundle and ignores the system store needs to be pointed at the proxy certificate explicitly.
See Network policies.

Sample scenario

Both worked examples use the same project, a web application requiring:
  • Node.js 22, the application runtime
  • Python 3.13, for build scripts and tooling
  • Terraform 1.x, for infrastructure management
  • jq, for JSON processing