Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / Container Guide / SLE Base Container Images
Applies to Container Guide

4 SLE Base Container Images

4.1 Introduction to SLE Base Container Images

SLE Base Container Images (SLE BCI) are minimal SLES 15-based images that you can use to develop, deploy, and share applications. There are two types of SLE BCIs:

  • General-purpose SLE BCIs can be used for building custom container images and for deploying applications.

  • Language stack SLE BCIs provide minimal environments for developing and deploying applications in specific programming languages.

SLE Base Container Images are available from https://registry.suse.com. It contains tested and updated SLE base container images. All images in the SUSE Registry undergo a maintenance process. The images are built to contain the latest available updates and fixes. The SUSE Registry’s Web user interface lists a subset of the available images. For information about the SUSE Registry, see Section 3.1, “SUSE Registry”.

SLE base images in the SUSE Registry receive security updates and are covered by the SUSE support plans. For more information about these support plans, see Chapter 15, Compatibility and support conditions.

4.2 Why SLE Base Container Images

SLE BCIs offer a platform for creating SLES-based custom container images and containerized applications that can be distributed freely. SLE BCIs feature the same predictable enterprise lifecycle as SLES. The SLE_BCI 15 SP3 and SP4 repository (which is a subset of the SLE repository) gives SLE BCIs access to 4000 packages available for the AMD64/Intel 64, AArch64, PowerPC, and IBM Z architectures. The packages in the repository have undergone quality assurance and security audits by SUSE. The container images are FIPS-compliant when running on a host in FIPS mode. In addition to that, SUSE can provide official support for SLE BCIs through SUSE subscription plans.


Each package in the SLE_BCI repository undergoes security audits, and SLE BCIs benefit from the same mechanism of dealing with CVEs as SUSE Linux Enterprise Server. All discovered and fixed vulnerabilities are announced via e-mail, the dedicated CVE pages, and as OVAL and CVRF data. To ensure a secure supply chain, all container images are signed with Notary v1, Podman’s GPG signatures, and Sigstore Cosign.


Since SLE BCIs are based on SLES, they feature the same level of stability and quality assurance. Similar to SLES, SLE BCIs receive maintenance updates that provide bug fixes, improvements, and security patches.

Tooling and integration

SLE BCIs are designed to provide drop-in replacements for popular container images available on hub.docker.com. You can use the general-purpose SLE BCIs and the tools they put at your disposal to create custom container images, while the language stack SLE BCIs provide a foundation and the required tooling for building containerized applications.


SLE Base Container Images are covered by a permissive EULA that allows you to redistribute custom container images based on a SLE Base Container Image.

4.2.1 Highlights

  • SLE BCIs are fully compatible with SLES, but they do not require a subscription to run and distribute them.

  • SLE BCIs automatically run in FIPS-compatible mode when the host operating system is running in FIPS mode.

  • Each SLE BCI includes the RPM database, which makes it possible to audit the contents of the container image. You can use the RPM database to determine the specific version of the RPM package any given file belongs to. This allows you to ensure that a container image is not susceptible to known and already fixed vulnerabilities.

  • All SLE BCIs (except for those without Zypper) come with the container-suseconnect service. This gives containers that run on a registered SLES host access to the full SLES repositories. container-suseconnect is invoked automatically when you run Zypper for the first time, and the service adds the correct SLES repositories into the running container. On an unregistered SLES host or on a non-SLES host, the service does nothing. See Section 5.2, “container-suseconnect” for more information.

Note: SLE_BCI repository

There is a SLE_BCI repository for each SLE service pack. This means that SLE BCIs based on SP4 have access to the SLE_BCI repository for SP4, all SLE BCIs based on SP5 use the SLE_BCI repository for SP5, and so on. Each SLE_BCI repository contains all SLE packages except kernels, bootloaders, installers (including YaST), desktop environments, and hypervisors (such as KVM and Xen).

4.3 General-purpose SLE BCIs

