SlimToolkit runs your application at build time, then deletes what it never touched

xray reads the image, build rewrites it from what the app loaded

The command set is the mental model: xray, lint, build, debug, run, images, merge, registry and vulnerability, plus others. Reading comes before rewriting. xray is the inspection pass, build is the one that produces a new smaller image, and debug, run and merge exist for looking at or working with what came out.

The mechanism underneath build is behavioural rather than static. Slim starts your application in a temporary container, lets it load what it needs, and keeps the files it touched while discarding the rest. That is also where the tool's blind spots come from, and the README is candid about two of them: some stacks need advanced probing so dynamically loaded components are detected, which is what the --http-probe* flags are for, and files the analysis cannot see need --include-path, with a cited case of a python SPA image where the client-side template files are included explicitly.

So the quality of the result depends on your application doing something observable while it is watched.

HTTP probing is on by default, and it makes your build talk to the network

The default behaviour is to interact with your application over HTTP, and the README's instruction is blunt: enable HTTP probing unless it gets in your way. The reason given is that some web applications built with scripting languages like Python or Ruby require service interactions to load everything in the application.

Probe commands are yours to define through the --http-probe* flags, and the container can be driven with --exec or --exec-file as well. The README's own example does exactly that, disabling probing and supplying the one command the image needs.

>> docker pull archlinux:latest
...

>> slim build --target archlinux:latest --tag archlinux:curl --http-probe=false --exec "curl checkip.amazonaws.com"
...

>> docker run archlinux:curl curl checkip.amazonaws.com
...

>> docker images
archlinux                 curl                ...        ...         17.4MB
archlinux                 latest              ...        ...         467MB
...

Two consequences for a build agent. Your image's code runs during the build, and in that example it reaches checkip.amazonaws.com, so the machine doing your build makes an outbound request. When the app exposes web interfaces you also get port mapping messages, and an internal port 8000 arriving as 32911 on the host is what the port.list and target.port.info lines show.

The build pauses and waits for you unless you pass --continue-after

Running the build or profile command gives you a chance to interact with the temporary container, and the default is to stop and wait for your input before continuing. That is the behaviour behind the interactive CLI prompt, and the screencasts linked from the README exist to show it.

One flag changes it: --continue-after. It decides both whether the run pauses and where your own tests fit. The README suggests using your app or environment tests when you run Slim, and points at the same flag for integrating them with the temporary container created during dynamic analysis. Running tests inside the target container is the alternative, and that one costs you a custom ENTRYPOINT or CMD with a wrapper that starts your app and then runs the tests.

For CI this is the difference between a pipeline that completes and a pipeline that hangs on a container waiting for a keypress. The second option, testing in the target container, is the heavier one: you are maintaining a wrapper entrypoint purely so the build can verify itself.

The 30x figure and the 467MB example are the project's own claims

The repository description says the tool minifies an image by up to 30x without changing anything in it, and a linked screencast is described as showing an image minified by more than 30x. Treat those as the project's numbers. Nothing here measures your image for you, and no independent figure accompanies them.

The worked example in the README is more informative than the headline. archlinux:latest appears at 467MB and the rebuilt archlinux:curl at 17.4MB, and the reason is visible in the command: probing is turned off and the single command the image is judged on is passed with --exec. In other words, the example works by telling the tool in advance what it needs, which is precisely the knowledge the analysis is supposed to discover on its own.

That is the honest way to read the whole project. It works best on images whose real dependency set is narrow and discoverable, which is what the curl image is.

go 1.24 with dependencies from three different eras

go.mod declares go 1.24.0, and the dependency list mixes generations. The container plumbing sits at github.com/docker/docker v25.0.6+incompatible with go-connections v0.4.0, and go-containerregistry is at v0.19.0, while the image specification itself is pinned to the release candidate opencontainers/image-spec v1.1.0-rc5.

The Kubernetes side is older. k8s.io/api, k8s.io/apimachinery, k8s.io/cli-runtime and k8s.io/client-go are all at v0.27.3, which is the 1.27 generation of those libraries and several years behind the Go directive that compiles them. Two consequences follow for a tool whose entire job is reading images. The dependency set is vendored into a vendor/ directory at the repository root, so a build uses those copies rather than resolving anything itself. And if you push image formats newer than the spec revision here, you are asking a parser to cope with a format version its dependency graph predates.

make builds inside Docker, and the end to end targets live in another file

The Makefile's first target is not a Go build. The default is build_in_docker, whose own comment says it builds docker-slim in docker, and its two recipe lines remove the bin directory with rm -rfv bin and then run scripts/docker-builder.run.sh.

Every target except help delegates to a script under scripts/, from the containerised builder to the quick development build, the formatter, the inspect step, the tool installer and the test runner, which exports GO_TEST_FLAGS before calling src.test.sh. There are separate build_m1 targets running a distinct builder script, so Apple Silicon is a maintained path rather than an accident.

The part worth knowing is the include line near the end of the Makefile, which pulls in test/e2e-tests.mk. The end to end targets live in that file rather than in the Makefile itself.

The newest tag is 1.40.11 from February 2024, and master is still moving

Here is the gap that matters when you decide how to install. The release list shows 1.40.9 on 2024-01-15, 1.40.10 on 2024-01-22 and 1.40.11 on 2024-02-02. The last push to this repository was on 2026-09-19, and it is not archived.

So work has continued on master for two and a half years after the newest tag. Anything that installs by tag, by release asset or by a versioned image gets code from February 2024, while the README on master describes a CNCF Sandbox project with GOVERNANCE.md and MAINTAINERS.md at the root, which is not the shape of a dormant repository.

There is also a self-update dependency, slimtoolkit/go-update, which tells you the project expects the binary to be able to update itself.

Slim rebuilds the image, Root.io patches the one you already ship

The README spends a paragraph on a partnership, and it is the closest thing here to an alternative. Kyle Quest created the project, it is now a CNCF Sandbox project, and the support is described as coming from Root.io, formerly Slim.AI. The stated division of labour is that Slim's open source toolkit optimizes containers while Root.io automatically fixes vulnerabilities without disrupting workflows, and readers are pointed to root.io for the commercial half.

The difference in approach is real and worth stating plainly. Slim acts at build time and produces a different artefact by removing what the application does not need, which also shrinks the attack surface. Root.io acts on what you already run, continuously, which addresses vulnerabilities that appear after the image shipped. Those are different problems on different timelines, not competing implementations of one.

Slim does carry its own vulnerability command in the command list. The README's overview draws no line between what that command reports and what Root.io remediates, so if your decision depends on that boundary, check further before relying on either.

Editorial conclusion

SlimToolkit fits a team shipping an image whose runtime weight is dominated by things the application never loads, and that can afford to execute that image during the build. It does not fit a pipeline that cannot run the artefact at build time, or that installs strictly by release tag, because the newest entry in the release list is 1.40.11 from 2024-02-02 while pushes continue on master. Verify first which flags your build passes, since whether HTTP probing stays on and whether --continue-after is set decide most of what happens next.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. slimtoolkit/slim on GitHub