Public | Automated Build

Last pushed: 11 days ago
Short Description
`kaixhin/cuda-torch` dependencies.
Full Description


Compilation of Dockerfiles with automated builds enabled on the Docker Hub. Not suitable for production environments. These images are under continuous development, so breaking changes may be introduced.

Nearly all images are based on Ubuntu Core 14.04 LTS, built with minimising size/layers and best practices in mind. Dependencies are indicated left to right e.g. cuda-vnc is VNC built on top of CUDA. Explicit dependencies are excluded.

Up-to-date builds

Some builds based on certain software have builds that are triggered on schedule via a cron script to stay up to date on a weekly basis. These are:

Graphical applications

Starting graphical (X11) applications is possible with the following commands:

docker run -it `# Running interactively, but can be replaced with -d for daemons` \
  -e DISPLAY `# Pass $DISPLAY` \
  -v=/tmp/.X11-unix:/tmp/.X11-unix `# Pass X11 socket` \
  --ipc=host `# Allows MIT-SHM` \

General information on running desktop applications with Docker can be found in this blog post. You probably will also need to configure the X server host (xhost) to give access. For hardware acceleration on Linux, it is possible to use nvidia-docker (with an image built for NVIDIA Docker), although OpenGL is not fully supported.

On Mac OS X, use XQuartz and allow connections from network clients. Then the following can be used:

docker run -it \
  -e DISPLAY=`ifconfig en0 | grep inet | awk '$1=="inet" {print $2}'`:0 `# Use XQuartz network $DISPLAY` \
  --ipc=host \

Daemonising containers

Most containers run as a foreground process. To daemonise (in Docker terminology, detach) such a container it is possible to use:

docker run -d <image> sh -c "while true; do sleep 1; done"

It is now possible to access the daemonised container, for example using bash:

docker exec -it <id> bash

Sibling containers

To start containers on the host from within a docker container, the container requires docker-engine installed, with the same API version as the Docker daemon on the host. The Docker socket also needs to be mounted inside the container:

-v /var/run/docker.sock:/var/run/docker.sock


Many images rely on CUDA. These images are versioned with the corresponding tags, e.g. "8.0", "7.5", "7.0" and "6.5", on the Docker Hub.

These images need to be run on an Ubuntu host OS with NVIDIA Docker installed. The driver requirements can be found on the NVIDIA Docker wiki.

Deprecated images

kaixhin/cuda and kaixhin/cudnn have now been deprecated in favour of the official solution (nvidia/cuda).


In the future it will hopefully be possible to checkpoint and restore Docker containers easily using CRIU. This would alleviate some issues, such as the inability to restart a VNC image successfully.

Automated Builds

Automated Builds on the Docker Hub have several advantages, including reproducibility and security. However the build cluster has the following limits for Automated Builds:

  • 2 hours
  • 1 CPU
  • 2 GB RAM
  • 512 MB swap
  • 30 GB disk space

The main tip for keeping within the CPU and memory limits is to reduce parallelism/forking processes. Due to their logging system, redirecting stdout/stderr to /dev/null can potentially save a reasonable amount of memory.


Some Dockerfiles have been modified from the work of others. The source for these are:


If you find this useful in research please consider citing this work.

Docker Pull Command
Source Repository

Comments (0)