Pluton: A Web UI Wrapper Around Restic and Rclone for Self-Hosted Backups

The gap Pluton fills between Restic and a cron file

Restic already does encrypted, deduplicated, incremental snapshots, and Rclone already speaks to a long list of cloud providers. What neither ships is a scheduler with a retention policy editor, a progress view, per-job notification routing and a restore browser. Pluton's README describes the project as a self-hosted backup management platform that simplifies automated, incremental backups, and states plainly that it wraps Restic for incremental backups and Rclone for cloud storage connectivity in a web interface. The target user is someone running a home server, a small fleet of VPS instances or a lab machine who is willing to run one container but not willing to maintain a set of shell scripts, systemd timers and log files. The topic list on the repository includes 3-2-1-backup, which signals the intended workflow: one copy local, one copy on a second medium, one copy offsite. Pluton addresses that with a feature it calls backup replication, described as automatically backing up content to multiple cloud storages to build a 3-2-1 plan. That is the actual selling point. Not encryption, which Restic provides, and not provider count, which Rclone provides.

What actually runs: Restic, Rclone and a Node process in between

The architecture visible in the material is a three-layer stack. The bottom layer is Restic, credited in the acknowledgements under a BSD 2-Clause licence, handling snapshot creation, compression, encryption and retention. The middle layer is Rclone, MIT licensed, providing the storage backends that the README counts as 70+ supported providers. The top layer is Pluton itself, a TypeScript application that ships as a Docker image and owns the database, configuration and logs inside a single volume mounted at /data. The data flow implied by the configuration is: Pluton reads a job definition from its database, invokes Restic against a repository whose credentials are derived from the ENCRYPTION_KEY environment variable, and when replication is configured, uses Rclone to push that repository to additional destinations. Source data enters the container through bind mounts, and the README is explicit about the direction that matters: backup sources are mounted read-only, while a local backup destination must be writable, with the instruction to leave out the :ro suffix in that case. It also warns that inside Pluton you select the container path such as /mnt/backups, not the host path. That detail trips people up more often than any other part of the setup.

Docker Compose setup and the environment variables that matter

The README provides a complete docker-compose.yml. The service is named pluton, the image is plutonhq/pluton:latest, the container is pluton-backup, and restart is set to unless-stopped. Ports map ${SERVER_PORT:-5173} to the same value inside the container, so the default web address is http://localhost:5173. Three environment variables are marked required: ENCRYPTION_KEY, described as the encryption key for restic and rclone snapshot encryption, plus USER_NAME and USER_PASSWORD for the admin login. The README asks for secure random strings of at least 12 characters each. Optional keys include APP_TITLE, APP_URL, SERVER_PORT, MAX_CONCURRENT_BACKUPS defaulting to 2, and SESSION_DURATION defaulting to 7 days. Three UI security toggles are worth reading twice: ALLOW_CUSTOM_RESTORE_PATH and ALLOW_FILE_BROWSER both default to true, and DISABLE_EVENT_SCRIPTS defaults to false. The accompanying .env example sets ENCRYPTION_KEY, USER_NAME and USER_PASSWORD, and shows SERVER_PORT=7173 as an override. The run command is docker compose up -d. Desktop installers for Windows, macOS and Linux are offered on the download page, and headless Linux server installation is delegated to a separate documentation page rather than described in the README. If you want the exact steps for a server install, that page is the only source.

Restore, scripts and notifications: the operational surface

Beyond scheduling, Pluton exposes the parts of a backup workflow that usually live in shell history. The README lists easy restore and download of snapshot data through the interface, real-time progress tracking, application and backup logs viewable in the UI, event notifications to email, Slack, Discord and NTFY push, and auto retry logic with customization options when a job fails. There is also a hook system: scripts can run before and after backups. The DISABLE_EVENT_SCRIPTS flag exists precisely because that hook system is an execution surface, and it defaults to false, meaning scripts are permitted unless you turn them off. Two other defaults deserve the same scrutiny. ALLOW_FILE_BROWSER set to true means the web interface can browse the filesystem as the container sees it. ALLOW_CUSTOM_RESTORE_PATH set to true means a restore can be directed to an arbitrary path rather than a fixed one. Neither is wrong for a single-admin home setup. Both are worth flipping if the instance is reachable by anyone else or sits on a network you do not fully control. The README presents them as settings, not warnings, so the judgement is left to you.

