Use Domino’s environment variables to inject values into your runs. Environment variables are stored securely and can be used to securely store and inject credential information.
Domino automatically injects the following environment variables whenever it runs your code as part of the context of your run.
|
Note
| These variables are not available in the Model Manager |
-
DOMINO_USER_API_KEY— This variable is sunsetting; use the API Proxy for Domino API authentication instead. -
DOMINO_API_HOST— Use this to use the Domino API to access another project. -
DOMINO_PROJECT_OWNER— Username of the owner of the running project. -
DOMINO_PROJECT_NAME— Name of the running project. -
DOMINO_RUN_ID— Run ID of the current run. -
DOMINO_RUN_NUMBER— Run number of the current run. -
DOMINO_HARDWARE_TIER_ID- Hardware tier the current run is executing on (new in v1.42). -
DOMINO_STARTING_USERNAME- Username of the user who began the run (new in v1.43). -
DOMINO_WORKING_DIR- Working directory for the running project. -
AWS_SHARED_CREDENTIALS_FILE- Path to your AWS credential file to connect to additional AWS resources (for example, S3, Redshift). See AWS credential propagation. -
DOMINO_TOKEN_FILE- DOMINO_TOKEN_FILE no longer exists as an environment variable. Instead, Use a Token for Authentication. -
DOMINO_USER_NAME— Domino Username of the person running the Workspace/Job. -
DOMINO_PROJECT_ID— Project ID of the current project. -
DOMINO_IS_GIT_BASED— Boolean value indicating if the Project is Git-based. -
DOMINO_IS_WORKFLOW_JOB— Boolean value indicating if the workflow is a job. -
DOMINO_IS_LOCAL_DATA_PLANE— Boolean value indicating if Datasets are associated with a local data plane. -
DOMINO_DATASETS_DIR— Directory where Datasets are accessed. -
DOMINO_IMPORTED_DATA_DIR— Directory where imported Datasets are accessed. -
DOMINO_ARTIFACTS_DIR— Directory where Artifacts files system is accessed. -
DOMINO_IMPORTED_ARTIFACTS_DIR— Directory where imported Artifacts file systems are accessed. -
DOMINO_IMPORTED_CODE_DIR— Directory where imported code repositories are accessed. -
DOMINO_TRAINING_SET_PATH— Directory where Domino Model Monitoring training sets are accessed. -
DOMINO_USER— Value of the default Linux username in the container, i.e.ubuntu. -
DOMINO_USER_ID— Value of the default Linux user ID in the container, i.e.12674. -
DOMINO_GROUP— Value of the default Linux group name in the container, i.e.ubuntu. -
DOMINO_GROUP_ID— Value of default Linux group ID in the container, i.e.12574. -
DOMINO_NODE_IP— The compute node IP. -
DOMINO_NODE_NAME— Name of the compute node.
|
Tip
| You can use these variables to create artifacts or results, like making a report that mentions the run number. |
You can also define custom environment variables. The names of these variables must start with a letter and contain only alphanumeric characters and underscores.
Only the owners of the project or the editors of a model can modify them. They are not tied to the version history of your project or model, so they can easily be revoked.
Domino pulls environment variables from the following sources whenever it loads a run or workspace:
-
User, project, and hardware information. These are stored in Domino’s default environment variables.
-
Environment variables defined in the user profile of the user starting a run.
-
Environment variables defined in the Hardware & Environment tab of the project settings.
You can use these to programmatically determine if your code is running in Domino or not. This is useful if your code might do something different when it runs locally as opposed to when it runs on Domino.
Reserved Environment variable names
In addition to the variables above, Domino sets some environment variables used to configure runs. They should not be defined as user or project-level environment variables. Here are some examples:
-
USER -
DOMINO_*(Any variable that starts withDOMINO, e.g.,DOMINO_NODE) -
LOGNAME -
MLFLOW_TRACKING_URI
To avoid collisions with Domino environment variables, we recommend using a common prefix like GOOGLE_ for all custom environment variables. Failing to do so may lead to unexpected behavior.
Environment variable hierarchy
You can set the same variable in different places. Each level overrides the previous one in the following order:
-
Compute environment
-
Project
-
User Account
The following shows an example of how a variable’s values can be set and the expected result:
| Place set | Run#1 | Run#2 | Run#3 |
|---|---|---|---|
Compute Environment | A | A | A |
Project | - | B | B |
User Account | - | - | C |
Run Result | A | B | C |
You must be the project owner to add, modify, or delete environment variables.
Use environment variables to set up the secure configuration to inject when the project executes.
-
Go to the Settings tab on the project.
-
In the Environment variables section, add the key/value pairs to inject as environment variables.
The values are passed verbatim, so escaping is not required. The value has a 64K length limit.
Only owners or editors can create environment variables.
Use environment variables to set up your secure configuration to inject at execution.
-
Go to the Settings tab on the model to configure.
-
In the Environment section, add key/value pairs to inject as environment variables at execution.
The values are passed verbatim, so no escaping is required. The value has a 64K length limit.
When you add a variable the values are pushed to all running model versions.
Project level and user level environment variables are not used in Models and must be set separately on the model.
You can configure environment variables on a per-user basis. The system injects these variables at execution time for any run that the user starts.
User Environment variables are automatically imported into runs across all projects and can be accessed like any other Environment Variables. User-specific environment variables are not used or available in models.
-
Click your username and then select Account Settings to open the Account Settings page.
-
Go to the User environment variables section.
-
Configure variables for your user account in the same way as project environment variables.
Every language reads environment variables uniquely. In Python, it might look like this:
import os
s3 = S3Client(os.environ['S3_KEY'], os.environ['S3_SECRET'])For more details, see Python help.
In R, it might look like this:
makeS3Client(Sys.getenv("S3_KEY"), Sys.getenv("S3_SECRET"))For more details, see R help.
The following are examples to retrieve an environment variable within your code:
Sys.getenv("DOMINO_RUN_ID")