baredevcontainer/mise repository overview

⁠mise

Dev container image with mise⁠ installed, built on the debian⁠ base image.

Like every image in this repository, it is minimal, built only from upstreams verified at build time, and published with SLSA provenance, a GitHub artifact attestation, and an SBOM; it runs as the non-root user dev. Why these images⁠ explains the reasoning, and Verifying the image⁠ below shows how to check a build.

mise is a polyglot runtime manager that can install and manage multiple language toolchains (Node.js, Python, Ruby, Go, etc.) per project.

⁠Image

ghcr.io/bare-devcontainer/mise:<tag>

Reference it from .devcontainer/devcontainer.json, pinning the digest as well as the tag:

{
  "image": "ghcr.io/bare-devcontainer/mise:trixie@sha256:<digest>"
}

⁠Dev Container Template

A ready-to-use Dev Container template for this image is available at bare-devcontainer/templates⁠. It provides the recommended configuration for this image, including security hardening and volume mounts that persist cache directories for faster rebuilds.

⁠Tags

Tags are also published with a date suffix on each build (e.g., 2026.9.14-trixie-<YYYYMMDD>).

⁠Installed software

Everything from the debian⁠ base image, plus:

• mise⁠

The shims directory ~/.local/share/mise/shims is on PATH under a Dev Container client, so tools resolve as soon as mise installs them. Running the image without one (docker run, a CI job's container:) leaves the directory off PATH.

⁠Not installed

• No language runtime. Nothing is installed until the project asks for it — that is the point of this image. mise resolves the versions declared in mise.toml (and the idiomatic per-language files such as .node-version or .python-version).
• No development headers beyond libc. The base image's build-essential covers the compiler and linker, so backends that download prebuilt binaries and simple source builds both work as-is. A backend that builds a language runtime from source additionally needs the -dev packages of the libraries it links against, such as libssl-dev or zlib1g-dev.

⁠Working with tools

mise install installs everything the project declares; mise exec <tool>@<version> -- <cmd> runs a one-off without declaring anything. To install the project's tools when the container is created rather than on first use, run mise install from a postCreateCommand.

Two directories are worth persisting across container rebuilds as volumes:

• ~/.local/share/mise — the installed tools. Everything is re-downloaded on every rebuild unless this directory survives.
• ~/.cache/mise — the download cache.

⁠Supply chain

The mise binary is downloaded from GitHub Releases⁠. Its checksum is verified against SHASUMS256.txt, whose minisign signature is verified against mise's public key (mise/mise-minisign.pub) before installation. The key is committed to this repository, so signatures are checked against a key reviewed here rather than one fetched at build time.

Note that this covers the mise binary only. Tools that mise installs at runtime are fetched from their own upstreams under mise's own verification, outside this image's build pipeline.

⁠Verifying the image

Every build is published with SLSA provenance, a GitHub artifact attestation, and an SBOM. The attestation confirms that an image was built by the release workflow of this repository and has not been altered since:

gh attestation verify oci://ghcr.io/bare-devcontainer/mise:<tag>@sha256:<digest> \
  --owner bare-devcontainer

The Docker Hub mirror carries the same digests, so the same command verifies an image pulled from docker.io/baredevcontainer/mise. Verifying Published Images⁠ covers inspecting the provenance and the SBOM as well.