Kali 2026.3 Opens Container Image Builds: Check Custom Scripts Before Reusing Them

A custom hostname, an extra package and the wrong architecture are enough to make a freshly built Kali image unsuitable for its intended machine. With today’s Kali 2026.3 release, the image-building scripts have changed, so an old command line deserves another look before it goes back into a build job.

The October 26 release announcement describes a first milestone in refreshing Kali’s public build scripts. These are the scripts used for official images. The project has aligned their arguments, layout and features where possible, and acknowledges that changes have broken some existing workflows along the way.

Start with the installer job you actually maintain

The release’s example clones the kali-installer repository. Building on the host requires its listed image-building dependencies, including simple-cdd and xorriso. The alternative uses build-in-container.sh, which detects Docker or Podman, creates a build container and runs the build there.

In Kali’s installer example, sudo ./build.sh starts a host build. After Podman is installed, sudo ./build-in-container.sh takes the container route. The helper detects the available engine and runs the build inside it. This makes a Debian-based workstation a more practical starting point, without installing the installer’s full dependency list on that host.

The example --hostname haxbox --packages rustscan changes the hostname and adds a package. A second example selects kali-dev, netinst and arm64. Someone copying that second command onto an AMD64 build job has changed three inputs at once. Compare your job’s arguments with ./build.sh --help and the current README, then check the output path in the build log.

A rolling build needs its own record

Kali’s default installer example targets AMD64 and the kali-rolling branch. That matters for repeatability: writing “2026.3” in a job description does not pin the repository contents or every package fetched from a rolling mirror. Keep the build date, script revision, selected branch and logs with the resulting image.

The project also says it did not finish refreshing every build script for this release and is aiming for 2026.4. Treat the installer example as documentation for that build path, rather than proof that every platform now has identical container support.

Check the installed machine separately

For people using Kali rather than building it, the release also brings Plasma 6.7 and a kernel update to 7.1.5. Existing installations can update through the rolling repositories. Review the package transaction before accepting a full upgrade, particularly on a machine with a custom kernel or external modules.

Afterward, grep VERSION /etc/os-release checks the distribution version, while uname -r reports the kernel currently running. Those answer different questions. Kali notes that the kernel output varies by architecture; do not demand the AMD64 suffix shown in its example on another system.

Keep the previous working image until the replacement has booted and its required services have been checked. If one fails, our journalctl troubleshooting guide explains how to collect the unit’s messages for the current boot. Save the first error with the build record so the next attempt starts with evidence of what failed.