Where Pluton is the wrong tool

Pluton is an orchestration layer, and orchestration layers fail in ways their underlying tools do not. If the container is down, the scheduler is down, and a backup that a systemd timer would have run simply does not happen. The README offers no statement about what happens to missed jobs, so treat catch-up behaviour as unverified. The ENCRYPTION_KEY deserves separate thought. It is supplied as an environment variable to the application, which means the running web process holds the material needed to derive repository access. That is a different posture from a Restic repository whose password lives in a root-owned file read only by a cron job. For a homelab it is a reasonable trade. For an environment where the web tier is exposed, it is a decision to make deliberately, not by default. The feature list is also thinner than a mature backup product: the README mentions retention policies and scheduling but no verification or check job, no bandwidth throttling, and no documented preflight that proves a restore works. Without a scheduled restic check, a repository can accumulate corruption that nobody notices until a restore is attempted. That is not a Pluton defect, it is an omission in what the interface exposes, and it is the first thing I would want to see added. Finally, the release cadence shown in the repository metadata (0.20.0, 0.19.0, 0.18.3 across roughly a month) indicates a project still moving quickly. Fast movement means API and configuration drift between versions, so pin a tag rather than tracking latest.

Compared with running Restic and Rclone directly

The honest alternative is the thing Pluton wraps: Restic plus Rclone, driven by cron, systemd timers, or a configuration management tool. The difference is not capability, it is where the logic lives. Direct usage puts scheduling, retention flags, notification and failure handling into files you own and version, typically a shell script per job plus a timer unit. Pluton moves all of that into a database behind a web form, which is faster to set up and easier to inspect for someone who does not want to read restic forget documentation. The trade runs the other way when something breaks. With direct Restic, a failed job produces a log line and an exit code you can reproduce by hand on any machine. With Pluton, the failure is mediated by the application, and debugging means reading Pluton's logs before you get to Restic's output. There is also the question of lock-in: a Pluton job definition is not portable, whereas a shell script is. If you already have working Restic scripts, Pluton's main additions are the restore browser and the replication fan-out. If you have neither, Pluton is the shorter path to a first encrypted offsite snapshot.

Maintenance, licensing and what to check before you commit

Pluton is Apache-2.0, and the two projects it depends on carry their own terms: Restic under BSD 2-Clause and Rclone under MIT, both permissive and both listed in the acknowledgements. Apache-2.0 includes an explicit patent grant and requires preservation of notices, which matters if you redistribute the image inside an organisation. That is a description of the licence text, not legal advice; if you ship Pluton as part of a product, have someone qualified read it. Operationally, the cost is one container plus a volume. Upgrades mean pulling a new image tag and restarting, with the caveat that a fast release cadence can bring schema changes to the database in /data. Back up that volume before upgrading, or you risk losing job definitions and history along with the ability to roll back cleanly. The dependency chain is short and stable, which keeps long-term maintenance low, but the container itself is a single point of failure for the scheduling function. If you run Pluton, run something independent that alerts you when a snapshot has not appeared in the expected window, because a backup system that silently stops is worse than no backup system at all.

Editorial conclusion

Adopt Pluton if you already want Restic semantics and Rclone reach but do not want to hand-write the scheduling, retention and notification glue, and if you are comfortable running a Docker container that holds the Restic encryption key. Do not adopt it if you need a formally audited backup product, if your threat model forbids a web process from touching the repository password, or if your retention rules are unusual enough that a UI cannot express them. Before committing, verify three things on a test host: that a snapshot created through the UI can be read with the restic CLI using the ENCRYPTION_KEY you supplied, that a restore to a custom path behaves as ALLOW_CUSTOM_RESTORE_PATH implies, and that your chosen Rclone backend survives a repository check.

Official sources

1. License: Apache-2.0
2. plutonhq/pluton on GitHub
3. Project website
4. README
5. Releases