Domino Standard Environments


The way we build Domino Environment Images has been fundamentally changed in 4.6 to use a templated environment building system. This allows us to provide slimmer environment images that yield faster execution startup times, avoid clashing dependencies, reduce security vulnerabilities, and make it easier to build on top of an environment image by adding your own custom Dockerfile commands.

Images prior to 4.6 were referred to as the DAD (Domino Analytics Distribution) and DMD (Domino Minimal Distribution). Starting in 4.6 these images have been replaced with the DSE (Domino Standard Environment) and DME (Domino Minimal Environment). We have also expanded the size of our Compute Environment Catalog to include new images specifically for Spark, Ray, and Domino partner integrations.

It is important to note that while Domino Environments typically ship with new versions of Domino, environment images are generally version agnostic and will work with any 4.x Domino deploy. You can still use an old DAD image if you would like a larger image that pre-installs far more packages, and the new environment images that ship with Domino 4.6 are suitable for use with any Domino deployment with version at least 4.2 .


Each run and workspace in Domino operates in its own Docker container. These Docker containers are defined by Domino compute environments. Environments can be shared and customized, and they are automatically versioned by Domino.

New installations of Domino come with a standard environment known as the Domino Standard Environment. Periodically, Domino publishes a new set of standard environments with updated libraries and packages. These environments include some common data science packages and libraries pre-configured for use in Domino.

We also make available a minimal environment (known as the Domino Minimal Environment) which includes only the necessary packages required to work with in Domino. These would be an appropriate option for a user who wants to build a Domino-compatible environment from scratch, which helps speed up environment build times and execution start times.

Domino Standard Environment (DSE)

The Domino Standard Environment is a revised and slimmed down version of the old Domino Analytics Distribution. It is designed to handle common data science workflows out of the box, and includes a handful of the most common Python and R packages.

The DSE includes far fewer packages by default than the DAD, giving it a much smaller footprint and making it much faster and easier to work with. You can find more information on how to add packages to the DSE in Managing Environments. The DSE also comes with a gpu flavor that includes CUDA support and common packages for taking advantage of gpu’s.


We recommend using an environment with explicit gpu support when using gpu hardware tiers.

You can find the available Domino Standard Environment images at

Domino Minimal Environment (DME)

The Domino Minimal Environment is a revised version of the Domino Minimal Distribution. It includes Jupyter and JupyterLab workspace support, but leaves out many of the packages that are included in the DSE. We recommend using the DME if you will be doing many custom installations on top of a base environment image, as its smaller size dramatically speeds up build times and helps you avoid conflicting dependencies. You can find more information on how to add packages to the DME in Managing Environments.

You can find the available Domino Minimal Environment images at


The next section covers Domino Compute Environments designed to be used with compute clusters. These environments can be used with any Domino execution like a Workspace or Job, but are best used in a distributed compute cluster alongside a Domino Cluster Environment.

What’s the difference between a compute and cluster environment?

Domino Compute Environments work like the Domino Standard Environment, but with additional libraries to support a specific cluster type. They contain the same workspace tools and general packages as the DSE in order to support general data science workflows.

In contrast, Domino Cluster Environments are much smaller, simpler environments that are only suitable for use in the worker nodes of a distributed compute cluster. A cluster won’t work correctly if the worker nodes are not using the appropriate Domino Cluster Environment for cluster workers and compatible Domino Compute Environment for Job or Workspace.

Domino Spark Environment

The Domino Spark Environment is an environment built specifically to be the environment for workspaces that control a Spark cluster. It includes Scala and Spark on top of the typical DSE functionality. This environment is best used alongside a Spark cluster environment. To ensure compatibility between the spark compute environment and spark cluster environment, the spark and python versions used must match across environment images.

You can find the available Domino Spark Environment images at

See here for more information on Spark Cluster Environments.

Domino Ray Environment

The Domino Ray Environment is an environment built specifically to be the environment for workspaces that control a Ray cluster. It includes Ray on top of the typical DSE functionality. This environment is best used alongside a Ray cluster environment. To ensure compatibility between the ray compute environment and ray cluster environment, the ray and python versions used must match across environment images.

