BMbmgoau·Sep 5, 2025
First result on Google, 22k stars https://github.com/slimtoolkit/slim
In I ditched Docker for Podmanslimtoolkit
slim
Go2015–2025
slimtoolkit / slim
slim
Slim(toolkit): Don't change anything in your container image and minify it by up to 30x (and for compiled languages even more) making it secure too! (free and open source)
21Distinct people
25Mentions
0Explicit recommenders
23.5KGitHub stars
What to know before exploring
What it is
Slim(toolkit): Don't change anything in your container image and minify it by up to 30x (and for compiled languages even more) making it secure too! (free and open source)
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year25 dated mentions
Observed mentions: 2015-10-03 17:36:23 UTC to 2025-09-05 19:51:22 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 7 | 2 | 5 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
25 sourcesMaybe this would help in that regard: https://github.com/docker-slim/docker-slim
In I deleted 78% of my Redis container and it still worksSlim.AI | Fullstack and Backend Engineers | REMOTE, international or Seattle/Bellevue/WA | Full-time | Golang, Node.js, Vue.js/Nuxt.js
I'm the founder and CTO at Slim.AI. I created DockerSlim as a hackathon project and it turned into a journey to redefine how DevOps is done for devs building cloudnative apps. We are still early stage, but we are fortunate enough to have 40M+ to support our mission.
Our engineering team is the innovation engine for our product because we are building a solution to solve our own problems creating and running containerized cloud-native applications.
We use Golang, Node.js Serverless/Lambda and containers. We have technical writer, frontend, backend and fullstack roles ( https://github.com/slim-ai/engineering ).
Our Interview Process:
We don't do Leetcode or the usual trivia-based puzzles and whiteboarding in
Read the rest
terviews. We customize the interview process based on the candidates and their background to make sure we get to learn as much possible and to see how working together can be mutually beneficial.
Our Engineering Principles:
* We use what we build.
* We share a common cloud-native mindset and a platform thinking DNA.
* We create stage appropriate designs that can evolve and that can be thrown away when necessary.
* We optimize for evolvable architecture building an extensible and composable system with disposable components using an API first approach.
* We optimize our designs for people first and machines second.
* We care about the entire system we are building considering the needs of our teammates and the impact of the design decisions we make.
* We learn together.
* We share knowledge and give back to the tech community.
* We have a written down and transparent culture that enables our remote first asynchronous approach to engineering.
* We have a lightweight engineering process based on trust, self-alignment and visibility.
Email me at cto@slim.ai if you'd like to learn more.
P.S.
Take a look at DockerSlim ( https://github.com/docker-slim/docker-slim ) if you are interested in working on the open source project that powers our SaaS.
Docker Image/Container Optimizer
1 points · Open discussionIn my experience docker-slim[0] is the way to go for creating minimal and secure Docker images.
I wasted a lot of time in the past trying to ship with Alpine base images and statically compiling complicated software. All the performance, compatibility, package availability headaches this brings is not worth it when docker-slim does a better job of removing OS from your images while letting you use any base image you want.
Tradeoff is that you give up image layering to some extent and it might take a while to get dead-file-elimination exactly right if your software loads a lot of files dynamically (you can instruct docker-slim to include certain paths and probe your executable during build).
If docker-slim is not your thing, “distroless” base images [1] are also pretty good. You can do your build with the same distro and then in a multi st
Read the rest
age docker image copy the artifacts into distroless base images.
[0] https://github.com/docker-slim/docker-slim
[1] https://github.com/GoogleContainerTools/distroless
Slim.AI | Technical Writer and Fullstack/Backend Engineers | REMOTE, international or Seattle/Bellevue/WA | Full-time | Golang, Node.js, Vue.js/Nuxt.js
I'm the founder and CTO at Slim.AI. I created DockerSlim as a hackathon project and it turned into a journey to redefine how DevOps is done for devs building cloudnative apps. We are still early stage, but we are fortunate enough to have 40M+ to support our mission.
Right now we are focusing on simplifying and accelerating the containerized app delivery (it's too hard, too complicated and with too much manual work). We are about to transition to the next phase and we are expanding our engineering team.
Our engineering team is the innovation engine for our product because we are building a solution to solve our own problems creating and running containerized cloud-native applications.
We us
Read the rest
e Golang, Node.js Serverless/Lambda and containers. We have technical writer, frontend, backend and fullstack roles ( https://github.com/slim-ai/engineering ).
Our engineering principles:
* We use what we build.
* We share a common cloud-native mindset and a platform thinking DNA.
* We create stage appropriate designs that can evolve and that can be thrown away when necessary.
* We optimize for evolvable architecture building an extensible and composable system with disposable components using an API first approach.
* We optimize our designs for people first and machines second.
* We care about the entire system we are building considering the needs of our teammates and the impact of the design decisions we make.
* We learn together.
* We share knowledge and give back to the tech community.
* We have a written down and transparent culture that enables our remote first asynchronous approach to engineering.
* We have a lightweight engineering process based on trust, self-alignment and visibility.
Email me at cto@slim.ai if you'd like to learn more.
P.S.
Take a look at DockerSlim ( https://github.com/docker-slim/docker-slim ) if you are interested in working on the open source project that powers our SaaS.
Nobody mentioned https://github.com/docker-slim/docker-slim yet.
So here it is.
In Optimizing Docker image size and why it mattersSlim.AI | Fullstack and Backend Engineers | REMOTE, international or Seattle/Bellevue/WA | Full-time | Golang, Node.js, Vue.js/Nuxt.js
I'm the founder and CTO at Slim.AI. We are a well funded seed stage startup (9M+) in the developer tooling space. Our mission is to simplify and accelerate the containerized app delivery (it's too hard, too complicated and with too much manual work). We are about to transition to the next phase and we are expanding our engineering team.
Our engineering team is the innovation engine for our product because we are building a solution to solve our own problems creating and running containerized cloud-native applications.
We use Golang, Node.js Serverless/Lambda and containers. We have frontend, backend and fullstack roles ( https://github.com/slim-ai/engineering ).
Our engineering principles:
* We use what we
Read the rest
build.
* We share a common cloud-native mindset and a platform thinking DNA.
* We create stage appropriate designs that can evolve and that can be thrown away when necessary.
* We optimize for evolvable architecture building an extensible and composable system with disposable components using an API first approach.
* We optimize our designs for people first and machines second.
* We care about the entire system we are building considering the needs of our teammates and the impact of the design decisions we make.
* We learn together.
* We share knowledge and give back to the tech community.
* We have a written down and transparent culture that enables our remote first asynchronous approach to engineering.
* We have a lightweight engineering process based on trust, self-alignment and visibility.
Email me at cto@slim.ai if you'd like to learn more.
P.S.
Take a look at DockerSlim ( https://github.com/docker-slim/docker-slim ) if you are interested in working on the open source project that powers our SaaS.
May I suggest you look into grype[0], or some other similar tool? It can be used to scan images for vulnerabilities. You'll probably find a bunch of vulnerabilities that aren't likely to actually affect you, but still, at least you'll know they're in the images you're running. And maybe you'll start using things like docker-slim[1] on your own images to get rid of those vulnerabilities you do find.
[0]: https://github.com/anchore/grype
[1]: https://github.com/docker-slim/docker-slim
In Log4jscannerSlim.AI | Backend and Fullstack Engineers | REMOTE, international or Seattle/Bellevue/WA | Full-time | https://github.com/slim-ai/engineering
We are a well funded seed stage startup (9M+) in the developer tooling space on a mission to redefine how DevOps is done for containerized apps (it's too hard, too complicated and with too much manual work). We are about to transition to the next phase and we are expanding our engineering team.
Our engineering team is the innovation engine for our product because we are building a solution to solve our own problems creating and running containerized cloud-native applications.
We use Golang, Node.js Serverless/Lambda and containers. Take a look at the backend ( https://github.com/slim-ai/engineering/blob/master/roles/bac... ) and fullstack ( https://github.com/slim-ai/engineering/blob/master/roles/fu
Read the rest
l... ) roles and our engineering principles to see if the role and how we do engineering looks interesting to you ( https://github.com/slim-ai/engineering#engineering-principle... ).
Email me at cto@slim.ai if you'd like to learn more.
P.S.
And take a look at DockerSlim ( https://github.com/docker-slim/docker-slim ) if you are interested in working on the open source project that powers our SaaS.
Slim.AI | Backend Engineer | REMOTE or Seattle/Bellevue/WA | Full-time | https://github.com/slim-ai/engineering/blob/master/roles/bac...
Our mission is to empower developers to create and deliver container-based cloud-native applications. You should spend more time building your application and less time fighting containers :-)
We use Go, serverless and containers. Take a look at the backend role description ( https://github.com/slim-ai/engineering/blob/master/roles/bac... ) and our engineering principles to see if the role and how we do engineering looks interesting to you ( https://github.com/slim-ai/engineering#engineering-principle... ).
Email me at cto@slim.ai if you'd like to learn more.
P.S.
You'll also get to work on DockerSlim ( https://github.com/docker-slim/docker-slim ) if you are interested in improving the core engine and if
Read the rest
you want contributing to open source to be your day job :-)
Much more information is available from their GitHub page at https://github.com/docker-slim/docker-slim
In Docker-slim: Minify and Secure Docker containers up to 30xMaybe give this a try: https://github.com/docker-slim/docker-slim
In Slimium: Debloating the Chromium Browser with Feature Subsettingbeen using docker-slim[1] for a couple years and am really happy with it.
Also I build everything from source and try to avoid glibc wherever I can, use hardened malloc and -D_FORTIFY_SOURCE=2 everything. also use static linking wherever I can and try to --disable-foo with configure if I can get away with it. Using a minimalistic approach that restricts everything (down to a syscall whitelist) sounds like it's high maintenence but when done in combination with a catalog of what runs in these containers and some plumbing to poll upstream for repo updates allows me to ignore a lot of what affects most people wrt security. As a bonus I learn about it quickly if upstream introduces a major change and I'm forced to study the source and get to decide if they were "out of their mind again" with these changes.
Keeps me abreast of how my platform
Read the rest
behaves and when it doesn't as it should (it's kind of a forward investment for efficient root cause analysis that beats "have you tried turning it off and on again")
Docker imo doesn't deserve the hype. Most of the flaws I deal with in my setup are due to docker instability (often in docker swarm) ... it's the next thing I actually want to replace because it's just overhyped "static linking for Millennials".
[1] https://github.com/docker-slim/docker-slim
use a docker sidecar, in fact explained in the docker-slim repo:
https://github.com/docker-slim/docker-slim#debugging-minifie...
In Docker-slim: Minify your Docker container image without changing anythingShowing the 15 most recent of 25 sources. Enable JavaScript to search and browse every indexed mention.