SingularityCE: SIF containers, and an end of engineering ahead

4.6.0 is expected to be the last release Sylabs manages

The first section of the project documentation is the one that decides any adoption question. There is an End of Life and End of Engineering notice, and the text is unambiguous: SingularityCE 4.6.0 is expected to be the final release managed by Sylabs, the code remains available under an open source licence, and security, bugfix and feature development will no longer be performed by Sylabs. The 4.6.0 release also incorporates code that was previously part of the commercial SingularityPRO edition, which means the final community release is also the most capable one. For a team evaluating the platform, this inverts the usual questions. Instead of asking what the roadmap holds, you ask who will patch a container runtime with a network stack and a setuid-adjacent privilege model after the vendor stops, and whether your organisation can absorb that cost. The repository is still being pushed to, with the last push on 2026-10-16, and the release history shows 4.5.0 in June, 4.5.1 in August and 4.6.0 in October 2026, so the branch is not frozen even as the engineering commitment ends.

SIF is a single file, and it can be signed and encrypted

The image format is the part of the design that travels well. SingularityCE uses an immutable single-file container image format, the SIF format, and the documentation highlights two properties that matter for sharing: cryptographic signatures and encryption. A single file is easy to move. A researcher can put an image on a shared filesystem, a journal article can point at a file, and a cluster administrator can hand the same artifact to ten users without a registry round trip. The other side of immutability is that the file does not change once built, so a signature over it means something specific, and encryption means the artifact can be distributed without giving away its contents. The repository examples directory shows the range of build styles the project supports, with directories for docker/ and shub/ alongside the usual distribution recipes, a scratch/ example for a minimal image, a multistage/ example, a nested/ example and a plugins/ example.

Integration over isolation, and you keep your own uid

The security model is the reason this project exists as a separate thing from daemon-rooted container platforms, and the documentation is blunt about it. Inside the container you are the same user you are outside, and you cannot gain additional privilege on the host system by default. The alternative approach, and the one the project names as its opposite, is integration over isolation by default: easily making use of GPUs, high speed networks, parallel filesystems on a cluster or server. On a shared HPC system those are not conveniences, they are the reason the software exists, because a model that isolates a user from the host filesystem and the network is useless for the actual workload. The cost is that the container is not a security boundary in the way a rootful daemon is, and a user who can write to the image or invoke the runtime with the right options is closer to the host than the same user inside an isolated container. The project does not hide this trade-off, it leads with it.

Building it from source follows the INSTALL.md path

The project documentation does not carry install commands inline, it points at them. For a source install the instruction is to follow the installation instructions in INSTALL.md, and for other installation options the reader is sent to the administrator guide on the Sylabs site, with the main documentation at sylabs.io/docs. The repository layout tells you what a source build involves. There is an mconfig script and a makeit/ directory, which is the build system wrapper, a cmd/ directory for the command line entry point, internal/ and pkg/ for the library code, e2e/ and test/ for the test suites, a debian/ directory for packaging, dist/ for distribution artefacts, and enterprise-plugin/ and log-plugin/ directories for the plugin interfaces. The module declaration in the root go.mod names the project as a versioned module and pins a specific Go toolchain:

module github.com/sylabs/singularity/v4

go 1.26.8

The dependency list is long and tells you what the runtime leans on: containerd and go-runc, buildkit, containers/image, docker/cli, the container networking plugins, plus the usual Go libraries. That set is why the examples include docker/ and shub/, since working with images produced elsewhere is part of the design rather than an add-on.

Go support tracks the two most recent stable releases

One policy in the documentation matters more now that the vendor has stepped back, because it determines who else is obliged to care about the language runtime. SingularityCE aims to maintain support for the two most recent stable versions of Go, which the documentation ties to the Go release maintenance policy and the Go security policy, so that critical bug fixes and security patches for the language are available for the supported versions. In practice, once Sylabs stops development, following Go releases becomes a job for whoever continues the project, and a runtime pinned to a language version that has left the support window accumulates issues quietly. The same logic applies to the container stack underneath, since the dependency list pins specific versions of containerd, runc, buildkit and the networking plugins rather than tracking them continuously. For an adopter, this is the concrete maintenance surface to price: a Go toolchain, a set of container runtime libraries, and a plugin interface.

A 3-clause BSD licence, with dependency licences to account for

The licensing position is clear and generous. The README states that SingularityCE is open source software distributed under the BSD License, and the licence section repeats it, noting that unless otherwise noted the project is licensed under a 3-clause BSD license. The repository carries the licence file as LICENSE.md, and it is worth noticing the two extra files beside it, LICENSE_DEPENDENCIES.md and LICENSE_THIRD_PARTY.md, which record the licences of the vendored and third-party components. With a runtime that pulls in containerd, runc, buildkit and the container networking plugins, that is the sensible bookkeeping, and an organisation that has to pass a licence scan will want those files rather than the BSD text alone. Because the code is BSD licensed and remains available after end of engineering, a team that takes over maintenance is free to do so, which is the point of the licence, but it also means nobody is obliged to do it for you.

The alternative is the daemon model, and it is a different bet

The realistic alternative is the daemon-based approach, where a root service owns the images and runs the containers on behalf of unprivileged users through a client. The difference in approach is not cosmetic, it is about who holds privilege and what the artifacts are. In the daemon model, the runtime is a privileged long lived service, images live in a registry or a content store managed by that service, and a user interacts with the system through a client that the service authorises. In SingularityCE the runtime is started by the user, the image is a file the user holds, and the user is the user inside it. That is what makes a signed single file transferable between a laptop and a login node, and it is also what makes the model unsuitable for a deployment where you need strong isolation between mutually distrusting tenants, since the point of the project is to let the user reach the host resources the workload needs. Neither side of that trade-off is free. The daemon model needs a privileged service to maintain; this model needs you to own the runtime after the vendor leaves.

Editorial conclusion

SingularityCE fits a research or HPC group that needs a portable, signable single-file image and cannot run a root-owned container daemon on a shared login node, and it fits teams willing to take over maintenance themselves. It does not fit a team that expects a vendor to ship security patches, because Sylabs states that security, bugfix and feature development has stopped after 4.6.0, and it does not fit a group that needs rootless daemon isolation instead of integration. Verify the EOL announcement and the release procedure in the repository before you commit, and budget for owning the code. The last push to the repository was on 2026-10-16.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. sylabs/singularity on GitHub