There are four general purpose SLE BCIs, and each container image comes with a minimum set of packages to keep its size low. You can use a general purpose SLE BCI either as a starting point for building custom container images, or as a platform for deploying specific software.

SUSE offers several general-purpose SLE BCIs that are intended as deployment targets or as foundations for creating customized images: SLE BCI-Base, SLE BCI-Minimal, SLE BCI-Micro, and SLE BCI-BusyBox. These images share the common SLES base, and none of them ship with a specific language or an application stack. All images feature the RPM database (even if the specific image does not include the RPM package manager) that can be used to verify the provenance of every file in the image. Each image includes the SLES certificate bundle, which allows the deployed applications to use the system’s certificates to verify TLS connections.

The table below provides a quick overview of the differences between SLE BCI-Base, SLE BCI-Minimal, SLE BCI-Micro, and SLE BCI-BusyBox.

Table 4.1: Support matrix
FeaturesSLE BCI-BaseSLE BCI-MinimalSLE BCI-MicroSLE BCI-BusyBox


CA certificates

rpm database




rpm (binary)


4.3.1 SLE BCI-Base and SLE BCI-Init: When you need flexibility

This SLE BCI comes with the Zypper package manager and the free SLE_BCI repository. This allows you to install software available in the repository and customize the image during the build. The downside is the size of the image. It is the largest of the general-purpose SLE BCIs, so it is not always the best choice for a deployment image.

A variant of SLE BCI-Base called SLE BCI-Init comes with systemd preinstalled. The SLE BCI-Init container image can be useful in scenarios requiring systemd for managing services in a single container.

Important: Using SLE BCI-init with Docker

When using SLE BCI-init container with Docker, you must use the following arguments for SYSTEMD to work correctly in the container:

> docker run -ti --tmpfs /run -v /sys/fs/cgroup:/sys/fs/cgroup:rw --cgroupns=host registry.suse.com/bci/bci-init:latest

To correctly shut down the container use the following command:

> docker kill -s SIGRTMIN+3 CONTAINER_ID

4.3.2 SLE BCI-Minimal: When you do not need Zypper

This is a stripped-down version of the SLE BCI-Base image. SLE BCI-Minimal comes without Zypper, but it does have the RPM package manager installed. This significantly reduces the size of the image. However, while RPM can install and remove packages, it lacks support for repositories and automated dependency resolution. The SLE BCI-Minimal image is therefore intended for creating deployment containers, and then installing the desired RPM packages inside the containers. Although you can install the required dependencies, you need to download and resolve them manually. However, this approach is not recommended as it is prone to errors.

4.3.3 SLE BCI-Micro: When you need to deploy static binaries

This image is similar to SLE BCI-Minimal but without the RPM package manager. The primary use case for the image is deploying static binaries produced externally or during multi-stage builds. As there is no straightforward way to install additional dependencies inside the container image, we recommend deploying a project using the SLE BCI-Minimal image only when the final build artifact bundles all dependencies and has no external runtime requirements (like Python or Ruby).

4.3.4 SLE BCI-BusyBox: When you need the smallest and GPLv3-free image

Similar to SLE BCI-Micro, the SLE BCI-BusyBox image comes with the most basic tools only. However, these tools are provided by the BusyBox project. This has the benefit of further size reduction. Furthermore, the image contains no GPLv3 licensed software. When using the image, keep in mind that there are certain differences between the BusyBox tools and the GNU Coreutils. So scripts written for a system that uses GNU Coreutils may require modification to work with BusyBox.

4.3.5 Approximate sizes

For your reference, the list below provides an approximate size of each SLE BCI. Keep in mind that the provided numbers are rough estimations.

  • SLE BCI-Base ~94 MB

  • SLE BCI-Minimal ~42 MB

  • SLE BCI-Micro ~26 MB

  • SLE BCI-BusyBox ~14 MB

4.4 Language stack SLE BCIs

