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
Terminal
# 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-certificates
Options
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.
Frequently asked questions
buildah from: Start a Working Container?
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.
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.
