Build Cache

Stop Reinstalling Dependencies
on Every Deploy

DeployHQ caches your build dependencies between deploys and only refreshes them when lock files change. Cold builds drop from minutes to seconds — without any config gymnastics.

Lock-file-aware invalidation
Works for npm, yarn, composer, pip, bundler
On by default — no setup required

Last updated on 22nd June 2026

Build Time
Cold build (no cache)
4m 12s
Cached build
0m 18s
Lock file unchanged
✓ Restored
Net speed-up
−94%

Build Cache stores your project's dependency directories — node_modules, vendor, .bundle, and any custom path you define — between deploys. DeployHQ tracks lock-file fingerprints, restores the cache automatically when nothing changed, and refreshes it only when a dependency moves. The net effect: most builds finish in seconds.

The Problem with Cold Builds Every Deploy

Installing dependencies from scratch dominates CI time — even when nothing about them has changed.

EVERY DEPLOY npm install · 3m 48s composer install · 1m 12s bundle install · 38s Lock files unchanged ⚠ Wasted minutes PER WEEK ❌ Hours of CI ❌ Slower releases ❌ Higher build cost

A 5-minute cold install on every push adds up fast — and slow deploys quietly discourage shipping small changes.

Build Cache — Reuse What Hasn't Changed

Lock-file-aware caching restores dependencies in seconds and only rebuilds what's actually new.

LOCK FILES package-lock.json composer.lock Gemfile.lock fingerprint = a3f12c… BUILD CACHE ✓ Fingerprint match → restore node_modules · vendor · .bundle Custom paths welcome ⚡ Isolated, per-project 18 SECONDS ✓ Deps restored ✓ Build runs ✓ Deploy ships

How It Works

Caching that's smart by default — and configurable when you need it.

1
Folder icon

Define Cache Paths

Pick the directories to preserve. Sensible defaults cover node_modules, vendor, .bundle and friends — add custom paths anytime.

2
Text icon

Tie to Lock Files

Each cache entry is fingerprinted against the lock files that produced it. No drift, no stale dependencies in production.

3
Zap icon

Restore Automatically

When fingerprints match, DeployHQ restores the cache into the isolated build container before any build command runs.

4
Check icon

Rebuild Only When Needed

When a lock file moves, DeployHQ refreshes the affected cache entry — leaving the rest of your dependency tree intact.

Why Use Build Cache?

Faster deploys aren't just nicer — they change how often your team ships.

Zap icon

Massive Speed-Up

Real-world projects regularly see 70–95% reduction in build time. Multi-minute cold installs become near-instant warm restores.

Check icon

Deterministic by Default

Lock-file fingerprints rule out the classic "it worked locally" cache bug. If the lock changes, the cache refreshes — no stale deps in production.

Folder icon

Works for Any Language

npm, yarn, pnpm, composer, bundler, pip, cargo, go modules — and any custom directory you want to preserve.

Shield icon

Isolated and Per-Project

Caches live inside the isolated build container and never cross project boundaries. No accidental leakage between codebases.

Getting Started

Cut your build time in minutes

Check mark

It's Already On

Build cache is enabled by default on new projects. Standard paths (node_modules, vendor) are cached automatically.

Check mark

Add Custom Paths

Open Project → Build Pipeline → Cache and add any directory your build relies on — Next.js .next/cache, Cargo target/, etc.

Check mark

Purge When You Need To

One click in the project settings clears the cache and forces a clean build — useful after a runtime upgrade.

Read the documentation →
BUILD CACHE Cached paths: node_modules/ vendor/ .next/cache/ Fingerprinted from: package-lock.json · composer.lock Last restore: ✓ 0.4s ago

Frequently Asked Questions

How does cache invalidation work?

DeployHQ fingerprints the lock files that produced the cache (package-lock.json, composer.lock, Gemfile.lock, etc.). When the fingerprint matches the next deploy's lock files, the cache is restored as-is. When it doesn't, the affected cache entry is refreshed automatically.

Can I cache custom paths beyond node_modules?

Yes. Add any directory your build relies on — Next.js .next/cache, Cargo target/, Webpack persistent cache, a custom data directory. Each path is cached independently and restored together at the start of the build.

Is the cache per-project or shared across projects?

Per-project. Caches are scoped to the project that produced them and live inside the isolated build container, so codebases never leak dependencies into each other.

Can I purge the cache?

Yes. One click in the project settings clears the cache and forces the next deploy to do a fresh install. Useful after a language-runtime upgrade or when you want to verify a clean build.

Does it work with Docker Builds?

Yes. Build cache plays nicely with Docker Builds — your image's intermediate layers are cached separately, and any host-side build steps benefit from the same lock-file-aware caching.

Is it on by default?

Yes. New projects ship with sensible cache defaults already enabled — most teams get the benefit without touching configuration. Custom paths and tweaks are available when you need them.

Build minutes back from your day

Lock-file-aware caching, on by default. Start shipping smaller, faster.

10-day free trial • No setup fees • Cancel anytime

Get started today for just $9/month

That's unlimited deployments and 3 projects.

Start your free 10 day trial