Cache

Dagger cache follows the graph.

Same inputs, same work, same result: Dagger can reuse it.

Different inputs: Dagger reruns the affected work.

This is why module API design affects speed.

Inputs Matter

Precise inputs make precise cache keys.

Use narrow inputs:

• the package directory, not the whole repo
• the lock file, not every generated file
• the file being processed, not every file nearby
• the secret needed for one step, not hidden host credentials

Broad inputs make broad invalidation. If a lint function accepts the whole repo, a README change can rerun work that only needed source files.

Outputs Matter

Composable outputs help cache too.

Return a Container, Directory, File, or object when the caller may keep building. Let the caller decide when to materialize.

Materialize only when the function is meant to produce a final result.

Cache Volumes

Cache volumes are for tool caches:

• package downloads
• compiler caches
• dependency stores
• other mutable acceleration data

They are not source of truth. A module must still be correct with an empty cache.

Cloud Cache

Local and CI caches are often separate. Dagger Cloud can share cache across environments.

Do not depend on a warm cache. Design for correctness first, speed second.

Design Check

Ask:

• Does each function accept the smallest meaningful Directory or File?
• Are tool versions pinned?
• Are generated files excluded unless needed?
• Does the function return a composable value?
• Can the caller understand why work reran?

Next: Execution.