SlimToolkit: Container Minification Without Rewrites
SlimToolkit takes a container image you've already built and strips it down to the files your app actually touches at runtime, without a Dockerfile rewrite or a base image swap. That's a sharper approach than hand-trimming a Dockerfile because it watches real behavior instead of guessing from instructions, but it earns its keep only once you've tuned the HTTP probing and exec flags for your specific app.
Why Container Images Are Bloated and Insecure by Default
A typical container image ships with the full base OS: a package manager, shared libraries the app never calls, and often a shell, because trimming any of that by hand risks breaking the app at runtime. Most teams just don't bother. That leftover surface is exactly what attackers scan for. Locking it down properly means hand-writing Seccomp and AppArmor profiles, which requires knowing precisely which Linux syscalls your process needs — most developers never reverse-engineer their own app's syscall behavior just to ship a container, so images stay wide open by default.
What is it?
SlimToolkit is a free, open-source CLI (formerly DockerSlim) that inspects a running container, works out which files and libraries the application actually used, and rebuilds a minified version of the image from just that set. It ships as a single Go binary with commands like xray, build, debug, and lint, and it's now a CNCF Sandbox project maintained by its original creator and outside contributors.
Key features
- ✓`xray` performs static analysis on an image and reverse-engineers the Dockerfile that produced it, so you can see what's actually inside before touching anything.
- ✓`build` is described in the README as the main command — it analyzes, profiles, and optimizes an image in one pass, generating matching Seccomp and AppArmor profiles as it goes.
- ✓`lint` checks a Dockerfile's instructions against a set of rules (Docker image linting is still work in progress).
- ✓`debug` attaches to an already-minified or regular running container for troubleshooting, without needing to rebuild it.
- ✓`merge` combines two container images, and the README notes it's optimized specifically for merging already-minified images.
- ✓An interactive CLI prompt (built on go-prompt) starts automatically if you run `slim` with no command, with tab-completion for flags.
- ✓`appbom` prints an application bill of materials — the composition and dependencies of the analyzed app.
- ✓`registry` handles pull, push, copy, and server operations directly against a container registry.
Supported Languages and Base Images
- •Application languages the README lists as tested: Node.js, Python, Ruby, Java, Go, Rust, Elixir, and PHP (for some app types).
- •Base images: Ubuntu, Debian, CentOS, Alpine, and even Distroless images.
- •Compiled languages like Go see the largest gains — the README's own Go examples shrink further than any interpreted-language example it shows.
- •Apps with dynamically loaded modules (common in Python and Ruby) need extra `--http-probe` or `--include-path` tuning so the analysis doesn't miss files loaded outside the main request path.
Installing SlimToolkit
SlimToolkit ships as a single binary with no runtime dependencies beyond Docker itself. On macOS or Linux, the fastest path is the scripted installer: `curl -sL https://raw.githubusercontent.com/slimtoolkit/slim/master/scripts/install-slim.sh | sudo -E bash -`. Homebrew users can run `brew install docker-slim` (the formula keeps the old project name). There's also a Docker image, pulled with `docker pull dslim/slim`, and direct zip/tar.gz downloads for Mac, Mac M1, Linux, Linux ARM, and Linux ARM64 that you unzip and move the `slim` and `slim-sensor` binaries into your PATH yourself. If Slim is already installed, `slim update` fetches the latest release.
Building a Minified Container with Slim
The core workflow is `slim build --target <image>`, which analyzes the target image, runs it as a temporary container so Slim can watch what the app actually touches, and writes out a minified copy. By default the build pauses so you can interact with the temporary container (or point a browser at the port it prints), and you control that pause with `--continue-after`. HTTP probing is on by default to exercise any web endpoints automatically; a runnable example straight from the README shows the shape of it: `slim build --target archlinux:latest --tag archlinux:curl --http-probe=false --exec "curl checkip.amazonaws.com"` — which in that case produced a 17.4MB image from a 467MB base. For anything your test suite or a browser wouldn't naturally hit, `--include-path` and `--exec-file` let you point Slim at files or run scripts explicitly.
Pros of Using SlimToolkit
- ✓No Dockerfile changes required — you keep your existing base image, package manager, and build process exactly as they are.
- ✓Generates Seccomp and AppArmor profiles automatically instead of requiring you to hand-write them from syscall traces.
- ✓The `build` command's dynamic analysis catches what static Dockerfile analysis can't, because it watches the app actually run.
- ✓Apache-2.0 licensed and free, with a CNCF Sandbox governance model rather than a single vendor holding the keys.
- ✓Works across a wide spread of language runtimes (Node.js, Python, Ruby, Java, Go, Rust, Elixir, PHP) and base images (Ubuntu, Debian, CentOS, Alpine, Distroless).
Limitations and Known Issues
- △Dynamic analysis only sees what actually ran during the build — dynamically loaded modules in interpreted languages can get stripped out unless you tune `--http-probe` or `--include-path` first, and the README says so directly.
- △`lint`'s Docker image support is still work in progress per the README; it's solid for Dockerfiles but not yet a full image linter.
- △Debugging a minified image means running a separate side-car debug container, since the point of minifying is removing the shell and tools you'd normally debug with.
- △The build step needs a real Docker daemon to spin up and interact with a temporary container, so it adds a genuine step (and time) to CI, not just a static scan.
Alternatives to SlimToolkit
Frequently Asked Questions
SlimToolkit is free and open source, released under the Apache-2.0 license and developed as a CNCF Sandbox project with contributions from outside the original team.
SlimToolkit's README describes growing support for additional container tools and runtimes across the cloud native ecosystem, though it doesn't name specific runtimes beyond Docker — the CLI's `--host` and `--tls` flags configure the Docker connection SlimToolkit uses.
SlimToolkit relies on `--http-probe` flags to exercise an app's endpoints during analysis and on `--include-path` to explicitly pull in files a dynamic scan might miss, which the README recommends for stacks like Python or Ruby apps that load components dynamically.
SlimToolkit's `debug` command attaches to a running minified container for troubleshooting, and the README recommends a separate debugging side-car container rather than adding tools back into the minified image itself.
`slim build` analyzes, profiles, and optimizes an image and generates security profiles — the README calls it the commonly used command. `slim profile` runs the same dynamic analysis and produces a report but stops short of generating an optimized image.
SlimToolkit's documentation doesn't call out multi-stage builds specifically. It analyzes the final image you already have rather than the Dockerfile that produced it, so an image from a multi-stage build is just another target the same way any other built image would be.
Who should try it — and who should skip
Try it if you ship containerized Node.js, Python, Ruby, Java, Go, Rust, Elixir, or PHP apps and want smaller, more locked-down images without rewriting your Dockerfile or switching base images — the `build` command bolts onto an existing image and pipeline. Skip it, or budget extra setup time, if your CI can't run a full container build-and-probe step, or your app leans heavily on modules loaded outside the paths Slim's HTTP probing exercises by default; you'll spend real time in `--include-path` and `--http-probe` flags before the output is trustworthy.
Related repositories
Want a second opinion on slim?
Ask an AI that can read this page — one click and you get its take on slim.