NOnomad41·Dec 26, 2021Submission
Toolbox: Tool for containerized command line environments on Linux
26 points · Open discussioncontainers
toolbox
Go2018–2026
containers / toolbox
toolbox
Tool for interactive command line environments on Linux
27Distinct people
30Mentions
0Explicit recommenders
3.5KGitHub stars
What to know before exploring
What it is
Tool for interactive command line environments on Linux
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
- 89luca89/distrobox · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:02:44 AM 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 year30 dated mentions
Observed mentions: 2018-12-13 18:49:07 UTC to 2026-10-06 10:54:23 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
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 | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 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 | 6 | 0 | 6 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
9 sourcesIf by "toolboxes" you mean the original "CoreOS Toolbox" (https://github.com/coreos/toolbox) which was originally a bash script, now re-written in Go (https://github.com/containers/toolbox) that's very, very unfortunate.
It should just be a user configuration.
In the original we defaulted to the latest Fedora image (yes, even in the days of CoreOS... blame me for that), but allowed the user to override this with an environment variable (and later a `.toolboxrc` file in their home directory). Thus, IMHO, this is a regression.
Now it seems the new stewards are trying to be "clever" and protect you from yourself, creating "foot-guns" in the process.
According to the docs (https://github.com/containers/toolbox#image-requirements):
Since Toolbox only works with OCI images that fulfill certain requirements, it will refuse images that ar
Read the rest
en't tagged with com.github.containers.toolbox="true" and com.github.debarshiray.toolbox="true" labels. These labels are meant to be used by the maintainer of the image to indicate that they have read this document and tested that the image works with Toolbox. You can use the following snippet in a Dockerfile for this:
LABEL com.github.containers.toolbox="true"
edit: I forgot part of my point: This is a regression from the original utility.
It's pretty easy to create one yourself (from an open MR https://github.com/containers/toolbox/pull/483/files#diff-21...), but it would have been nice to have out of the box.
I've used buildah to set up a C/C++ dev environment in a Ubuntu toolbox at work without any major issues.
In Podman: A tool for managing OCI containers and podsFrom a previous discussion:
One very interesting piece of tech coming from podman, is toolbox (https://github.com/containers/toolbox). Basically throwaway (or keeparound) rootless containers with their own root directory but shared HOME. Install hundreds of dev-dependencies to build this one piece of software? Yeah, not gonna install those packages permanently. Spin up a toolbox, build it, install it in my home/.local.
You have root in the container without having root in the host system. That takes care of a lot of issues as well.
I basically no longer have development packages installed and run some applications with lots of dependencies out of toolboxes.
In Podman: A tool for managing OCI containers and podsYou’ll probably want to install it in a Toolbox [1] container. This is the recommended way to set up development tools; you’ll generally want as little as possible layered on the OSTree file system.
1. https://github.com/containers/toolbox
In macOS Nix setup: an alternative to Homebrew (2020)There is a tool, Toolbox, for changing linux environments that could be helpful to test that.
https://github.com/containers/toolbox
In Rocky Linux 8.4 RC1Too bad Red Hat is going the opposite direction with their Toolbox container management project, sharing your entire home dir with every container but not explicitly documenting this:
https://github.com/containers/toolbox/issues/183
In Private Home Directories for Ubuntu 21.04I'm currently testing fedora silverblue, which uses toolbox in a roughly similar way. https://github.com/containers/toolbox
One thing that bugs me is that I can't (or don't know how) get my current state into a Textfile, from which I can reproduce.
It's also not fun for embedded development. Guess what, I need to access USB devices, serial, mass storage, hid - super annoying with this setup.
In Docker as an Integrated Development Environment (2019)One very interesting piece of tech coming from it, is toolbox (https://github.com/containers/toolbox). Basically throwaway (or keeparound) rootless containers with their own root directory but shared HOME. Install hundreds of dev-dependencies to build this one piece of software? Yeah, not gonna install those packages permanently. Spin up a toolbox, build it, install it in my home/.local.
You have root in the container without having root in the host system. That takes care of a lot of issues as well.
In Podman: A Daemonless Container Engine