Language stack SLE BCIs are built on top of the SLE BCI-Base general-purpose SLE BCI. Each container image comes with the Zypper stack and the free SLE_BCI repository. Additionally, each image includes most common tools for building and deploying applications in the specific language environment. This includes tools like a compiler or interpreter as well as the language specific package manager.

Below is an overview of the available language stack SLE BCIs.


4.5 Application SLE BCIs

Application SLE BCIs are SLE BCI-Base container images that include specific applications, such as the PostgreSQL database and the Performance Co-Pilot a system-level performance analysis toolkit. Application SLE BCIs are available in the dedicated section of SUSE Registry.

4.6 Important note on status and lifecycle

All container images, except for base, are currently classified as tech preview, and SUSE does not provide official support for them. This information is visible on the web on registry.suse.com. It is also indicated via the com.suse.supportlevel label whether a container image still has the tech preview status. You can use the skopeo and jq utilities to check the status of the desired SLE BCI as follows:

> skopeo inspect docker://registry.suse.com/bci/bci-micro:15.4 | jq '.Labels["com.suse.supportlevel"]'

> skopeo inspect docker://registry.suse.com/bci/bci-base:15.4 | jq '.Labels["com.suse.supportlevel"]'

In the example above, the com.suse.supportlevel label is set to techpreview in the bci-micro container image, indicating that the image still has the tech preview status. The bci-base container image, on the other hand, has full L3 support. Unlike like the general purpose SLE BCIs, the language stack SLE BCIs may not follow the lifecycle of the SLES distribution: they are supported as long as the respective language stack receives support. In other words, new versions of SLE BCIs (indicated by the OCI tags) may be released during the lifecycle of a SLES Service Pack, while older versions may become unsupported. Refer to suse.com/lifecycle to find out whether the container in question is still under support.


A SLE Base Container Image is no longer updated after its support period ends. You will not receive any notification when that happens.

4.6.1 SLE BCI labels

SLE BCIs feature the following labels.


Shows whether this is a pure SLE BCI or an application container based on another SLE BCI.


Marks which section of the SUSE EULA applies to the container image.


Indicates the current release stage of the image.

  • prototype Indicates that the container image is in the ALP prototype phase.

  • alpha Prevents the container image from appearing in the registry.suse.com Web interface even if it is available there. The value also indicates the alpha quality of the container image.

  • beta Lists the container image in the Beta Container Images section of the registry.suse.com Web interface and adds the Beta label to the image. The value also indicates the beta quality of the container image.

  • released Indicates that the container image is released and suitable for production use.


Shows the support level for the container.

  • l2 Problem isolation, which means technical support designed to analyze data, reproduce customer problems, isolate problem areas, and provide a resolution for problems not resolved by Level 1, or prepare for Level 3.

  • l3 Problem resolution, which means technical support designed to resolve problems by engaging engineering to resolve product defects which have been identified by Level 2 Support.

  • techpreview The image is unsupported and intended for use in proof-of-concept scenarios.

  • unsupported No support is provided for the image.


Points to the https://www.suse.com/lifecycle/ page that offers information about the lifecycle of the image. Working with SLE BCI labels

Starting with SLE 15 SP3, all base container images include information such as a build time stamp and description. This information is provided in the form of labels attached to the base images, and is therefore available for derived images and containers.

Here is an example of the Labels information shown by podman inspect:

