master builds:
202605 builds:
202511 builds:
202505 builds:
202411 builds:
202405 builds:
All SONiC project build pipelines can be found at Download Portal for SONiC Images
Following are the instructions on how to build an (ONIE) compatible network operating system (NOS) installer image for network switches, and also how to build docker images running inside the NOS. Note that SONiC images are built per ASIC platform. Switches using the same ASIC platform share a common image. For a list of supported switches and ASIC, please refer to this list
Any server can be a build image server as long as it has:
Note: If you are in a VM, make sure you have support for nested virtualization. Some cases (e.g. building OVS image) also requires extra configuration options to expose the full KVM interface to the VM (e.g. the KVM paravirtualization support on VirtualBox).
A good choice of OS for building SONiC is currently Ubuntu 22.04 or Ubuntu 24.04.
Note (Ubuntu 24.04): Python 3.12+ removed the
impmodule, which breaks the legacyj2clipackage. The prerequisites script and manual steps below installjinjanatorinstead, which is a drop-in replacement that works on all Python versions.
For convenience, you can use the automated prerequisites script to handle both prerequisites installation and repository cloning:
curl -sSL https://raw.githubusercontent.com/sonic-net/sonic-buildimage/master/scripts/prerequisites.sh | bash
If you have already cloned the repo, run it locally to install only the prerequisites
(the script detects an existing clone at SONIC_DIR and skips the clone/checkout step):
cd ~/sonic-buildimage # or wherever your clone lives
SONIC_DIR=$(pwd) bash scripts/prerequisites.sh
Tip: You can override clone location and branch:
SONIC_DIR=~/my-sonic BRANCH=202511 bash scripts/prerequisites.shWhenSONIC_DIRalready exists, only prerequisites are installed — no second clone.
This script will automatically:
After completing this step, proceed to the Usage section below.
sudo apt install -y python3-pip
pip3 install --user jinjanator
Note: If you cannot run the
j2command after installation, this is likely because the~/.local/bindirectory was just created and is not yet included in your$PATH. Please log out and log back in to refresh your environment, then test the command again.
sudo gpasswd -a ${USER} dockerclone3 syscall, which is now used in Bookworm.Note: If a previous installation of Docker using snap was present on the system, remove it and also remove docker from snap before reinstalling docker. This will avoid known bugs that falsely report read-only filesystems issues during the build process.
To clone the code repository recursively:
git clone --recurse-submodules https://github.com/sonic-net/sonic-buildimage.git
To build SONiC installer image and docker images, run the following commands:
# Ensure the 'overlay' module is loaded on your development system
sudo modprobe overlay
# Enter the source directory
cd sonic-buildimage
# (Optional) Checkout a specific branch. By default, it uses master branch.
# For example, to checkout the branch 201911, use "git checkout 201911"
git checkout [branch_name]
# Execute make init once after cloning the repo,
# or after fetching remote repo with submodule updates
make init
# Execute make configure once to configure ASIC
make configure PLATFORM=[ASIC_VENDOR]
# Build SONiC image with 4 jobs in parallel.
# Note: You can set this higher, but 4 is a good number for most cases
# and is well-tested.
make SONIC_BUILD_JOBS=4 all
Parallelism vs memory: Each parallel job can use 4–6 GB RAM during C++ compilation,
plus a ~4 GB base overhead. Rule of thumb: (JOBS × 6 GB) + 4 GB ≤ available RAM:
| JOBS | Approx RAM needed | Typical VS build time |
|---|---|---|
| 1 | ~10 GB | ~3 hours |
| 4 | ~28 GB | ~1.5 hours |
| 8 | ~52 GB | ~1 hour |
Contain OOM in the build container (protects host processes):
# Add to rules/config.user (persists across rebases):
SONIC_BUILD_MEMORY = 24g
Skip tests for faster iteration:
make SONIC_BUILD_JOBS=4 BUILD_SKIP_TEST=y all
Use a persistent config file instead of CLI overrides — create rules/config.user (gitignored):
SONIC_CONFIG_BUILD_JOBS = 4
BUILD_SKIP_TEST = y
SONIC_BUILD_MEMORY = 24g
DEFAULT_BUILD_LOG_TIMESTAMP = simple
The supported ASIC vendors are:
sudo apt-get install --allow-downgrades -y docker-ce=5:18.09.0~3-0~ubuntu-xenial
sudo apt-get install --allow-downgrades -y docker-ce-cli=5:18.09.0~3-0~ubuntu-xenial
To build Arm32 bit for (ARMHF) platform
# Execute make configure once to configure ASIC and ARCH
make configure PLATFORM=[ASIC_VENDOR] PLATFORM_ARCH=armhf
make target/sonic-[ASIC_VENDER]-armhf.bin
example:
make configure PLATFORM=marvell-prestera PLATFORM_ARCH=armhf
make target/sonic-marvell-prestera-armhf.bin
To build Arm32 bit for (ARMHF) Marvell Prestera platform on amd64 host for debian buster using cross-compilation, run the following commands:
# Execute make configure once to configure ASIC and ARCH for cross-compilation build
NOJESSIE=1 NOSTRETCH=1 BLDENV=buster CROSS_BLDENV=1 \
make configure PLATFORM=marvell-prestera PLATFORM_ARCH=armhf
# Execute Arm32 build using cross-compilation environment
NOJESSIE=1 NOSTRETCH=1 BLDENV=buster CROSS_BLDENV=1 make target/sonic-marvell-prestera-armhf.bin
Running the above Arm32 build using cross-compilation instead of qemu emulator drastically reduces the build time.
To build Arm64 bit for platform
# Execute make configure once to configure ASIC and ARCH
make configure PLATFORM=[ASIC_VENDOR] PLATFORM_ARCH=arm64
# example:
make configure PLATFORM=marvell-prestera PLATFORM_ARCH=arm64
NOTE:
Recommend reserving at least 100G free space to build one platform
with a single job.
The build process will use more disk if you are setting SONIC_BUILD_JOBS
to more than 1.
If Docker's workspace folder, /var/lib/docker,
resides on a partition without sufficient free space,
you may encounter an error like the following during a Docker container build job:
/usr/bin/tar: /path/to/sonic-buildimage/<some_file>: Cannot write: No space left on device
The solution is to move the directory to a partition with more free space.
Use
http_proxy=[your_proxy] https_proxy=[your_proxy] no_proxy=[your_no_proxy] make
to enable http(s) proxy in the build process.
Add your user account to docker group and use your user account to make.
root or sudo are not supported.
For more details on cross-compilation errors, please refer to README.arm64_build_on_amd64.md
The SONiC installer contains all docker images needed. SONiC uses one image for all devices of a same ASIC vendor.
For Broadcom ASIC, we build ONIE and EOS image. EOS image is used for Arista devices, ONIE image is used for all other Broadcom ASIC based devices.
make configure PLATFORM=broadcom
# build debian stretch required targets
BLDENV=stretch make stretch
# build ONIE image
make target/sonic-broadcom.bin
# build EOS image
make target/sonic-aboot-broadcom.swi
You may find the rules/config file useful. It contains configuration options for the build process, like adding more verbosity or showing dependencies, username and password for base image etc.
Every docker image is built and saved to target/ directory. So, for instance, to build only docker-database, execute:
make target/docker-database.gz
Same goes for debian packages, which are under target/debs/:
make target/debs/swss_1.0.0_amd64.deb
Every target has a clean target, so in order to clean swss, execute:
make target/debs/swss_1.0.0_amd64.deb-clean
It is recommended to use clean targets to clean all packages that are built together, like dev packages for instance. In order to be more familiar with build process and make some changes to it, it is recommended to read this short Documentation.
SONiC build system supports building dockers and ONIE-image with debug tools and debug symbols, to help with live & core debugging. For details refer to SONiC Buildimage Guide.
Please refer to SONiC roadmap on the SAI version for each SONiC release.
Opt-in SBOM generation and SBOM-based vulnerability scanning are
supported via ENABLE_SBOM=y at build time. The default build path
is unchanged; enabling SBOM adds CycloneDX 1.6 + SPDX 2.3 + SLSA
v1.0 in-toto provenance sidecars per built artifact, along with
standalone CycloneDX scanner output for vulnerability reports.
See README.sbom.md for the full design, build flag reference, vulnerability-report quick start, VEX workflow, reproducibility notes, and known limitations.
sudo../target, containing the NOS installer image
and docker images.
All contributors must sign a contribution license agreement before contributions can be accepted. Visit EasyCLA - Linux Foundation.
We're following basic GitHub Flow. If you have no idea what we're talking about, check out GitHub's official guide. Note that merge is only performed by the repository maintainer.
Guide for performing commits:
[component/folder touched]: Description intent of your changes
[List of changes]
Signed-off-by: Your Name your@email.com
For example:
swss-common: Stabilize the ConsumerTable
- Fixing autoreconf
- Fixing unit-tests by adding checkers and initialize the DB before start
- Adding the ability to select from multiple channels
- Health-Monitor - The idea of the patch is that if something went wrong with the notification channel, we will have the option to know about it (Query the LLEN table length).
Signed-off-by: user@dev.null
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
(top 30 of 403)
C
54.7%
Python
33.5%
Jinja
5.9%
Shell
3.3%
Makefile
1.5%
master builds:
202605 builds:
202511 builds:
202505 builds:
202411 builds:
202405 builds:
All SONiC project build pipelines can be found at Download Portal for SONiC Images
Following are the instructions on how to build an (ONIE) compatible network operating system (NOS) installer image for network switches, and also how to build docker images running inside the NOS. Note that SONiC images are built per ASIC platform. Switches using the same ASIC platform share a common image. For a list of supported switches and ASIC, please refer to this list
Any server can be a build image server as long as it has:
Note: If you are in a VM, make sure you have support for nested virtualization. Some cases (e.g. building OVS image) also requires extra configuration options to expose the full KVM interface to the VM (e.g. the KVM paravirtualization support on VirtualBox).
A good choice of OS for building SONiC is currently Ubuntu 22.04 or Ubuntu 24.04.
Note (Ubuntu 24.04): Python 3.12+ removed the
impmodule, which breaks the legacyj2clipackage. The prerequisites script and manual steps below installjinjanatorinstead, which is a drop-in replacement that works on all Python versions.
For convenience, you can use the automated prerequisites script to handle both prerequisites installation and repository cloning:
curl -sSL https://raw.githubusercontent.com/sonic-net/sonic-buildimage/master/scripts/prerequisites.sh | bash
If you have already cloned the repo, run it locally to install only the prerequisites
(the script detects an existing clone at SONIC_DIR and skips the clone/checkout step):
cd ~/sonic-buildimage # or wherever your clone lives
SONIC_DIR=$(pwd) bash scripts/prerequisites.sh
Tip: You can override clone location and branch:
SONIC_DIR=~/my-sonic BRANCH=202511 bash scripts/prerequisites.shWhenSONIC_DIRalready exists, only prerequisites are installed — no second clone.
This script will automatically:
After completing this step, proceed to the Usage section below.
sudo apt install -y python3-pip
pip3 install --user jinjanator
Note: If you cannot run the
j2command after installation, this is likely because the~/.local/bindirectory was just created and is not yet included in your$PATH. Please log out and log back in to refresh your environment, then test the command again.
sudo gpasswd -a ${USER} dockerclone3 syscall, which is now used in Bookworm.Note: If a previous installation of Docker using snap was present on the system, remove it and also remove docker from snap before reinstalling docker. This will avoid known bugs that falsely report read-only filesystems issues during the build process.
To clone the code repository recursively:
git clone --recurse-submodules https://github.com/sonic-net/sonic-buildimage.git
To build SONiC installer image and docker images, run the following commands:
# Ensure the 'overlay' module is loaded on your development system
sudo modprobe overlay
# Enter the source directory
cd sonic-buildimage
# (Optional) Checkout a specific branch. By default, it uses master branch.
# For example, to checkout the branch 201911, use "git checkout 201911"
git checkout [branch_name]
# Execute make init once after cloning the repo,
# or after fetching remote repo with submodule updates
make init
# Execute make configure once to configure ASIC
make configure PLATFORM=[ASIC_VENDOR]
# Build SONiC image with 4 jobs in parallel.
# Note: You can set this higher, but 4 is a good number for most cases
# and is well-tested.
make SONIC_BUILD_JOBS=4 all
Parallelism vs memory: Each parallel job can use 4–6 GB RAM during C++ compilation,
plus a ~4 GB base overhead. Rule of thumb: (JOBS × 6 GB) + 4 GB ≤ available RAM:
| JOBS | Approx RAM needed | Typical VS build time |
|---|---|---|
| 1 | ~10 GB | ~3 hours |
| 4 | ~28 GB | ~1.5 hours |
| 8 | ~52 GB | ~1 hour |
Contain OOM in the build container (protects host processes):
# Add to rules/config.user (persists across rebases):
SONIC_BUILD_MEMORY = 24g
Skip tests for faster iteration:
make SONIC_BUILD_JOBS=4 BUILD_SKIP_TEST=y all
Use a persistent config file instead of CLI overrides — create rules/config.user (gitignored):
SONIC_CONFIG_BUILD_JOBS = 4
BUILD_SKIP_TEST = y
SONIC_BUILD_MEMORY = 24g
DEFAULT_BUILD_LOG_TIMESTAMP = simple
The supported ASIC vendors are:
sudo apt-get install --allow-downgrades -y docker-ce=5:18.09.0~3-0~ubuntu-xenial
sudo apt-get install --allow-downgrades -y docker-ce-cli=5:18.09.0~3-0~ubuntu-xenial
To build Arm32 bit for (ARMHF) platform
# Execute make configure once to configure ASIC and ARCH
make configure PLATFORM=[ASIC_VENDOR] PLATFORM_ARCH=armhf
make target/sonic-[ASIC_VENDER]-armhf.bin
example:
make configure PLATFORM=marvell-prestera PLATFORM_ARCH=armhf
make target/sonic-marvell-prestera-armhf.bin
To build Arm32 bit for (ARMHF) Marvell Prestera platform on amd64 host for debian buster using cross-compilation, run the following commands:
# Execute make configure once to configure ASIC and ARCH for cross-compilation build
NOJESSIE=1 NOSTRETCH=1 BLDENV=buster CROSS_BLDENV=1 \
make configure PLATFORM=marvell-prestera PLATFORM_ARCH=armhf
# Execute Arm32 build using cross-compilation environment
NOJESSIE=1 NOSTRETCH=1 BLDENV=buster CROSS_BLDENV=1 make target/sonic-marvell-prestera-armhf.bin
Running the above Arm32 build using cross-compilation instead of qemu emulator drastically reduces the build time.
To build Arm64 bit for platform
# Execute make configure once to configure ASIC and ARCH
make configure PLATFORM=[ASIC_VENDOR] PLATFORM_ARCH=arm64
# example:
make configure PLATFORM=marvell-prestera PLATFORM_ARCH=arm64
NOTE:
Recommend reserving at least 100G free space to build one platform
with a single job.
The build process will use more disk if you are setting SONIC_BUILD_JOBS
to more than 1.
If Docker's workspace folder, /var/lib/docker,
resides on a partition without sufficient free space,
you may encounter an error like the following during a Docker container build job:
/usr/bin/tar: /path/to/sonic-buildimage/<some_file>: Cannot write: No space left on device
The solution is to move the directory to a partition with more free space.
Use
http_proxy=[your_proxy] https_proxy=[your_proxy] no_proxy=[your_no_proxy] make
to enable http(s) proxy in the build process.
Add your user account to docker group and use your user account to make.
root or sudo are not supported.
For more details on cross-compilation errors, please refer to README.arm64_build_on_amd64.md
The SONiC installer contains all docker images needed. SONiC uses one image for all devices of a same ASIC vendor.
For Broadcom ASIC, we build ONIE and EOS image. EOS image is used for Arista devices, ONIE image is used for all other Broadcom ASIC based devices.
make configure PLATFORM=broadcom
# build debian stretch required targets
BLDENV=stretch make stretch
# build ONIE image
make target/sonic-broadcom.bin
# build EOS image
make target/sonic-aboot-broadcom.swi
You may find the rules/config file useful. It contains configuration options for the build process, like adding more verbosity or showing dependencies, username and password for base image etc.
Every docker image is built and saved to target/ directory. So, for instance, to build only docker-database, execute:
make target/docker-database.gz
Same goes for debian packages, which are under target/debs/:
make target/debs/swss_1.0.0_amd64.deb
Every target has a clean target, so in order to clean swss, execute:
make target/debs/swss_1.0.0_amd64.deb-clean
It is recommended to use clean targets to clean all packages that are built together, like dev packages for instance. In order to be more familiar with build process and make some changes to it, it is recommended to read this short Documentation.
SONiC build system supports building dockers and ONIE-image with debug tools and debug symbols, to help with live & core debugging. For details refer to SONiC Buildimage Guide.
Please refer to SONiC roadmap on the SAI version for each SONiC release.
Opt-in SBOM generation and SBOM-based vulnerability scanning are
supported via ENABLE_SBOM=y at build time. The default build path
is unchanged; enabling SBOM adds CycloneDX 1.6 + SPDX 2.3 + SLSA
v1.0 in-toto provenance sidecars per built artifact, along with
standalone CycloneDX scanner output for vulnerability reports.
See README.sbom.md for the full design, build flag reference, vulnerability-report quick start, VEX workflow, reproducibility notes, and known limitations.
sudo../target, containing the NOS installer image
and docker images.
All contributors must sign a contribution license agreement before contributions can be accepted. Visit EasyCLA - Linux Foundation.
We're following basic GitHub Flow. If you have no idea what we're talking about, check out GitHub's official guide. Note that merge is only performed by the repository maintainer.
Guide for performing commits:
[component/folder touched]: Description intent of your changes
[List of changes]
Signed-off-by: Your Name your@email.com
For example:
swss-common: Stabilize the ConsumerTable
- Fixing autoreconf
- Fixing unit-tests by adding checkers and initialize the DB before start
- Adding the ability to select from multiple channels
- Health-Monitor - The idea of the patch is that if something went wrong with the notification channel, we will have the option to know about it (Query the LLEN table length).
Signed-off-by: user@dev.null
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
(top 30 of 403)
C
54.7%
Python
33.5%
Jinja
5.9%
Shell
3.3%
Makefile
1.5%