Queue environments follow the Open Job Description environment template specification and prepare software or licensing once per worker session. Jobs select packages through parameters such as CondaPackages, RezPackages, or PipPackages.
This table lists each user-selectable queue environment or collection directly in queue_environments/. Nested collections provide their own complete indexes.
| Sample | What it demonstrates | Start here when |
|---|---|---|
| Console Conda environment | Service-managed fleet conda-queue-env commands backed by Rattler |
You want the environment created by console onboarding |
| Inline Conda environment | Creating and deleting a Conda environment with portable bash | A customer-managed fleet has Conda but not service-provided helper commands |
| Py-rattler Conda environment | Solving and activating packages with the py-rattler library |
You want faster solving and can accept its compatibility differences |
| Cached Conda environment | Reusing hash-named environments with service-managed fleet commands | Repeated package sets should avoid relinking on every job |
| Cached inline Conda environment | Portable named-environment reuse and expiration logic | Customer-managed fleets need reusable Conda environments |
| Rez environment | Running each task in a resolved Rez context through Open Job Description wrap actions | Your studio already distributes software with Rez |
| Rez shim environment | Wrapping each task in a resolved Rez context through PATH shims |
No longer recommended. Use the Rez environment, which wraps tasks with wrap actions |
| Pip environment | Creating a Python venv and installing job-selected pip packages |
Jobs need Python packages without Conda or Rez |
| Disconnect UBL | Removing Deadline Cloud Usage Based License environment variables | A queue must use only a custom license server |
| Short path mapping junctions | Junctioning job attachment directories to short paths and republishing path mapping rules through them | A Windows application fails on long input paths despite long path support |
-
In the selected sample, change
CondaChannels,RezRepositories, or package-index defaults to your package source. Conda and Rez support shared file-system paths. Conda also supports Anaconda.org, web, and S3 channels. -
Follow Create a queue environment to add or update it. A CLI invocation looks like:
aws deadline create-queue-environment \ --farm-id FARM_ID \ --queue-id QUEUE_ID \ --priority 1 \ --template-type YAML \ --template file://conda_queue_env_improved_caching.yaml
These samples use bash that is portable to Windows. On Windows customer-managed fleets, install Git for Windows and put its Git binary on PATH.
Customer-managed fleets must provide Conda or Rez, such as in the AMI.
For Conda, also make conda activate and conda deactivate available in non-interactive bash. The samples assume /opt/conda on Linux and C:\Programs\Conda on Windows.
Amazon Linux 2023:
# Use /etc/environment in non-interactive scripts.
echo 'auth required pam_env.so' >> /etc/pam.d/su
echo 'BASH_ENV=/etc/bash_env' >> /etc/environment
echo 'source /opt/conda/etc/profile.d/conda.sh' > /etc/bash_envUbuntu:
echo 'source /opt/conda/etc/profile.d/conda.sh' >> /usr/share/modules/init/bashWindows PowerShell:
[Environment]::SetEnvironmentVariable("BASH_ENV", "/etc/bash_env", "Machine")
$Env:BASH_ENV = [Environment]::GetEnvironmentVariable("BASH_ENV", "Machine")
echo @'
echo 'source "/c/Programs/Conda/etc/profile.d/conda.sh"' > /etc/bash_env
'@ | & "C:\Programs\Git\bin\bash"Deadline Cloud submitters can add the package-selection parameters defined by a queue environment automatically. Custom bundles can get the same behavior by defining CondaPackages, RezPackages, or PipPackages with suitable defaults. The Blender render template demonstrates both Conda and Rez package parameters.
The queue environment creates and activates the selected virtual environment, so task commands should invoke applications such as blender from PATH instead of using absolute paths.
The console environment runs conda-queue-env-enter and conda-queue-env-exit, which are available on service-managed fleet workers and implemented with Rattler. Their relevant options are:
Usage: conda-queue-env-enter [OPTIONS] [ENV_DIR]
Arguments:
[ENV_DIR] The location of the environment to be created
Options:
-p, --packages <PACKAGES> Space-separated packages
-c, --channels <CHANNELS> Space-separated channels
--channel-priority <PRIORITY> "strict" or "disabled"
--persist-envs-hashed <ROOT> Reuse hash-named environments
--update-after-minutes <MINUTES> Refresh age; default 600
-v, --verbose... Increase logging verbosity
--windows-activation-shell <SHELL> "bash" or "cmd"
--print-env0 Print null-delimited environment values
-h, --help
Usage: conda-queue-env-exit [OPTIONS]
Options:
--persist-envs-hashed <ROOT> Root containing persistent environments
--cleanup-after-hours <HOURS> Stale cleanup age; default 96
-v, --verbose... Increase logging verbosity
-h, --help
Persistent reuse is not enabled in the console template by default. The cached Conda sample enables it.
The inline sample directly runs Conda and works on customer-managed fleets. It creates one environment per OpenJD session and deletes it afterward. Conda still caches downloaded and expanded packages, but each session pays the cost of linking a new environment. Unlike the console environment's strict channel priority, it uses Conda's flexible priority for multiple channels.
The py-rattler sample provides similar behavior through py-rattler. It generally solves faster, but pip is not automatically included with python, it rejects some syntax accepted by Conda (such as colmap=*=gpu*), and solver errors can include less diagnostic detail.
The service-managed cached sample stores reusable environments under ~/.persistent_envs by default. Change both enter and exit actions if you choose another path.
The cached inline sample implements the same idea with Conda environments identified by name on customer-managed fleets. Its default name hashes channels and packages, and jobs can also specify a name. Separate settings control how long an environment is reused before package refresh and when stale environments are deleted.
The Rez sample resolves software from a shared package repository. Use it with customer-managed fleets that can access that repository.
onEnter resolves the requested packages once and saves the context to the session directory. The environment then uses the WRAP_ACTIONS extension to run every task, and the enter and exit actions of environments entered after it, inside that context with rez env --input. Rez applies the whole context in the task's own process. The task gets plain environment variables and also any alias, shell function, or PATH prepend that shadows a system binary. Job templates call tools by bare name and don't need changes.
Each wrapped action takes on the timeout and cancelation of the action it wraps. The wrapped command runs as rez env --input <context> -- <command> <args>, which passes it to the shell as one command line. The shell expands $VAR and $(...) in its arguments and removes one level of backslash escaping, the same as for a command typed after rez env --. A render.$F4.exr argument becomes render..exr, and \\server\share becomes \server\share. Workers need Rez, python, and bash (Git Bash on Windows) on PATH, and read access to the package repository.
Because the context is applied again for each wrapped action, Rez's default overwrite behavior applies to environments entered after this one, including job environments. Rez overwrites a variable the first time a package modifies it and rebuilds PATH from the system paths, so without configuration a later environment's changes to PATH, or to any variable a resolved package modifies, don't reach the task. The RezParentVariables parameter, a comma-separated list that defaults to PATH, controls this. The wrap hooks pass it to Rez as parent_variables, so packages append and prepend to those variables instead. Add variables such as PYTHONPATH to keep later changes to them too, or set it empty to use the worker's Rez configuration. Packages that call setenv still overwrite. With parent variables, the context also includes software from the worker's environment, which Rez's default excludes.
The Rez shim environment is no longer recommended. It predates wrap actions and gets the same result by writing a PATH shim for each tool the resolved packages provide, with each shim re-entering the saved context. Use the Rez environment above instead. The shim environment's README covers its deployment and tradeoffs.
The pip sample uses Python's standard-library venv module to install PipPackages and activate the environment for subsequent steps. If PipPackages is empty it does nothing, allowing mixed queues. PipIndexUrl and PipExtraIndexUrls support private indexes such as AWS CodeArtifact.
Workers need python3 or python on PATH. Service-managed fleets provide one. Compare the pip package job with the self-contained pip job when deciding whether configuration belongs on the queue or in one bundle.
The disconnect environment unsets Deadline Cloud Usage Based License variables so jobs use a custom license server. Give it a higher-precedence position than other environments, such as priority 0, so later licensing setup is not removed. Review Bring Your Own License. Additional UBL variables can be introduced over time, so review the template against current service behavior before deployment.
Windows imposes a 260 character path limit, and applications that are not long-path-aware, such as Adobe After Effects and Cinema 4D, keep failing on longer paths even when long path support is enabled through the registry. Deadline Cloud downloads job attachments into a subdirectory of the session working directory whose name is a hash, which puts them roughly 107 characters deep before any project-relative path is added.
This environment creates a Windows directory junction to each job attachment directory at a short numbered path, then writes a new pathmapping-1.0 rules file whose destinations point through those junctions. The DEADLINE_JUNCTION_PATHMAPS environment variable names that file. It also writes a second pathmapping-1.0 file that maps the directories directly to their junctions.
The DEADLINE_JUNCTION_PATHMAPS file is a direct replacement for the session's own immutable path mapping rules file. For adaptors built on the Open Job Description adaptor runtime, replacing --path-mapping-rules file://{{Session.PathMappingRulesFile}} with --path-mapping-rules file:// plus the DEADLINE_JUNCTION_PATHMAPS value allows the adaptor to use the newly created junctions. For non-adaptor integrations such as the one for After Effects, the path mapping rules defined in DEADLINE_JUNCTIONS can be applied on top of the existing path mapping rules. If neither set of path mapping rules is applied, then the job falls back to the session's original long paths without utilizing the junctions that this queue environment creates.