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

  1. cd into (or pass) the directory that directly contains Dockerfile or Containerfile - exact names only
  2. Rename or symlink your custom recipe to Dockerfile/Containerfile for the dive build step
  3. Prefer building with docker/podman directly and pointing dive at the result (dive docker://<image>) to avoid the file-discovery limitation
  4. 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

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


AI-assisted analysis of wagoodman/dive@d6c691947f (2026-08-15). Data as JSON: /api/errors/995ffa5ea7e090a3. Report an issue: GitHub.