Unity ML-Agents: a C# Unity package, two Python packages, and a Dockerfile pinned to CUDA 10.2

A Unity scene becomes the environment the agent learns in

ML-Agents is Unity Technologies' toolkit for using games and simulations as environments for training intelligent agents, with deep reinforcement learning and imitation learning as the two approaches named in the project description. The repository's primary language is C#, which reflects the Unity side: the com.unity.ml-agents/ directory holds the Unity package, and com.unity.ml-agents.tests/ sits next to it. The Python side lives in ml-agents/ and ml-agents-envs/, the two packages that the repository's own Dockerfile installs.

That split decides who can use it. You need to be comfortable in the Unity editor to build the environment and comfortable in a Python environment to train against it. A team with only one of those skills will hit a wall at the other half, and nothing in the repository layout hides that boundary.

The GitHub page defers every version question to docs.unity3d.com

The repository landing page is short on purpose. For installing the toolkit and for checking which Unity and Python versions are compatible, it points to the Install the ML-Agents Toolkit page in the package documentation at docs.unity3d.com/Packages/com.unity.ml-agents@latest. That package documentation is named as the primary documentation, and it also carries the feature list, tutorials, API references and citation guidance.

The consequence is practical: you cannot judge from GitHub alone whether your Unity editor version or your Python interpreter is supported. Open the installation page for the release you plan to use before you create a Python environment, because a URL ending in @latest follows the newest package, not the tag you happened to clone. The repository also contains docs/, localized_docs/ and an mkdocs.yml, so a documentation source tree exists inside the repo as well.

Two Python packages, installed editable and in a fixed order

The clearest installation sequence inside the repository is in its Dockerfile, which installs both Python packages in editable mode, the environment package first:

RUN pip install -e /ml-agents/ml-agents-envs
RUN pip install -e /ml-agents/ml-agents

ml-agents-envs comes before ml-agents, and both use -e, so Python reads the code from the checked-out tree rather than from a copy in site-packages. If you copy this pattern outside Docker, every change you pull into the clone changes what your training run executes, which is convenient for development and risky for a training run you want to reproduce later.

Next to these two packages the repository carries ml-agents-trainer-plugin/ and ml-agents-plugin-examples/, plus a protobuf-definitions/ directory. Colab users get a colab/ folder and a separate colab_requirements.txt.

The Dockerfile is built on CUDA 10.2 and Ubuntu 18.04

The Dockerfile at the repository root starts from an old base image:

FROM nvidia/cuda:10.2-cudnn7-devel-ubuntu18.04

On top of that it installs a display and graphics toolset (xorg, xorg-dev, xvfb, mesa-utils and the libgl, libegl and libgles2 Mesa development packages), adds google-cloud-sdk from the cloud-sdk-xenial apt source, downloads a libxfont1 package built for Ubuntu 16.04 from security.ubuntu.com, upgrades pip, and pins setuptools to 41.0.0.

The limit for readers is that this file describes one specific, aged stack. Nothing in it targets a newer CUDA release, so if your machines or cloud images use a different one, you will be editing the FROM line yourself and then checking every package in the apt list against the new base. Treat the Dockerfile as a record of which system libraries the training container needed, not as a maintained deployment path.

The image builds one pushed commit, selected by a SHA argument

The container does not copy your working tree. It initialises an empty repository and fetches a single commit from GitHub:

ARG SHA
RUN git init
RUN git remote add origin https://github.com/Unity-Technologies/ml-agents.git
RUN git fetch --depth 1 origin $SHA
RUN git checkout FETCH_HEAD

The build expects a SHA build argument, and that commit has to exist on the public Unity-Technologies remote, because the fetch goes to github.com rather than to your local files. Local edits that you have not pushed will not appear in the image, and commits on your own fork will not be found unless you change the remote URL in the file. The fetch is shallow (--depth 1), so the container holds no history to switch to another revision without fetching again. This suits reproducible builds of a known upstream commit and works against anyone iterating on a fork.

develop is the default branch, and releases arrive about once a year

Cloning without a branch argument gives you develop, the default branch, not a release. The three most recent releases are release_21 (ML-Agents Release 21) on 2023-10-09, release_22 (ML-Agents Release 22) on 2024-10-05 and release_23_tag (ML-Agents Release 23) on 2025-09-02. The tag name changed for the last one, so any script that builds tag names from a release_N pattern will miss release_23_tag.

The repository is not archived and the last push was on 2026-10-30, so work on the code continues, but more than a year has passed since Release 23 was tagged. Anyone who wants a stable base should check out a release tag, or the latest_release tag that the GitHub page links to, and read the package documentation for that release instead of following develop.

The license field reads NOASSERTION, and the editor collects analytics

GitHub's license detector reports NOASSERTION for this repository, which means it could not map LICENSE.md to a standard license identifier. The project calls itself open-source, but the automated label gives you no answer about terms, so read LICENSE.md and Third Party Notices.md yourself before you ship a product that embeds the Unity package.

A second check belongs before any team-wide rollout. The GitHub page sends readers to the package documentation home page for information about privacy and in-editor analytics. If your studio has rules about telemetry from development tools, read that page before installing the package on every workstation, not after. A SURVEY.md file also sits at the top level of the repository.

Training questions go to the Unity forum, bugs to GitHub issues

Support is split by topic. Installation and setup problems, and discussions about how to set up or train agents, belong on the Unity ML-Agents discussion forum at discussions.unity.com under the ml-agents tag. Other problems and feature requests go to GitHub issues. A training question filed as an issue lands in the wrong queue.

Contributors start from CONTRIBUTING.md, which lives under com.unity.ml-agents/Documentation~/, together with the code of conduct. The repository's tooling is visible at the top level: a .pre-commit-config.yaml and a .pre-commit-search-and-replace.yaml, pytest.ini and conftest.py, test_requirements.txt and test_constraints_version.txt, a .yamato/ directory and a CODEOWNERS file. There are also DevProject/ and PerformanceProject/ alongside Project/, so the Unity side is split across several separate Unity projects in one tree.

Editorial conclusion

ML-Agents fits Unity developers who want to train agents with reinforcement or imitation learning inside their own scenes and who can run a Python environment next to the editor. It is a poor fit for anyone expecting a ready Docker setup on a current CUDA stack, since the bundled Dockerfile starts from CUDA 10.2 on Ubuntu 18.04. Before starting, check out a release tag such as release_23_tag instead of develop, read LICENSE.md, and confirm Unity and Python version compatibility on docs.unity3d.com.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Unity-Technologies/ml-agents on GitHub