Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / SUSE Linux Enterprise Server Documentation / Container Guide / SLE Base Container Images
Applies to SUSE Linux Enterprise Server 15 SP4

2 SLE Base Container Images

2.1 Introduction to SLE Base Container Images

SLE Base Container Image (SLE BCI) are minimal SUSE Linux Enterprise Server 15-based images that you can use to develop, deploy, and share applications. There are two types of SLE BCI:

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

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

In addition to that, we will provide Application Container Images based on SLE BCI featuring popular containerized applications like Nginx, PostgreSQL, MariaDB and RMT.

2.1.1 Highlights

  • SLE BCI are fully compatible with SUSE Linux Enterprise Server, but they do not require a subscription to run and distribute them.

  • SLE BCI 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 BCI (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.

2.1.2 General-purpose SLE BCI

There are four general purpose SLE BCI, 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. For more information about general purpose SLE BCI, see Section 2.3, “BCI-Base, BCI-Minimal, BCI-Micro, and BCI-BusyBox”.

2.1.3 Language stack SLE BCI

Language stack SLE BCI are built on top of the 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. For more information about language stack SLE BCI, see Section 2.4, “Language stack SLE Base Container Images”.

2.1.4 Important note on status and lifecycle

All container images, except for base, are currently classified as tech preview, and SUSE doesn't provide official support for them. This information is visible on the web on registry.suse.com. In addition to that, 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 is fully l3 supported. Unlike like the general purpose SLE BCI, the language stack SLE BCI may not follow the lifecycle of the SLE distribution: they are supported as long as the respective language stack receives support. In other words, new versions of SLE BCI (indicated by the OCI tags) may be released during the lifecycle of a SLE 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.

2.1.5 Getting started

The SLE BCI 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 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!

2.2 Why SLE Base Container Images

SLE BCIs offer a platform for creating SLE-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 4,000 packages available for the AMD64/Intel 64, AArch64, ppc64le, and s390x 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 SLES. 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 SLE, they feature the same level of stability and quality assurance as SUSE Linux Enterprise Server. 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.


BCIs are covered by a permissive EULA that allows you to redistribute custom container images based on a BCI.

2.3 BCI-Base, BCI-Minimal, BCI-Micro, and BCI-BusyBox

SUSE offers several general-purpose SLE Base Container Images that are intended as deployment targets or as foundations for creating customized images: BCI-Base, BCI-Minimal, BCI-Micro, and 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.

2.3.1 Quick overview

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


2.3.2 BCI-Base and BCI-Init: When you need flexibility

This SLE BCI comes with the Zypper package manager and a 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 BCI-Base called BCI-Init comes with systemd preinstalled. The BCI-Init container image can be useful in scenarios requiring systemd for managing services in a single container.

2.3.3 BCI-Minimal: When you do not need Zypper

This is a stripped-down version of the BCI-Base image. 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 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.

2.3.4 BCI-Micro: When you need to deploy static binaries

This image is similar to 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 BCI-Minimal image only when the final build artifact bundles all dependencies and has no external runtime requirements (like Python or Ruby).

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

Similar to BCI-Micro, the 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.

2.3.6 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.

  • BCI-Base ~94 MB

  • BCI-Minimal ~42 MB

  • BCI-Micro ~26 MB

  • BCI-BusyBox ~14 MB

2.4 Language stack SLE Base Container Images

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.

2.4.1 Language stack SLE BCIs

Language stack SLE BCI are built on top of BCI-Base. Below is an overview of the available language stack SLE BCIs.


2.4.2 Package manager

The default package manager in SUSE Linux Enterprise 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/SLES-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 should verify themselves.

2.4.3 Common patterns

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

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

  • SLE BCI: Not required as long as 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

2.4.4 Package naming conventions

SUSE Linux Enterprise package naming conventions differ from Debian, Ubuntu, and Alpine, and they are closer to those of Red Hat Enterprise Linux. The main difference is that development packages of libraries (that is, packages containing headers and build description files) are named PACKAGE-devel in SUSE Linux Enterprise, 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).

2.4.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.