Installing Repeatr

Installing Repeatr

Repeatr releases are available from the releases page on Github!

Changelogs are also committed with the source repo.

All our release binaries were built with Repeatr! They can be reproduced using the same formulas that built them.

To build repeatr from source yourself, the the build instructions in the repo show the way.

Setup and Configuration

Repeatr is pretty darn zero-conf. There are minimal configuration options, and you should be able to start using Repeatr without reading the following section. If you're the enterprising sysadmin who always reads before you run, or running in unusual circumstances, read on:

In particular, you'll notice that none of the configuration available should be capable of changing the correctness of Repeatr, or the behavior in formula evaluation. There is configuration for storage pool locations, configuration for caching pools, configuration for what implmentation details to use for filesystem assembly -- but all of these are have the property that the system will either A) work, or B) explicitly fail; there is no half-alive half-sanity-devouring-zombie mode where Repeatr will claim to run your process, but do so in an unpredictable nonsense way.


Use the `$REPEATR_BASE` environment variable to control where Repeatr will keep its cache, where it will unpack input filesystems during use, and where it will assemble filesystems and launch containers. Typically, you should not need to override this. The default value is `/var/lib/repeatr/`.

Setting REPEATR_BASE may be useful to you if:

Security note: do not set REPEATR_BASE to a path owned by unprivileged users. Doing so would enable a priviledge escalation where the user owning some part of the REPEATR_BASE path can race with Repeatr to modify the filesystem in ways which would cause undefined behavior.

controlling which executor to use

Repeatr supports your choice of execution engines:

Specify your choice at the time of run by using the `--executor` flag.

The default executor is `runc`. Using `chroot` is not recommended unless debugging, or if nesting within another containment system that provides better isolation.

filesystem assembly plugins

Repeatr supports several different mechanisms for assemblying filesystems. Typically, you should not need to explicitly configure this. Repeatr will automatically pick the fastest tools it can, and emit a warning in the logs if using a fallback that's known to particularly slow.

Roughly, the fallback order is as follows:

  1. If it's a read-only filesystem, use a bind mount. (These are usually available on any system.)
  2. If it's a read-write filesystem, try to use AUFS for fast Copy-On-Write performance. (AUFS may need installation on the host.)
  3. If AUFS isn't available, try to modprobe it into being, just in case. (This is a workaround for some oddly behaving distros.)
  4. If nothing worked yet, fall back to doing a full copy of the filesystem. Warn the user: this makes launch time visibly slower.

Installing AUFS on the host is strongly recommended. AUFS should be available from the system package manager in most distributions.