podman inspect registry.suse.com/suse/sle15
"Labels": {
            "com.suse.bci.base.created": "2023-01-26T22:15:08.381030307Z",
            "com.suse.bci.base.description": "Image for containers based on SUSE Linux Enterprise Server 15 SP4.",
            "com.suse.bci.base.disturl": "obs://build.suse.de/SUSE:SLE-15-SP4:Update:CR/images/1477b070ae019f95b0f2c3c0dce13daf-sles15-image",
            "com.suse.bci.base.eula": "sle-bci",
            "com.suse.bci.base.image-type": "sle-bci",
            "com.suse.bci.base.lifecycle-url": "https://www.suse.com/lifecycle",
            "com.suse.bci.base.reference": "registry.suse.com/suse/sle15:",
            "com.suse.bci.base.release-stage": "released",
            "com.suse.bci.base.source": "https://sources.suse.com/SUSE:SLE-15-SP4:Update:CR/sles15-image/1477b070ae019f95b0f2c3c0dce13daf/",
            "com.suse.bci.base.supportlevel": "l3",
            "com.suse.bci.base.title": "SLE BCI 15 SP4 Base Container Image",
            "com.suse.bci.base.url": "https://www.suse.com/products/server/",
            "com.suse.bci.base.vendor": "SUSE LLC",
            "com.suse.bci.base.version": "",
            "com.suse.eula": "sle-bci",
            "com.suse.image-type": "sle-bci",
            "com.suse.lifecycle-url": "https://www.suse.com/lifecycle",
            "com.suse.release-stage": "released",
            "com.suse.sle.base.created": "2023-01-26T22:15:08.381030307Z",
            "com.suse.sle.base.description": "Image for containers based on SUSE Linux Enterprise Server 15 SP4.",
            "com.suse.sle.base.disturl": "obs://build.suse.de/SUSE:SLE-15-SP4:Update:CR/images/1477b070ae019f95b0f2c3c0dce13daf-sles15-image",
            "com.suse.sle.base.eula": "sle-bci",
            "com.suse.sle.base.image-type": "sle-bci",
            "com.suse.sle.base.lifecycle-url": "https://www.suse.com/lifecycle",
            "com.suse.sle.base.reference": "registry.suse.com/suse/sle15:",
            "com.suse.sle.base.release-stage": "released",
            "com.suse.sle.base.source": "https://sources.suse.com/SUSE:SLE-15-SP4:Update:CR/sles15-image/1477b070ae019f95b0f2c3c0dce13daf/",
            "com.suse.sle.base.supportlevel": "l3",
            "com.suse.sle.base.title": "SLE BCI 15 SP4 Base Container Image",
            "com.suse.sle.base.url": "https://www.suse.com/products/server/",
            "com.suse.sle.base.vendor": "SUSE LLC",
            "com.suse.sle.base.version": "",
            "com.suse.supportlevel": "l3",
            "org.openbuildservice.disturl": "obs://build.suse.de/SUSE:SLE-15-SP4:Update:CR/images/1477b070ae019f95b0f2c3c0dce13daf-sles15-image",
            "org.opencontainers.image.created": "2023-01-26T22:15:08.381030307Z",
            "org.opencontainers.image.description": "Image for containers based on SUSE Linux Enterprise Server 15 SP4.",
            "org.opencontainers.image.source": "https://sources.suse.com/SUSE:SLE-15-SP4:Update:CR/sles15-image/1477b070ae019f95b0f2c3c0dce13daf/",
            "org.opencontainers.image.title": "SLE BCI 15 SP4 Base Container Image",
            "org.opencontainers.image.url": "https://www.suse.com/products/server/",
            "org.opencontainers.image.vendor": "SUSE LLC",
            "org.opencontainers.image.version": "",
            "org.opensuse.reference": "registry.suse.com/suse/sle15:"

All labels are shown twice to ensure that the information in derived images about the original base image is still visible and not overwritten.

Use Podman and the jq tool (sudo zypper in jq) to retrieve labels of a local image. The following command lists all labels and only the labels information of the bci-base:15.4 image:

podman inspect registry.suse.com/bci/bci-base:15.4 | \
jq '.[0].Labels'

It is also possible to retrieve the value of a specific label:

podman inspect registry.suse.com/bci/bci-base:15.4 | \
jq '.[0].Labels["com.suse.sle.base.supportlevel"]'

The preceding command retrieves the value of the com.suse.sle.base.supportlevel label.

The skopeo tool makes it possible to examine labels of an image without pulling it first. For example:

skopeo inspect docker://registry.suse.com/bci/bci-base:15.4 | \
jq '.Labels'
skopeo inspect docker://registry.suse.com/bci/bci-base:15.4 | \
jq '.Labels["com.suse.sle.base.supportlevel"]'

4.6.2 Tags

Tags are used to refer to images. A tag forms a part of the image’s name. Unlike labels, tags can be freely defined, and they are usually used to indicate a version number.

If a tag exists in multiple images, the newest image is used. The image maintainer decides which tags to assign to the container image.

The conventional tag format is repository name: image version specification (usually version number). For example, the tag for the latest published image of PRODUCTNAME 15 SP2 would be suse/sle15:15.2.

4.7 Verifying SLE BCIs with Cosign

To verify a SLE BCI, run Cosign in the container. The command below fetches the signing key from the SUSE server and uses it to verify the latest BCI-Base container image.

> podman run --rm -it gcr.io/projectsigstore/cosign verify \
    --key https://ftp.suse.com/pub/projects/security/keys/container–key.pem \
    registry.suse.com/bci/bci-base:latest | tail -1 | jq

    "critical": {
      "identity": {
        "docker-reference": "registry.suse.com/bci/bci-base"
      "image": {
        "docker-manifest-digest": "sha256:52a828600279746ef669cf02a599660cd53faf4b2430a6b211d593c3add047f5"
      "type": "cosign container image signature"
    "optional": {
      "creator": "OBS"

The signing key can be used to verify all SLE BCIs, and it also ships with SLE 15 (the /usr/share/container-keys/suse-container-key.pem file).

You can also check BCI container images against rekor, the immutable tamper resistant ledger. For example:

> podman run --rm -it -e COSIGN_EXPERIMENTAL=1 gcr.io/projectsigstore/cosign \
    verify --key https://ftp.suse.com/pub/projects/security/keys/container–key.pem \
    registry.suse.com/bci/bci-base:latest | tail -1 | jq
    "critical": {
      "identity": {
        "docker-reference": "registry.suse.com/bci/bci-base"
      "image": {
        "docker-manifest-digest": "sha256:52a828600279746ef669cf02a599660cd53faf4b2430a6b211d593c3add047f5"
      "type": "cosign container image signature"
    "optional": {
      "creator": "OBS"

If verification fails, the output of the cosign verify command is similar to the one below.

Error: no matching signatures:
crypto/rsa: verification error
main.go:62: error during command execution: no matching signatures:
crypto/rsa: verification error

4.8 Understanding SLE BCIs

If you have a working knowledge of containers, you will not have any difficulties using SLE BCIs. However, there are certain features that set SLE BCIs apart from similar offerings, like images based on Debian or Alpine Linux. And understanding the specifics can help you to get the most out of SLE BCIs in the shortest time possible.

4.8.1 Package manager

The default package manager in SLES is Zypper. Similar to APT in Debian and APK in Alpine Linux, Zypper offers a command-line interface for all package management tasks. Below is brief overview of commonly used container-related Zypper commands.

Install packages

zypper --non-interactive install PACKAGE_NAME

Add a repository

zypper --non-interactive addrepo REPOSITORY_URL; zypper --non-interactive refresh

Update all packages

zypper --non-interactive update

Remove a package

zypper --non-interactive remove --clean-deps PACKAGE_NAME (the --clean-deps flag ensures that no longer required dependencies are removed as well)

Clean up temporary files

zypper clean

For more information on using Zypper, refer to https://documentation.suse.com/sles-15/html/SUSE Linux Enterprise Server-all/cha-sw-cl.html#sec-zypper.

All the described commands use the --non-interactive flag to skip confirmations, since you cannot approve these manually during container builds. Keep in mind that you must use the flag with any command that modifies the system. Also note that --non-interactive is not a "yes to all" flag. Instead, --non-interactive confirms what is considered to be the intention of the user. For example, an installation command with the --non-interactive option fails if it needs to import new repository signing keys, as that is something that the user must verify themselves.

4.8.2 Using container-suseconnect with SLE BCIs

container-suseconnect is a plugin available in all SLE BCIs that ship with Zypper. When the plugin detects the host’s SUSE Linux Enterprise Server registration credentials, it uses them to give the container access the SUSE Linux Enterprise repositories. This includes additional modules and previous package versions that are not part of the free SLE_BCI repository. Refer to Section 5.2, “container-suseconnect” for more information on how to use the repository for SLES, openSUSE, and non-SLES hosts.

4.8.3 Common patterns

Here are a few examples that can give you an idea how to accomplish certain tasks in a SLE BCI compared to Debian.

Remove orphaned packages
  • Debian: apt-get autoremove -y

  • SLE BCI: Not required if you remove installed packages using the zypper --non-interactive remove --clean-deps PACKAGE_NAME

Obtain container’s architecture
  • Debian: dpkgArch="$(dpkg --print-architecture | awk -F- '{ print $NF }')"

  • SLE BCI: arch="$(uname -p|sed 's/x86_64/amd64/')"

Install packages required for compilation
  • Debian: apt-get install -y build-essential

  • SLE BCI: zypper -n in gcc gcc-c++ make

Verify GnuPG signatures
  • Debian: gpg --batch --verify SIGNATURE_URL FILE_TO_VERIFY

  • SLE BCI: zypper -n in dirmngr; gpg --batch --verify SIGNATURE_URL FILE_TO_VERIFY; zypper -n remove --clean-deps dirmngr; zypper -n clean

4.8.4 Package naming conventions

SLE package naming conventions differ from Debian, Ubuntu, and Alpine, and they are closer to those of RHEL. The main difference is that development packages of libraries (that is, packages containing headers and build description files) are named PACKAGE-devel in SLE, as opposed to PACKAGE-dev as they are in Debian and Ubuntu. When in doubt, search for the package directly using the following command: docker run --rm registry.suse.com/bci/bci-base:OS_VERSION zypper search PACKAGE_NAME (replace OS_VERSION with the appropriate service version number, for example: 15.3 or 15.4).

4.8.5 Adding GPG signing keys

Adding external repositories to a container or container image normally requires importing the GPG key used for signing the packages. This can be done with the rpm --import KEY_URL command. This adds the key to the RPM database, and all packages from the repository can be installed afterwards.

4.9 Getting started with SLE Base Container Images

The SLE BCIs are available as OCI-compatible container images directly from registry.suse.com and can be used like any other container image. For example, using one of the general purpose containers:

> podman run --rm -it registry.suse.com/bci/bci-base:15.4 grep '^NAME' /etc/os-release

Alternatively, you can use a SLE BCI in Dockerfile as follows:

FROM registry.suse.com/bci/bci-base:15.4
RUN zypper -n in python3 && \
    echo "Hello Green World!" > index.html
ENTRYPOINT ["/usr/bin/python3", "-m", "http.server"]

You can then build container images using the docker build . or buildah bud . commands:

> docker build .
Sending build context to Docker daemon  2.048kB
Step 1/4 : FROM registry.suse.com/bci/bci-base:15.4
 ---> e34487b4c4e1
Step 2/4 : RUN zypper -n in python3 &&     echo "Hello Green World!" > index.html
 ---> Using cache
 ---> 9b527dfa45e8
Step 3/4 : ENTRYPOINT ["/usr/bin/python3", "-m", "http.server"]
 ---> Using cache
 ---> 953080e91e1e
Step 4/4 : EXPOSE 8000
 ---> Using cache
 ---> 48b33ec590a6
Successfully built 48b33ec590a6

> docker run -p 8000:8000 --rm -d 48b33ec590a6

> curl localhost:8000
Hello Green World!