Docker and Singularity containers: which one is better?

1.0 Introduction

Building a web application using containers is one of the new technologies that I and my Capstone team need to learn and master. I researched and self-learned to build Docker images and run docker stack services to create a microservice web application. However, there is a need for our project to build an internal web application which is run on the HPC system. As a result, Singularity containers become more preferable than Docker’s. However, the process of converting from Docker’s multi-containers to a single Singularity container seems to be challenging. In this blog, I differentiate the differences between Singularity and Docker. Hopefully, this will help new learners to gain some insights when choosing the right container technologies for their applications. 

2.0  Docker containers:

2.1 Limitations: 

To maintain the Docker engine, Docker daemon needs to be run in the background; Docker daemon needs root privileges, which could potentially be a security concern. Only trusted users should be allowed to control your Docker daemon [1]. Otherwise, without limiting access rights, containers can alter the host filesystem as Docker host and guest containers share a directory. However, some extra steps can be done to reduce these security risks. For example, enabling SELinux and not allowing users to mount directories outside Docker context. Also, binding options should only apply to trusted user-defined paths and the filesystem maintains proper user’s ownership rights [2]. 

2.2 Strengths:

Docker is suitable for DevOps engineering; Docker provides cloud-native micro-services to users [3]. With Docker swarm, multiple Docker containers can be run and connected on multiple hosts. With Docker compose, multiple Docker containers can be configured and started on the same host. Docker Hub provides a great number of pre-built Docker images, which is convenient to meet the needs of many applications. 

3.0 Singularity containers:

3.1 Limitations:

Singularity containers are not as popular as Docker containers are. For Windows users, for example, users can set up a Docker desktop but cannot install a Singularity desktop. To run Singularity locally, Windows’ users have to install many dependencies including Git Bash, Vagrant, and Virtual Box [5]. In addition, when encountering problems with container technologies, Docker containers seem to have more support from a large number of users. Singularity has smaller numbers of users; thus, new learners might find it is challenging when building applications with Singularity. 

3.2 Strengths:

Singularity containers are preferred when running applications in HPC systems. Singularity containers can be run without sudo. Unprivileged users can also use –remote or –fakeroot features to build Singularity containers. In addition, Singularity can convert Docker containers to Singularity, or can run containers directly from Docker Hub, or can pull images from Singularity Hub. 

4.0 Differences between Singularity definition file and Dockerfile:

Understanding the basic differences between the Singularity definition file and Dockerfile could help users to quickly build Singularity definitions files when it is necessary. 

Singularity definition files have header and section. Header has the keyword “Bootstrap”. Depending on bootstrap agents, other keywords need to be added. For example: “From”, “OSVersion”, “MirrorURL”, “include”, “Fingerprints”. Sections start with % followed by the names of the sections. Common sections are %setup, %files, %environment, %post, %runscripts, %startscripts, %test, %label. %help, %app*. 

In contrast to Singularity, dockerfile can only use Docker Hub to bootstrap. Also, Dockerfile does not support %setup, %startscript, % help, and  %app*. Instead of %files, %environment, %post, %runscript, %test, and %label, dockerfile uses different section names including COPY, ENV, RUN, CMD, HEALTHCHECK, and LABEl respectively [4]. 

5.0  Conclusion:

Understanding pros and cons of Docker and Singularity containers could help developers select suitable container technology for their applications. From my own experience, it is faster to build and deploy Docker containers; the main concern is the security risks that prevent usage of Docker containers on HPC systems. 


[1] Docker docs. (Docker Security.  [Online]. Available: Accessed Jan 3rd, 2022.

[2] Nishanth Dandapanthula. (2018). [Online]. Available: Accessed Jan 3rd, 2022. 

[3] RRZE. (2020). Introduction to software containers with Singularity. [Online]. Available: Accessed Jan 3rd, 2022

[4] Singularity container. Support for Docker and OCI. [Online]. Available: Accessed Jan 3rd, 2022. 

[5] Singularity docs. Installation. [Online]. Available: Accessed Jan 3rd, 2022. 

Print Friendly, PDF & Email


  1. You should consider using podman ( rather than docker. podman can run without sudo and does not require root access. podman more or less has all the advantaged you mention for Docker over Singularity, but without the disadvantages of docker.

    1. Thank you for introducing me to the Podman. I have not used Podman before, but I agree that having the option to run as root or as non-root users makes Podman appealing and safer. Reading Podman’s specification, I see that Podman uses some other third-party tools to manage containers’ services without the need of using a daemon, which is the main mechanism for Dockerd. I am surprised by how compatible Podman is as commands to run containers are similar to docker’s commands. If features like docker-compose or docker-swarm are not needed, users can use Podman to manage containers as non-root user. I would definitely try Podman, especially because I learn that Podman can create image from a Dockerfile.

      Thank you again, Castedo Ellerman, for your knowledge sharing. It would be a great help for many developers!

Leave a comment

Your email address will not be published. Required fields are marked *