Skip to content

Installation

The image is published to Docker Hub on two release trains. Pick the train that matches how comfortable you are running pre-release builds in production.

Release trains

Train When to use Example pull
Stable Production. Tags are cut from main after stabilising on develop. docker pull marc0janssen/restic-backup-helper:latest
Testing Pre-release / CI. Cut from develop; carries -dev suffix. docker pull marc0janssen/restic-backup-helper:develop

Pinning a specific version

Tags follow the schema <helper-semver>-<restic-version>, e.g. 2.2.2-0.18.1, so you can pin both the helper logic and the Restic base image in lockstep. Testing builds add a -dev suffix, e.g. 2.2.2-0.18.1-dev.

docker pull marc0janssen/restic-backup-helper:2.2.2-0.18.1
docker pull marc0janssen/restic-backup-helper:2.2.2-0.18.1-dev

Why pin?

latest and develop are moving targets. Pinning the full <helper>-<restic> tag means an unattended docker compose pull cannot silently flip you onto a new Restic minor or a new helper major release. See Image tags for the full taxonomy.

Verify signatures and SBOM

  • Trivy scans every push and every tag release; SARIF results land in the GitHub Security tab and tag releases fail on CRITICAL / HIGH findings.
  • SBOMs in SPDX and CycloneDX JSON are emitted by ./build.sh and ./build-testing.sh when SBOM=ON and syft is on PATH. The release CI also uploads source-tree SBOMs on tag pushes.

See Supply chain for verification steps.

Required runtime ingredients

  1. RESTIC_REPOSITORY — Restic repository location. Any backend Restic supports: local path, s3:, sftp:, rclone:, swift:, b2:, …
  2. A password — preferably RESTIC_PASSWORD_FILE pointing at a Docker secret or read-only mounted file; RESTIC_PASSWORD works but appears in docker inspect.
  3. RESTIC_TAG — explicitly empty is a hard failure since 1.14.0. Pick something meaningful (daily, ${HOSTNAME}-data, …) so snapshots can be filtered by tag later.
  4. BACKUP_CRON — when the backup runs (crond 5-field syntax).
  5. Source data mounted somewhere the container can read — typically /data, sometimes a wider read-only /host.

That is the minimum. Everything else is optional and additive.

Next steps