Deepo: A Dockerfile Generator for Deep Learning Stacks

The dependency matrix is the problem Deepo targets

Getting TensorFlow, PyTorch and Keras to coexist in one Python environment is mostly a version-arithmetic exercise. Each framework constrains the CUDA toolkit, cuDNN, Python and sometimes each other. The Deepo README describes the project as an open framework for assembling Docker images for deep learning research, and the core of it is a generator that knows which combinations of CUDA, cuDNN, Python, PyTorch and TensorFlow are compatible, picks versions on your behalf, and determines installation order by topological sorting. That last detail is the honest description of the work involved: the generator is not doing anything exotic, it is encoding a dependency graph and emitting a Dockerfile in a valid order. The audience is researchers and engineers who want a container that runs several frameworks at once, and who would rather name the frameworks than resolve the matrix themselves. The README also positions a set of pre-built images for people who do not want to generate anything at all.

What the generator actually emits

The generator lives in the generator directory of the repository and is invoked as python generate.py Dockerfile pytorch keras. The first argument is the output filename, and the remaining positional arguments are the components you want. Version selection is exposed through flags rather than a config file: --cuda-ver 11.3.1 and --cudnn-ver 8 appear in the README example, and a Python version can be pinned by passing python==3.8 as though it were another component. According to the README, the generator follows best practices for the Dockerfiles it produces and handles configuration for you. Treat the generated Dockerfile as the artifact under review. It is plain text, it is committed alongside your project, and it is what docker build consumes. The compatibility knowledge lives inside the generator, so the generated file is a snapshot of that knowledge at the commit you cloned. Nothing in the supplied material describes how the compatibility table is maintained or how quickly new CUDA releases are added, which is the main thing to check before relying on it for a long-lived project.

Pulling a pre-built image versus building your own

There are two entry paths and they have different costs. The pre-built path is two commands: install Docker and the NVIDIA Container Toolkit, then docker pull ufoym/deepo for the all-in-one GPU image or docker pull ufoym/deepo:cpu for the CPU variant. Framework-specific tags exist as well, so docker pull ufoym/deepo:tensorflow gets you TensorFlow alone. The README states that the images run on Linux in CPU and GPU mode, on Windows in CPU mode, and on macOS in CPU mode. The build path is git clone, cd deepo/generator, then generate and docker build -t my/deepo . The README warns that this build may take several minutes, and the truncation of the text cuts off mid-sentence there, so the full build-time guidance is not visible in the supplied material. The trade-off is straightforward: pulling gives you someone else's build with an unknown set of transitive packages, while generating gives you a file you can read and edit before the build starts.

Runtime flags that matter more than the image tag

Two flags in the README's run commands are easy to skip and expensive to skip. The first is --gpus all, which is how the GPU image gets device access, and the README suggests verifying it with docker run --gpus all --rm ufoym/deepo nvidia-smi before doing anything else. If that command fails, the README points at the NVIDIA Container Toolkit issue tracker rather than at Deepo itself, which is the correct place to look. The second is shared memory. The README notes that some frameworks, PyTorch among them, use shared memory for inter-process communication, and that the container default may be too small for multiprocessing workloads. The fix is --ipc=host or an explicit --shm-size. For Jupyter, the documented invocation maps port 8888, mounts a host directory over /root, and passes --ipc=host along with a set of Jupyter Lab flags including --allow-root and a wildcard allow_origin. That combination is permissive by design and worth reading before exposing the port beyond localhost.

Where the all-in-one image works against you

An image containing every supported framework is large, and the README does not publish a size figure. Size is not the only cost. The all-in-one image fixes the version of every framework at build time, so upgrading one library means either waiting for a new tag or rebuilding from the generator with a new component list. There is also a mismatch between the generator's flexibility and the tag list: the README documents tags for single frameworks and an all-in-one tag, but the composition space is combinatorial, so an arbitrary pair like pytorch plus keras is reachable through generation rather than through a published tag. Reproducibility is the subtler issue. Because the generator resolves versions for you at generation time, two people running the same command months apart may get different Dockerfiles unless they share the generated file or pin the repository commit. The README does not describe a lockfile mechanism. If your requirement is bit-identical rebuilds over a long horizon, generate once, commit the Dockerfile, and treat the generator as a bootstrap tool rather than a build step.

How this differs from writing your own Dockerfile

The obvious alternative is a hand-written Dockerfile, or a base image from a framework vendor plus your own layers. The difference is where the compatibility knowledge sits. A hand-written file puts it in your repository, where you maintain it and where it is visible to anyone reading the build. Deepo puts it in the generator, so you inherit whatever the project has encoded and you get topological sorting for free. The cost of that inheritance is opacity: when a build fails because two components disagree, you are debugging the generator's output rather than a file you wrote. A vendor base image takes a third position, offering a single framework with versions the vendor controls, at the price of composing multiple frameworks yourself. None of these is strictly better. Deepo's value is concentrated in the multi-framework case, where the alternative is a long afternoon of version archaeology.

Licence and the cost of staying current

Deepo is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is a permissive arrangement, but it covers the generator and the Dockerfiles it produces, not the frameworks installed inside them. TensorFlow, PyTorch, CUDA and cuDNN each carry their own terms, and the NVIDIA components in particular have redistribution conditions that differ from MIT. Check those separately; this is not legal advice. On maintenance, the repository shows releases v1.0.0 and v2.0.0 both dated 2017-11-27, with the last push in March 2026. The gap between the release dates and the last push suggests active commits without tagged releases, but the supplied material does not show what those commits contain or whether the compatibility table has kept pace. That is the single fact worth verifying against the repository before you depend on it: whether the CUDA and cuDNN versions you need are represented in the generator's table, and when that entry was last touched.

Editorial conclusion

Adopt Deepo if you want a working multi-framework container quickly or need to pin a CUDA, cuDNN and Python combination without reading each framework's install matrix. Do not adopt it if you need a minimal image, a fully pinned lockfile, or a stack that is not in its tag list. Before committing, run python generate.py Dockerfile pytorch keras --cuda-ver 11.3.1 --cudnn-ver 8 from the generator directory and read the produced Dockerfile line by line, because that file is the actual environment you will ship.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ufoym/deepo on GitHub