wagoodman/dive · error
could not find Containerfile or Dockerfile
Error message
could not find Containerfile or Dockerfile
What it means
Returned by tryFindContainerfile (dive/image/docker/build.go:83) when no build argument resolves to a directory containing a known container recipe. The search is strict: for each arg that Stats as a directory it checks exactly Containerfile, containerfile, Dockerfile, dockerfile (filepath.Join'd onto that directory). No -f equivalent exists, and non-directory args are ignored entirely.
Source
Thrown at dive/image/docker/build.go:83
defaultContainerfileName, // Containerfile
strings.ToLower(defaultContainerfileName), // containerfile
defaultDockerfileName, // Dockerfile
strings.ToLower(defaultDockerfileName), // dockerfile
}
for _, arg := range buildArgs {
fileInfo, err := fs.Stat(arg)
if err == nil && fileInfo.IsDir() {
for _, candidate := range candidates {
filePath := filepath.Join(arg, candidate)
if exists, _ := afero.Exists(fs, filePath); exists {
return filePath, nil
}
}
}
}
return "", fmt.Errorf("could not find Containerfile or Dockerfile\n")
}
View on GitHub (pinned to d6c691947f)
Solutions
- cd into (or pass) the directory that directly contains Dockerfile or Containerfile - exact names only
- Rename or symlink your custom recipe to Dockerfile/Containerfile for the dive build step
- Prefer building with docker/podman directly and pointing dive at the result (dive docker://<image>) to avoid the file-discovery limitation
- Note -f/--file is not honored by this finder regardless of flags passed
Example fix
# before dive build-image --build -f Dockerfile.prod . # after cp Dockerfile.prod ./Dockerfile && dive build-image --build . # or: build externally, then analyze docker build -f Dockerfile.prod -t app:ci . && dive docker://app:ci
Defensive patterns
Strategy: validation
Validate before calling
// check for a discoverable recipe before invoking the build
candidates := []string{"Containerfile", "containerfile", "Dockerfile", "dockerfile"}
found := false
for _, c := range candidates {
if _, err := os.Stat(filepath.Join(ctxDir, c)); err == nil {
found = true
break
}
}
if !found {
return fmt.Errorf("no Containerfile/Dockerfile in %s; build externally instead", ctxDir)
} Try / catch
err := builder.Build(ctx, buildArgs)
if err != nil && strings.Contains(err.Error(), "could not find Containerfile or Dockerfile") {
// fall back to an explicit docker build + dive on the result
_ = run("docker", append([]string{"build", "-t", tag, ctxDir}, buildArgs...)...)
return diveImage("docker://" + tag)
} Prevention
- Name your recipe exactly Dockerfile or Containerfile at the context root
- Remember dive's finder ignores custom filenames (-f is not supported)
- Prefer building with docker/podman and analyzing the tagged image
When it happens
Trigger: Running dive --build with build args that name a file (e.g. 'dive --build -f Dockerfile.custom .') - files are never opened as recipes; pointing at a directory whose recipe has a custom name (Dockerfile.dev, docker/Dockerfile); an empty or misspelled build-context path.
Common situations: Monorepos where the Dockerfile lives in a parent dir or is renamed per-service; CI running dive from a different working directory than the build context; users expecting buildkit-style -f semantics from dive.
Related errors
- cannot build image: %w
- failed to set UI: %w
- exactly one argument is required
- cannot export analysis: %w
- unable to determine image source from %q: %v
AI-assisted analysis of wagoodman/dive@d6c691947f (2026-08-15).
Data as JSON: /api/errors/995ffa5ea7e090a3.
Report an issue: GitHub.