MNmnming·Jun 8, 2024Submission
Img: Standalone, daemon-less, unprivileged Docker and OCI image builder
2 points · Open discussiongenuinetools
img
Go2018–2024
genuinetools / img
img
Standalone, daemon-less, unprivileged Dockerfile and OCI compatible container image builder.
9Distinct people
9Mentions
0Explicit recommenders
4KGitHub stars
What to know before exploring
What it is
Standalone, daemon-less, unprivileged Dockerfile and OCI compatible container image builder.
GitHub
Where it is used
No documented product use has been verified yet.
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, 3:03:16 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 year9 dated mentions
Observed mentions: 2018-04-29 23:03:46 UTC to 2024-06-08 10:17:31 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 |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 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 | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 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 | 1 | 1 | 0 |
What Hacker News says
9 sourcesDoes this solve a similar problem to img[0]?
[0] https://github.com/genuinetools/img
In Show HN: Build and push container images without Docker Daemon based on BuildKitBuild img from source is an option for mac osx.
https://github.com/genuinetools/img
A few rootless feature may not work. But as root i haven't seen problems so far.
In Ignoring Docker updates is a paid feature now?and yes, people have proven that it's possible to build something like podman or buildah on top of containerd / buildkit! No need to reinvent the wheel!
https://github.com/rancher/k3c
https://github.com/genuinetools/img
In Transitioning from Docker to PodmanWe're using img [1] with a helper script. The helper script runs a pod in the (potentially) remote Kubernetes cluster that takes the container build context as stdin, then runs img to build the image, and then imports it into the host's containerd instance. It also maps in the right host volumes so that the image build is cached between subsequent runs.
I was surprised to be unable to otherwise find a good local / remote container development workflow, but this was built to replace what we were previously doing, which is setting DOCKER_HOST to point to the remote (single-node) cluster's Docker daemon (over SSH), so that docker CLI commands would execute on that remote box.
In both cases, you'll still want to take steps to minimize the size of your container image build context, but the size of the images doesn't matter. I'm not sure if it
Read the rest
'd fit your needs or not, though.
[1] https://github.com/genuinetools/img
Img: Standalone, daemon-less, unprivileged Dockerfile/container image builder
3 points · Open discussionI don't think that's very verbose. The dockerfile I was using to build the app basically grabbed a specific version of all the deps and ./configure && make install'ed each one.
I'm completely onboard with the idea of reproducible builds.
> The thing is docker is huge and bloated; is far from secure, and will probably stay that way for the foreseeable future
It would be a mistake to fully associate container workflows with docker itself.
https://github.com/genuinetools/img + https://github.com/opencontainers/runc can be used to provide almost the same workflow as docker, without using docker itself.
You could also use the '-f docker' option the post talks about with runc to run the resulting image in an unprivileged container.
In Tarballs, the ultimate container image formatA PoC was shown of how to do this with buildkit several weeks ago in [0], but in your words - it's also not for the faint of heart (involving patching the Kernel). This is the way of the future - Docker image builds should not need to be privileged (they often are for mounting filesystems)
https://github.com/genuinetools/img [0]
Similar: https://github.com/AkihiroSuda/runrootless
In Unprivileged Docker Builds – A Proof of Concept