Build cache

Gigadrive Network keeps your package-manager store and your framework's incremental state between builds, so a second deployment of the same branch does not reinstall everything from the registry. The cache never holds a finished build output, so a cache hit still runs your build command.

What is cached

Nothing else carries into the next build. node_modules is reinstalled every time, and any file your build script writes outside those two directories is gone once the sandbox ends.

What invalidates it

The cache is looked up by a key computed from the dependency state of your application. Change any of these and the next build starts cold, then writes a new entry:

• Your lockfile contents.
• The package manager, and the version declared in the packageManager field of your package.json.
• The root directory.
• The application.

The key does not include the branch or the build environment variables. Every branch of an application shares the same cache, so a new branch starts warm when its lockfile matches, and changing or rotating an environment variable does not cause a cold build.

A build writes a new entry only when the key is new, when the install changed a package store, or when the entry is older than one day. A build that restores a cache and installs nothing new logs Build cache unchanged, skipping save and ends without an upload.

Restoring and saving

Restore happens before install. A restore that fails for any reason wipes the directory and the build continues cold, which is why you will occasionally see a slow build with no explanation in the log.

The save runs alongside packaging, after your build finishes, and writes these lines to the deployment log:

Saving build cache
Uploading build cache (412 MB)
Build cache saved (412 MB in 6.1s)

A save can also be skipped or refused, which shows as Build cache save skipped for this deployment or Build cache save failed; continuing without cache update. Neither fails the deployment.

A refusal means the organization is over its cache capacity in bytes or entries, has passed its hourly upload ceiling, or already has too many builds writing at once.

Choose the cache mode

Set the mode per application on the General settings page under Build cache. The default, Auto, fits most applications.

A build that skips the cache in Auto mode logs Build cache skipped: the last cold install was faster than a cache restore. The first cold build of an application always uses the cache, because that build produces the install measurement.

Redeploy without the cache

If you suspect a stale cache, open the deployment's actions menu and choose Redeploy without build cache. The new deployment builds cold, logs Build cache disabled for this deployment, and leaves the application's entries untouched. Use it before clearing the cache for the whole organization.

Limits per plan

Storage beyond the included allowance is only used when an organization admin enables cache overage, which is billed per GiB-month. Without it, builds keep running and stop writing new entries once the included allowance is full. Least-recently-used entries are removed as capacity or retention limits bite. See Plans for what each plan costs.

An archive larger than the plan's entry limit is abandoned during the save with Build cache exceeds the plan entry-size limit, and the build finishes normally.

Clearing the cache

Cache clearing is organization-wide and restricted to organization admins. Open Settings, Limits, then Clear cache on the build cache card. Every entry becomes unavailable immediately, and the next build for each key reinstalls dependencies and writes a fresh one.

That page also shows what is currently retained, the recent evictions, and the overage toggle.