Skip to content

Commit 240bc3d

Browse files
committed
feat: add container image caching documentation
1 parent a2dc71d commit 240bc3d

1 file changed

Lines changed: 76 additions & 0 deletions

File tree

Lines changed: 76 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,76 @@
1+
---
2+
title: Container Image Caching
3+
description: How Rover caches container images to speed up subsequent task runs.
4+
sidebar:
5+
order: 2
6+
---
7+
8+
Every time Rover runs a task, it starts a container and performs a setup phase — installing languages, package managers, the AI agent CLI, MCP servers, and running your init script. This setup can be slow, especially for projects with many dependencies.
9+
10+
Container image caching eliminates this overhead for repeated runs by saving the fully initialized container as a local image and reusing it for subsequent tasks that share the same setup configuration.
11+
12+
## How It Works
13+
14+
When a task starts, Rover computes a fingerprint of everything that affects the setup phase:
15+
16+
- Base agent image
17+
- Configured languages and package managers
18+
- AI agent (Claude, Gemini, etc.)
19+
- MCP server definitions
20+
- Init script contents
21+
- Rover version
22+
23+
If a cached image matching that fingerprint already exists locally, Rover starts the container directly from it, skipping the entire setup phase. If no match is found, Rover runs the setup phase in an init-only container, commits the result as a new cached image, and then starts the actual task container from it.
24+
25+
Any change to the setup inputs — such as adding a language, updating the init script, or upgrading Rover — produces a new fingerprint, so a fresh image will be created on the next run.
26+
27+
## Cache Invalidation
28+
29+
The cache is content-addressed: two projects with identical setup configurations will share the same cached image. Conversely, any change to the inputs automatically invalidates the old cache because it produces a different fingerprint.
30+
31+
You do not need to manually invalidate the cache in normal usage. Simply changing your project configuration or upgrading Rover is enough.
32+
33+
## Managing Cache Images
34+
35+
Over time, stale cache images can accumulate — for example, after upgrading Rover or changing your project configuration. The `rover cleanup` command helps manage them.
36+
37+
### Listing What Would Be Removed
38+
39+
Use `--dry-run` to preview the cleanup without deleting anything:
40+
41+
```bash
42+
rover cleanup --dry-run
43+
```
44+
45+
### Running Cleanup
46+
47+
```bash
48+
rover cleanup
49+
```
50+
51+
By default, cleanup keeps the most recent cache image per project and agent combination, and removes:
52+
53+
- **Stale images**: older images superseded by a newer one for the same project and agent
54+
- **Orphaned images**: images whose project no longer exists on disk or is no longer registered with Rover
55+
- **Legacy images**: images created before metadata labels were introduced
56+
57+
### Removing All Cache Images
58+
59+
To remove every cache image, including current ones:
60+
61+
```bash
62+
rover cleanup --all
63+
```
64+
65+
### JSON Output
66+
67+
For scripting and automation, use the `--json` flag:
68+
69+
```bash
70+
rover cleanup --json
71+
rover cleanup --dry-run --json
72+
```
73+
74+
## Container Backend Support
75+
76+
Image caching works identically with both Docker and Podman. Rover auto-detects which backend is available and uses the same caching mechanism for either one, including support for remote container daemons via `DOCKER_HOST`.

0 commit comments

Comments
 (0)