-
-
-
-
Manage workspace toolchains
-
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Manage workspace toolchains
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.
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
Related information
Share
Share
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.