Skip to main content
Minimus images are designed to easily replace open source images without encountering compatibility issues as much as possible. As a rule, Minimus images will match the security context and default entrypoint unless there are security considerations to address.

​
Default user

Minimus aligns the security context so that container runs by default with a UID that allows file permissions, volumes, and security policies to work together. There are several scenarios:
  • Non-root images:
    • If the public image runs as non-root, the Minimus image will match the user for compatibility reasons. For example, Velero runs as user 1002, ClickHouse-Operator runs as user 65534, Argo CD runs as user 999.
    • If the public image runs as root but can also run as non-root, Minimus will set the default user to 65532 or 1000. For example:
  • Root requirement:
    • If the image must run as root to support required functions, the Minimus image will default to root as expected. For example, Go, Perl, aws-for-fluent-bit run as root.
  • Helm chart requirement:
    • If the image is designed to run with a Bitnami Helm chart, the image will run as user 1001 by default. Minimus Advanced images are designed to be deployed with Bitnami charts and therefore usually run as user 1001. Learn more Below is the typical securityContext for Bitnami compatibility: 
      securityContext:
  runAsUser: 1001
  runAsGroup: 1001
  fsGroup: 1001
The Minimus default user policy recently changed. Therefore, some Minimus images may have a default user that does not align with the above stated policy. Please contact support for any questions or requests.

​
Look up the default user

The specification tab in the image version card always lists the default user set by Minimus. If the default user changed between versions, the changelog will show a configuration change (example in the Minimus console).

​
Entrypoint and default CMD

Minimus images try to match the entrypoint of the public image whenever possible. However, this is not always possible. For example, if the public image uses an entrypoint script but the Minimus image does not include a shell, the entrypoint and default CMD will be different. For example, the Minimus images for OpenJDK, OpenJRE and Fluentd use an EXEC-form entrypoint instead of an entrypoint script. Learn more

​
Look up the entrypoint and default command

The specification tab in the image version card always lists the default entrypoint and default command set by Minimus. If the entrypoint or default command change between versions, the changelog will show a configuration change.

​
Default working directory

Minimus aims to match the default working directory of the public image, unless there is a reason to diverge. Since Minimus images run as non-root in most cases, the working directory is often different from the public image to ensure it is writable by the default container user. Another reason why the working directory might differ is that Minimus images are optimized for mutli-stage build workflows. Unlike many public images which include enough tooling to support building and running the application in the same image, Minimus images embrace the distroless approach. Consequently, many Minimus images are optimized for the build stage by setting the working directory to home/build. The Minimus images for OpenJDK and OpenJRE are good examples.

​
Look up the default working directory

The specification tab in the image version card always lists the default working directory set by Minimus. If the working directory changes between versions, the changelog will show a configuration change.

​
Default volumes

Minimus images often run as non-root, and are configured to permit write access to the UID (or GID) the container process runs as. To avoid filesystem permission mismatches, writable volumes may be placed on a different path than the public image.

​
Look up the default volumes

The specification tab in the image version card always lists the default volumes mounted by Minimus. If the volume mounts change between versions, the changelog will show a configuration change.