[Support] D4v3 - Dockkeep (Backups made easy | Restic + Rclone)

Dockkeep runs the backups you would otherwise write cron jobs and shell scripts for.

You describe what to back up, where to, and when in a web UI. Dockkeep stores that as one plain TOML file you can still read, review and edit by hand, and then takes care of running the jobs, pruning old snapshots, copying repositories off-site, logging everything, telling you when something breaks, and getting your files back when you need them.

Backups run on Restic, off-site copies on Rclone. Dockkeep does not invent a backup format and does not hide the tools underneath: your repositories stay ordinary Restic repositories that any restic binary can read, with or without Dockkeep. That is deliberate — the day you need your data back is the worst possible day to depend on a tool that is also broken.

It is built for local, trusted environments: home servers, homelabs, NAS boxes.

---

What you can do with it

- Back up mounted directories to local repositories or to cloud storage through Restic's Rclone backend, with excludes, tags and per-backup arguments.

- Keep several copies per job — one to the array, one to a NAS, one to object storage — each with its own schedule, retention and credentials.

- Prune snapshots automatically with the usual keep rules keep_daily, keep_weekly, keep_within, …) and run a cleanup afterwards so the space actually comes back.

- Mirror repositories off-site with Rclone tasks. A deleting sync refuses to start when the source is missing or empty, so an unmounted volume cannot wipe the remote copy.

- Chain steps into workflows: stop containers, back up, sync off-site, start them again.

- Browse snapshots in the UI and restore single files or whole trees into a dedicated restore directory — restores never write anywhere else.

- Run hooks before and after a job, including stopping and starting other containers over the Docker socket.

- Get notified by e-mail, Pushover, ntfy, Gotify or webhook.

- Everything runs on a built-in cron scheduler; runs, logs and history are visible in the UI.

Screenshots

Dashboard:

Runs:

Restore browser:

Config editor:

---

Please read before installing

- The web UI has no built-in authentication. It is an administrative interface with full access to your configuration and your repository passwords. Keep the port on your LAN, or put it behind a VPN or an authenticating reverse proxy. Do not port-forward it.

- amd64 only. There is no arm64 image yet.

- Set TZ — it decides what "02:00" means for your schedules.

Getting started

1. Install from Community Applications and keep the default paths. /backups is where local repositories live, /restore is where restores are written, /data is the example read-only source mount — add one path entry per directory you want to back up.

2. Set a repository password, either in the configuration or via the masked DK_RESTIC_PASSWORD variable (referenced from the config as password_env).

3. Open the WebUI, create a job with one backup, point it at your source and a repository under /backups, and give it a schedule.

4. Run it once manually from the UI and check the log.

Two things cannot be regenerated if you lose them: your repositories and the credentials to read them /config plus wherever the passwords live). Keep a copy of those somewhere Dockkeep is not the only way to reach them. Everything in /appdata is convenience state and can be rebuilt.

Dockkeep follows semantic versioning: the configuration format and the container contract stay compatible within a major version, and any change to them is listed in that release's notes. Your repositories are never touched by an update — they are plain Restic repositories and no release rewrites them.

---

Links

- Project and documentation: https://github.com/DavidKrGH/Dockkeep

- Image: ghcr.io/davidkrgh/dockkeep

- Issues: https://github.com/DavidKrGH/Dockkeep/issues

- License: MIT

This is the first public release, so feedback from Unraid users is very welcome — especially on defaults that feel wrong for an Unraid box, and on anything in the setup that was harder than it should have been. Bug reports are best on GitHub so they do not get lost, but ask here whenever that is easier.

Edited Thursday at 09:43 PM2 days by D4v3