buildah from: Start a Working Container
buildah from creates a writable working container from a base image (or from scratch) that you then modify with buildah run, copy, and config.
Beyond Dockerfiles, buildah can build images imperatively. buildah from opens a working container you shape step by step, ideal for minimal or scripted images.
What it does
buildah from pulls a base image and creates a working container, printing its name. You then run commands, copy files, and set config on that container with other buildah subcommands, and finally buildah commit it into an image. buildah from scratch starts from an empty image.
Common usage
# build a minimal image imperatively
ctr=$(buildah from scratch)
buildah copy "$ctr" ./dist/app /app
buildah config --entrypoint '["/app"]' "$ctr"
buildah commit "$ctr" ghcr.io/acme/app:1.4.0
# start from a real base
ctr=$(buildah from alpine:3.20)
buildah run "$ctr" -- apk add --no-cache ca-certificatesOptions
| Flag | What it does |
|---|---|
| IMAGE | Base image, or "scratch" for an empty image (positional) |
| --name <name> | Name the working container instead of auto-generating |
| --pull / --pull-always | Control whether the base is pulled |
| --platform os/arch | Base image platform |
In CI
The from scratch flow builds ultra-minimal images (a single static binary plus CA certs) with no Dockerfile, fully scriptable and daemonless. Capture the container name from stdout and pass it to the later buildah run/copy/commit steps.
Common errors in CI
"error creating build container ... insufficient UIDs or GIDs ... in user namespace" is the rootless subuid/subgid setup issue. "unable to pull image" means the base reference or registry auth is wrong. Committing to a remote tag without a login fails with "unauthorized"; run buildah login first.