Skip to main content
Every remote build runs in a clean, single-use VM. Revyl uses two kinds of caching to make repeat builds faster:

​
Automatic compilation caching

Revyl enables the right compilation caches for each platform without changing your build commands: The first compatible build warms the cache. Later builds on the same toolchain can reuse its compiler outputs across apps and branches in your organization. The snippets below focus on cache fields. Keep the selected recipe’s runnable app_id, build_commands, and output_path from your build configuration. You can turn each cache off independently:
Each setting accepts "0" (off) or "1" (on) and defaults to "1".
Compilation caching is an optimization, not a build dependency. If it is unavailable, the build continues normally. It is also skipped when the build timeout is longer than 60 minutes.

​
Configured path caches

Declare defaults under build.caches and recipe-specific additions under build.profiles.<name>.<platform>.caches. Each cache has a key and a list of project-relative paths stored under it:
Paths must be project-relative and stay inside the workspace. Absolute paths and .. segments are rejected.

​
How configured caches work

Build-level and recipe caches merge by key. For a matching key, build-level paths come first and recipe paths are appended with duplicates removed. Each effective key maps to one compressed archive that Revyl stores between builds:
  1. After checkout, Revyl restores the latest archive directly into the clean build workspace. A new key starts empty.
  2. Your commands read and write the configured paths normally, such as node_modules, Pods, or DerivedData.
  3. If the build succeeds, Revyl archives those exact paths and saves them for the next build. Failed builds don’t update caches, so a broken run can’t poison them.
Compressed archives larger than 4 GiB are not saved. The build still succeeds, and the previous saved archive remains available for later builds. Cache keys are scoped to your organization and platform. Builds using the same key share that archive across apps and branches. Concurrent builds work in private VMs; the last successful upload becomes the next saved state.

​
What to cache

Tool caches that normally live in your home directory must be redirected into the project. For example:
If you cache a build-output directory, keep output_path specific enough that it cannot select a stale artifact.

​
Cold builds and clearing caches

revyl cache list and delete manage configured caches only. Compilation caches are managed automatically and can be bypassed with --no-cache or the individual environment settings above.

​
Troubleshooting

  • The second build is still slow: make sure the first build completed successfully and compare builds using the same toolchain.
  • Dependency installation is still slow: add its download or install directory to a configured cache.
  • A configured cache looks stale: try --no-cache, then delete the cache if the cold build fixes the problem.
  • Compilation caching is missing: check the build logs for compilation-cache messages and confirm the timeout is 60 minutes or less.