You can find the available Domino Ray Environment images at

See here for more information on Ray Cluster Environments.

GPU Environment Flavors

The Domino Standard Environment also includes a GPU version with support for CUDA and common GPU specific libraries like Torch and Tensorflow. These GPU enabled environment images are much larger, so we recommend avoiding using them if you are not taking advantage of a GPU enabled hardware tier.

FUSE Environment Flavors

The DSE environment also has a version that includes FileSystem in Userspace (FUSE) binaries to enable Goofys and SSHFS support. You can add these commands to your environment Dockerfile to enable FUSE functionality:

USER root

# Goofys
ADD  /usr/bin/
RUN chmod a+x /usr/bin/goofys

RUN apt-get update && apt-get install -y sshfs && \
    sed -i "s/^#user_allow_other/user_allow_other/" /etc/fuse.conf

USER ubuntu

Example: Creating a New Domino Environment

While Domino comes with only the Domino Standard Environment installed, you can easily create a new Domino Environment using the environment images referenced above. This section explains how to go about creating a new Domino Environment for a use case or to customize for specific user needs.

  1. Select an environment from those available, choosing the python and R version you desire. Typically, you’ll always want to choose the environment from the latest release of Domino.


    Domino Environment Images follow the naming scheme <ubuntuVersion-pythonVersion-rVersion-dominoVersion-optionalDescriptor>. It is worth noting that the Domino version refers to the version of Domino where the environment was released, but environments can be used across different versions of Domino. The optionalDescriptor is typically something like gpu that describes some variation on the typical version of the environment.


    Environments tagged “_legacy” are designed to work with Domino versions <4.x The only difference between a regular and legacy environment is the way they handle CUDA given the switch to using nvidia-docker2 in Domino version 4.0.

  2. Find the appropriate name, description, image uri and pluggable notebook properties for your environment.


    Starting with the introduction of the DSE in Domino 4.6, environments include the supported pluggable notebook properties in the image metadata under the com.dominodatalab.environment.workspace-properties field. You can base64 decode this string to get the yaml properties this workspace supports.

For example, for the Domino Standard Environment we might use:

Title: Domino Standard Environment Py 3.8 R 4.1



Ubuntu 18.04
Mini-conda py38_4.9.2
Python 3.8
R 4.1
Jupyter, Jupyterlab, VSCode, Rstudio

Pluggable Workspace Tools (decoded from environment metadata)

  title: "Jupyter (Python, R, Julia)"
  iconUrl: "/assets/images/workspace-logos/Jupyter.svg"
  start: [ "/opt/domino/workspaces/jupyter/start" ]
    port: 8888
    rewrite: false
    internalPath: "/{{ownerUsername}}/{{projectName}}/{{sessionPathComponent}}/{{runId}}/{{#if pathToOpen}}tree/{{pathToOpen}}{{/if}}"
    requireSubdomain: false
  supportedFileExtensions: [ ".ipynb" ]
  title: "JupyterLab"
  iconUrl: "/assets/images/workspace-logos/jupyterlab.svg"
  start: [  /opt/domino/workspaces/jupyterlab/start ]
    internalPath: "/{{ownerUsername}}/{{projectName}}/{{sessionPathComponent}}/{{runId}}/{{#if pathToOpen}}tree/{{pathToOpen}}{{/if}}"
    port: 8888
    rewrite: false
    requireSubdomain: false
  title: "vscode"
  iconUrl: "/assets/images/workspace-logos/vscode.svg"
  start: [ "/opt/domino/workspaces/vscode/start" ]
    port: 8888
    requireSubdomain: false
  title: "RStudio"
  iconUrl: "/assets/images/workspace-logos/Rstudio.svg"
  start: [ "/opt/domino/workspaces/rstudio/start" ]
    port: 8888
    requireSubdomain: false
  1. Create a new Domino Compute environment
  • See Compute Environment Management for an overview of how to create and manage environments. This sections also includes info on how customize your new environment with additional Docker commands or pre-run scripts.

  1. Update your Domino AMI (not required for non-cloud)
  • Once you’ve created a compute environment with a new base image, you’ll want to work with your admin to update your Domino’s AMI (or if not on AWS, the GCP or Azure equivalent) by caching the new image. As Domino spins up and down new executors, if your new image is not in the AMI, it will need to pull that image onto the executor the first time it starts up. This can cause a ~10 minute delay for starting workspaces on new executors. See here for the procedure to snap and update your AMI.


  1. How can I tell which image I’m currently using?

    The URI for the image will be listed on your compute environment’s overview page. If your environment is built on top of another environment, you may need to click through to the parent environment before seeing the underlying docker image.

  2. I have a third party docker image, can I use that in Domino?

    Maybe, but not likely without some customization. The DSE and DME are tested and configured to meet the Domino platform requirements and conventions. For example, by convention Domino uses /mnt as the default working directory. It is much easier to use the DME as your base environment to build on top of than it is to try to get a 3rd party environment to work directly in Domino.

    However, this is not the case for environments for compute cluster worker nodes. In most cases, these environments can be plugged directly into Domino with no modifications, as they do not need to support the same workflows as the Domino Compute Environments.

  3. How can I learn about new versions of the DSE and make feature requests?

    Check out the Domino community forum for news and updates.

