Runtime images
Your teams’ workloads — jobs and workspaces — run inside runtime images published separately from the platform. They do not follow the product’s version number: a security fix on an image must not wait for a graal release.
The base images
Section titled “The base images”| Image | Base | Used for |
|---|---|---|
toolbox |
Alpine | bash jobs and init containers (copies, waits, preparation) |
python |
Python 3.11 slim | python and lowcode jobs |
spark-py |
Apache Spark 3.5 | spark jobs |
jupyter |
scipy-notebook | Jupyter workspace |
code-server |
code-server | VS Code workspace |
Shared properties, verified at build time:
- unprivileged identity by default (uid 10001), without having to force the user at launch;
- base pinned by digest, not by a moving tag: two builds of the same definition produce the same image;
- tested under simulated restricted constraints (all Linux capabilities dropped, no new privileges), that is, under real execution conditions.
Where they are pulled from
Section titled “Where they are pulled from”Runtime images are public: they contain no customer code, no configuration and no secret — only public packages. This allows anonymous pulls, without distributing registry credentials to the nodes that execute workloads.
The rule that follows is strict: nothing confidential, and never a customer image, in that repository.
Designating another image
Section titled “Designating another image”Each runtime type resolves its image through a configuration table. You can point it at your own image — for example a Python image hardened by your security team, or derived from ours with your internal libraries.
The specialised types (docker, dbt, dask, flink, ray) are served the same way: one
image per type, designated in that table. A runtime with no configured image answers
501 feature_disabled rather than attempting a launch bound to fail.