Pluton: Self-Hosted Backups with Restic and Rclone

Pluton is an open-source backup platform you self-host, and it runs the backups on my own server. Under the hood, two familiar tools do the work: Restic handles the encrypted, deduplicated snapshots, and Rclone connects it to more than 80 storage providers. Pluton wraps both in a web UI where you define plans, schedules, retention, and replication without touching a terminal.

I have it deployed on my server backing up my Docker stacks, project folders, and Docker volumes. Setup notes below, plus a comparison with Zerobyte, another Restic GUI I wrote about earlier this year.

What is Pluton?

Pluton is a TypeScript application (Apache-2.0 licensed) that turns Restic and Rclone into a managed backup service. The split of responsibilities looks like this:

Layer	Responsibility	What you get
Restic	Snapshots, encryption, deduplication, compression	Fast incremental backups that are encrypted client-side
Rclone	Storage connectivity	S3, B2, Google Drive, OneDrive, SFTP, pCloud, and 80+ more
Pluton	Web UI, scheduling, retention, replication, agents	A control plane for all of it

The project is young. It appeared in November 2025 and sits at v0.18.3 as of August 2026, but development is active and the feature list already covers most of what people patch together with cron jobs and shell scripts.

Key features

Pluton vs Zerobyte

Both tools wrap Restic, so snapshot format, encryption, and deduplication are identical. The difference is scope. Zerobyte is a lean dashboard for backing up one server. Pluton aims to be a small backup platform.

	Pluton	Zerobyte
Backup engine	Restic	Restic
Cloud destinations	80+ providers through built-in Rclone integration	Local, S3, GCS, Azure, or rclone remotes via mounted config
Replication	Up to 2 mirror destinations per plan	One repository per job
Remote machines	Pluton Agent reports into the central console	Single node only
Network sources	Through agent devices	NFS, SMB, WebDAV mounts via FUSE
Scripts	Pre/post job hooks	Not built in
Auth	Users, sessions, 2FA	Single user
Dashboard port	5173	4096
Privileges	None beyond your volume mounts	SYS_ADMIN + FUSE device if you mount shares
Maturity	v0.18.x, first release Nov 2025	0.x series

My take after running both: pick Zerobyte if you back up a single server and want the simplest possible setup, especially when your sources live on NFS or SMB shares. Pick Pluton if you want built-in replication for proper 3-2-1 backups, or you have more than one machine to protect. The replication feature alone settles it for me: every plan can push its snapshots to two extra destinations automatically, which is exactly what the 3-2-1 rule asks for.

Install Pluton with Docker Compose

This is the compose file from my server. It joins the Caddy network instead of publishing ports, and mounts everything I want backed up as read-only:

services:
  pluton:
    image: plutonhq/pluton:latest
    container_name: pluton
    restart: unless-stopped
    volumes:
      - pluton-data:/data
      - /home/user/docker-apps:/mnt/docker-apps:ro
      - /home/user/projects:/mnt/projects:ro
      - /var/lib/docker/volumes:/mnt/docker-volumes:ro
    environment:
      ENCRYPTION_KEY: ${ENCRYPTION_KEY}
      USER_NAME: ${USER_NAME}
      USER_PASSWORD: ${USER_PASSWORD}
      APP_TITLE: ${APP_TITLE:-Pluton}
      APP_URL: ${APP_URL:-http://localhost:5173}
      SERVER_PORT: ${SERVER_PORT:-5173}
      NODE_ENV: production
      IS_DOCKER: "true"
    networks:
      - web
    expose:
      - "5173"

volumes:
  pluton-data:

networks:
  web:
    external: true

The .env file needs three required values:

ENCRYPTION_KEY=generate-a-long-random-string
USER_NAME=admin
USER_PASSWORD=use-a-real-password

Generate the key with openssl rand -base64 32. The ENCRYPTION_KEY protects your restic snapshots and rclone configs, so back it up somewhere safe. Lose it and the backups are decoration.

A few details worth knowing:

• Source mounts can be read-only (:ro). A backup destination must be writable, so never add :ro to a local repository path.
• APP_URL must match how you reach the UI, especially behind a reverse proxy.
• If you prefer exposing the port directly, replace expose with ports: ["5173:5173"].

Then start it:

docker compose up -d

Reverse proxy with Caddy

Since the container sits on the shared web network, a Caddy block is all it takes:

backup.example.com {
    reverse_proxy pluton:5173
}

One quirk I noticed behind the proxy: the logs fill up with ERR_ERL_UNEXPECTED_X_FORWARDED_FOR warnings because the app does not set Express’ trust-proxy setting. Backups run fine; it is log noise, not a failure. If you expose Pluton directly without a proxy, the warnings do not appear.

Create your first backup plan

The workflow is three steps: destination, plan, schedule.

1. Add a storage destination. For local storage, point Pluton at a writable container path such as /mnt/backups. For cloud storage, pick a provider from the Rclone-backed list and enter credentials in the UI. No config files to edit.
2. Create a backup plan. Choose source paths, destination, schedule, and a retention policy (keep N daily, weekly, monthly, yearly snapshots). Compression and AES-256 encryption come from Restic automatically.
3. Add replication (optional). Attach up to two extra destinations so every run is mirrored. This is the 3-2-1 shortcut.

Run the plan once manually and watch the real-time progress view. Check the logs tab if anything looks off, then let the scheduler take over. Before trusting it, set up notifications under settings so failed jobs reach you on Discord, Slack, NTFY, or email. A backup system without notifications fails silently, and silent failures are how you find out during a disaster.

Restore and download

Restores are where most backup GUIs fall apart, so I tested this early. Open a plan, browse a snapshot like a regular file manager, then either restore selected files or the whole snapshot to the original location or a custom path. You can also download the entire snapshot as a TAR file, which is handy for pulling a copy onto your laptop without touching the CLI.

My setup notes

For reference, my instance backs up three read-only mounts: my Docker app configs, my project folders, and /var/lib/docker/volumes for the databases and stateful containers. Snapshots go to a local disk, with replication to cloud storage for the offsite copy. The whole thing replaced a pile of cron-driven restic commands that worked but had no visibility.

Two habits worth keeping regardless of tool:

• Test a restore on real files, not in your head. Do it after the first week and then monthly.
• Keep the ENCRYPTION_KEY and a copy of your Pluton data directory outside the machine it lives on.

FAQ

Does Pluton replace Restic?

No, it drives Restic. Your repositories stay standard restic repositories, so you can still restore from the CLI if Pluton disappears tomorrow. That also means no vendor lock-in.

Can Pluton back up Docker volumes?

Yes. Mount /var/lib/docker/volumes into the container read-only and add it as a source path. For databases, use a pre-script to dump data first so you are not copying live files mid-write.

Is there a desktop version?

Yes. Installers exist for Windows, macOS, and Linux desktops, plus a headless Linux server install. The desktop builds are useful for backing up workstations into the same central console through the agent.

Final thoughts

Pluton has earned its place on my server. Restic keeps the snapshots trustworthy, Rclone puts any storage target a dropdown away, and the UI handles scheduling, retention, and replication. It is younger than Zerobyte, so pin your version and read release notes before updating. But for proper 3-2-1 backups across multiple machines, it is the stronger platform of the two.

View Pluton on GitHub