The BioSimulators standard for Docker images of biosimulation software tools outlines the syntax and semantics of the entry points of Docker images of biosimulators. This standard ensures that containerized simulation tools can be consistently executed with the same input arguments (a path to a COMBINE/OMEX archive that defines models and simulations and a path to save the outputs of the simulation experiments defined in the archive) and that simulation tools produce consistent outputs (reports and plots at consistent paths in consistent formats). The standard also specifies how images of biosimulation software tools should use Docker labels to capture metadata about themselves.

Simulation tools which implement the BioSimulators Docker image standard should provide an entry point that maps to a command-line interface that implements the BioSimulators standard for command-line interfaces for biosimulation tools:

The entry point should map to a command-line interface for a biosimulator (ENTRYPOINT ["simulator-standard-interface"]).
The default arguments for the entry point should be an empty list (CMD []).

Simulation tools which implement the BioSimulators Docker image standard should use labels to provide metadata consistent with the Open Containers Initiative and BioContainers .

Specifically, images should provide the following labels:

Open Containers Initiative labels:
- org.opencontainers.image.title: Human-readable title of the image.
- org.opencontainers.image.version: Version of the software in the image.
- org.opencontainers.image.revision: Source control revision identifier of the software in the image.
- org.opencontainers.image.description: Human-readable description of the software in the image.
- org.opencontainers.image.url: URL to find more information about the image.
- org.opencontainers.image.documentation: URL to get documentation about the image.
- org.opencontainers.image.source: URL to get the Dockerfile for building the image.
- org.opencontainers.image.authors: Contact details of the people or organization responsible for the image.
- org.opencontainers.image.vendor: Name of the entity, organization or individual which distributes the image.
- org.opencontainers.image.licenses: SPDX expression which describes the license(s) under which the software in the image is distributed.
- org.opencontainers.image.created: Date and time when the image was built (RFC 3339).
BioContainers labels:
- version: Version of the image (e.g., 1.0.0)
- software: Simulation program wrapped into the image (e.g., BioNetGen).
- software.version: Version of the simulation program wrapped into the image (e.g., 2.5.0).
- about.summary: Short description of the simulation program (e.g., Package for rule-based modeling of complex biochemical systems).
- about.home: URL for the simulation program (e.g., https://bionetgen.org/).
- about.documentation: URL for documentation for the simulation program (e.g., https://bionetgen.org/).
- about.license_file: URL for the license for the simulation program (e.g., https://github.com/RuleWorld/bionetgen/blob/master/LICENSE).
- about.license: SPDX license id for the license for the simulation program (e.g., SPDX:MIT). See SPDX for a list of licenses and their ids.
- about.tags: Comma-separated list of tags which describe the simulation program (e.g., rule-based modeling,dynamical simulation,systems biology,BNGL,BioSimulators). Please include the tag BioSimulators.
- extra.identifiers.biotools: Optionally, the bio.tools identifier for the simulation program (e.g., bionetgen). Visit bio.tools to request identifiers for simulation programs.
- maintainer: Name and email of the person/team who developed the image (e.g., Jonathan Karr <karr@mssm.edu>).

To ensure that containerized simulation tools can be executed inside high-performance computing clusters where root access is typically not allowed and conversion to Singularity images is necessary, we recommend that developers also follow the best practices below for Dockerfiles. For more discusion, we recommend Syslab's best practice guide for Singularity images .

Sources of containerized simulation tools and their dependencies: To ensure that the construction of Docker images is reproducible and portable, the simulation tools inside images should be installed from internet sources rather than the local file system. One exception is licenses that are needed to install commerical software. These can be copied from a local directory such as assets/, deleted and squashed out of the final image, and injected again when the image is executed.
Installation locations of containerized simulation tools and their dependencies: Because Docker images are typically run as root, /root should be be reserved for the home directory of the user which executes the image. Similarly, /tmp should be reserved for temporary files that must be created during the execution of the image. Consequently, the simulation tools inside containers and their dependencies should be installed to different directories other than /root and /tmp.
Environment variables: All environment variables that the containerized simulation tool supports should be explicitly defined using the ENV directive.
User priviledges: Do not use the USER directive.

An an example, below is a portion of the Dockerfile for an image for tellurium .