Is Scalingo Buildpack Cache Invalidate When Dependency Changes?

Answer

Scalingo does **not** automatically invalidate or refresh its per‑application buildpack cache when you edit a dependency manifest (Gemfile, package.json, Pipfile, etc.). The cache persists until you manually clear it via the CLI or dashboard.

Confirmed facts

• The Scalingo CLI provides only a scalingo cache:clear subcommand; there is no TTL setting or disable‑cache flag.
• Documentation states that the cache is retained across builds and is cleared only by user action.

Likely explanation

When a manifest changes but the corresponding lock file (e.g., Gemfile.lock, package-lock.json, Pipfile.lock) stays the same, many buildpacks treat the change as a non‑version bump and reuse previously downloaded or compiled layers. Consequently, the cached buildpack may continue to serve the old artifact.

Steps to verify the behavior

1. Make a commit that updates a manifest file but leaves the lock file unchanged.
2. Trigger a new build (e.g., scalingo deploy) and note the build duration and any output indicating dependency installation.
3. Clear the cache: scalingo cache:clear.
4. Repeat the build and compare the duration and output; a longer build and fresh dependency fetch indicate that the cache was previously serving stale layers.

Missing diagnostic detail

To decide whether a manual cache clear is required, we need to know: Did the lock file change along with the manifest? If the lock file changed, the buildpack may already trigger a fresh dependency resolution; if it did not, a manual clear is the reliable way to avoid stale artifacts.