4.6 Environment Changes

As touched on earlier, there were a number of changes to Domino Environments in 4.6 as we shifted from the DAD to the DSE. These changes were the result of an improvement of our internal environment building practices, which now enable us to build environments faster and therefore support a larger catalog of unique images. In addition, our newer images are much slimmer, leading to faster build and startup times and fewer security vulnerabilities.

Here are the key changes in the 4.6 Domino Environment images:

  1. Removed hundreds of Python and R packages from the image

  2. Removed Scala and Scala Kernel

  3. Removed FUSE (Goofys and SSHFS) binaries in default image. These are still available in FUSE image

  4. Removed VSCode in JupyterLab extension in favor of distinct VSCode IDE option

  5. Python 3.8.8 -> 3.8.10

  6. miniconda py38_4.8.3 -> py38_4.9.2

  7. R 4.0.5 -> 4.1.0

  8. openjdk 1.8.0_292 -> 11.0.11

  9. nodejs v14.17.0 -> 16.4.1

  10. jupyter-notebook 6.3.0 -> 6.4.0

  11. jupyter-lab 3.0.15 -> 3.0.16

  12. rstudio 1.4.1106 -> 1.4.1717

  13. code-server 3.7.3 -> 3.10.2

  14. Purged some unused apt-get dependencies

  15. Moved workspace start scripts from /var/opt/workspaces to /opt/domino/workspaces. New images symlink old directory, so change is backwards compatible.

  16. Added Snowflake data connector

  17. Removed Kerberos libs

  18. Removed R Jupyter Kernel

  19. Added image metadata including workspace properties and language versions

These changes improved image security and reduced image size by 3.5 GB.

Domino Environments Pre-4.6

  • Domino Analytics Distribution (DAD)

    The Domino Analytics Distributions are designed to handle most of what a typical data science workflow needs out of the box. They include the most common Python and R packages. Various versions are available if you need CUDA support.

    You can review the available dockerfile and descriptions here: Domino Base Images.

    The built images are hosted on unless otherwise stated in the READMEs for the corresponding image.

  • Domino Minimal Distribution (DMD)

    While the DAD includes most of what a data scientist needs to do their work, the DMD includes only the bare necessities required to work in Domino.

    Specifically, the objective for the DMD is to provide an image which will allow one to:

    • Open Jupyter, Jupyterlab

    • Batch run Python and R jobs

    • Host a Shiny web app

    • Publish a Python and R Model API

    • Use Domino’s Git integration

    • Install Python and R packages

    You can shrink the DMD to be smaller by removing any of the workspaces you won’t be using or removing either Python or R.

    You can review the available dockerfile and descriptions here: Domino Base Images.

    The built images are hosted on unless otherwise stated in the READMEs for the corresponding image.