SlimToolkit (slim): minify container images without rewriting your Dockerfile

What SlimToolkit removes, and who ends up using it

The README frames the problem as one of workflow cost. Hand-optimizing a Dockerfile means switching base images, rebuilding on a different package manager, and re-testing everything. SlimToolkit takes the opposite route: keep the image you already build, and let a separate tool figure out which parts of it the application never reads. The project claims minification of up to 30x, and the README says the reduction is larger for compiled languages.

The audience is broad on purpose. The README lists Node.js, Python, Ruby, Java, Go, Rust, Elixir and PHP (some app types) as tested stacks, running on Ubuntu, Debian, CentOS, Alpine and Distroless. That list matters because the tool's usefulness tracks how much of the filesystem the application touches at runtime. A statically linked Go binary that opens two files is an easy case. A Python service that imports plugins based on a database row is not.

SlimToolkit is also a CNCF Sandbox project, created by Kyle Quest and now supported by Root.io, which the README describes as a separate commercial product for vulnerability remediation. The toolkit itself is free and open source. Nothing in the README makes the hosted service a requirement for using the CLI.

How the dynamic analysis and image rebuild actually work

The mechanism is behavioural observation, not static dependency resolution. When you run `build` or `profile`, SlimToolkit starts a temporary container from your target image and watches what the application does. According to the README, it pauses by default and waits for your input before continuing, so you can interact with the container while it is being profiled. The `--continue-after` flag changes that behaviour, and the README suggests using it to run your own application or environment tests inside the temporary container.

HTTP probing is on by default. If the application exposes a web interface, SlimToolkit talks to it for you. The README notes that the host ports are printed in the `port.list` and `target.port.info` messages, and gives the example of an internal port 8000 mapped to 32911 on the host. For scripting languages, the README says service interactions are often required before everything in the application loads, which is why HTTP probing is enabled unless it gets in the way.

What comes out is a new image containing only the files the observation touched, plus generated Seccomp and AppArmor profiles derived from the syscalls the application made. The README is explicit that you should not have to become an expert in Linux syscalls to get secure containers, and that reverse engineering application behaviour by hand is time-consuming. The generated profiles are the part of the output that has nothing to do with image size, and for many teams it is the more interesting half.

Installing slim and running a first minify

The README points to the installation section of the repository rather than listing package commands inline. The Makefile builds the project itself: `make build` runs `scripts/src.build.sh`, `make build_dev` produces a quick development build in `bin/`, and `make build_in_docker` builds inside Docker. The module is `github.com/slimtoolkit/slim` and it requires Go 1.24.0 or newer according to `go.mod`. There is a Gitpod badge in the README, so a browser-based environment is one documented path.

Once `slim` is on your PATH, the smallest useful run is a build against an existing image. This is the shape the README uses in its own example, with a different target:

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

Here `--target` is the image to analyze, `--tag` is the name for the new minified image, `--http-probe=false` disables the default HTTP probe because there is no web server, and `--exec` runs a command inside the temporary container so the profiler can see what that command needs. The README then runs the result directly:

docker run archlinux:curl curl checkip.amazonaws.com

If the command still works, the minified image kept what curl needed. If it fails, the profiler missed a file, and the fix is usually to widen the observation rather than to inspect the image by hand.

When part of the application is loaded only under specific conditions, the README points at `--include-path` to force files into the result. It cites an example where client-side template files had to be included explicitly. For stacks that load components dynamically, the `--http-probe*` flags let you define custom probe commands so the profiler sees more of the application's real behaviour.

The failure mode is a probe that does not exercise the app

Everything SlimToolkit keeps is something it saw being used. That is the whole design, and it is also the weakness. If a code path only runs during a monthly batch job, a failed health check, or an error handler that fires once a week, the profiler has no reason to keep the files behind it. The minified image will start, pass a smoke test, and break later.

The README acknowledges this indirectly. It recommends running your app and environment tests against the temporary container via `--continue-after`, and it warns that some application stacks require advanced container probing to detect dynamically loaded components. Both statements are admissions that observation coverage determines correctness. A team that runs `slim build` with default settings against a complex application and ships the result without a test pass is taking a real risk.

The second limitation is interaction. The default behaviour pauses and waits for you, which is fine at a terminal and awkward in CI. You can move past it with `--continue-after`, but then you have to supply the traffic or the test run yourself, and the quality of the minified image is only as good as that supply. There is also a debugging cost after the fact: the README's answer is dedicated debugging side-car containers, which means the minified image is not the image you debug in. If your workflow depends on execing into production containers with a full toolchain, minification removes exactly the tools you rely on.

SlimToolkit versus switching to Alpine or Distroless

The common alternative is not another minifier. It is changing the base image, usually to Alpine or Distroless, and rebuilding the application on top of it. People search for that comparison directly, and the difference in approach is worth being precise about.

Moving to Alpine or Distroless is a build-time decision. You choose a smaller base, install fewer packages, and the resulting image is reproducible from the Dockerfile alone. The cost is that you may have to change the package manager, deal with musl versus glibc differences, and re-verify the application. The README's pitch is aimed squarely at that cost: use the base image you want, use the package manager you want, and do not hand-optimize the Dockerfile.

SlimToolkit instead derives the image from observed runtime behaviour. The result is not reproducible from a Dockerfile; it is reproducible from the same probe run against the same input image. That is a meaningful difference for audit and rebuild workflows. A base-image swap gives you a recipe. SlimToolkit gives you an artifact plus the analysis that produced it. Teams that need to explain exactly why a file is in an image will find the second model harder to work with, even when the size numbers are better.

Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-19. The most recent release listed is 1.40.11 from 2024-02-02, described as improved xray and build with new Docker Engine version support, followed by 1.40.10 and 1.40.9 in January 2024. There is a visible gap between the release tags and the commit activity, so anyone pinning a version should check the changelog rather than assuming a tag tracks the current state of `master`.

Upgrade cost is mostly tied to Docker Engine compatibility. Release 1.40.11 explicitly mentions new Docker Engine version support, and `go.mod` pins `github.com/docker/docker v25.0.6+incompatible`. The tool talks to the Docker daemon and to Kubernetes APIs (`k8s.io/client-go v0.27.3`), so a daemon upgrade is the event most likely to force a SlimToolkit upgrade. Building from source also means tracking the Go toolchain: `go.mod` requires Go 1.24.0.

The licence is Apache-2.0, which is permissive and includes an explicit patent grant. That is a normal choice for infrastructure tooling and generally compatible with commercial use. This is not legal advice; if you redistribute a modified `slim` binary, read the LICENSE file and the NOTICE requirements yourself. The generated Seccomp and AppArmor profiles are outputs of your own analysis and are not covered by the project's licence in any way the repository states.

Editorial conclusion

Adopt SlimToolkit when you already have a working image and a repeatable way to exercise the application, and you want the size and attack-surface reduction without touching the Dockerfile. Skip it when the application loads code only in response to rare events, or when you cannot run the app under a probe at all, because the minified image is built from what the probe observed. Before trusting a minified image, run your own test suite against it, check the generated Seccomp and AppArmor profiles, and confirm the files you know the app needs are still present.

Frequently asked questions

Official sources

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