Kopia

Kopia is an open-source backup tool that turns files and directories into encrypted, deduplicated snapshots, then parks that data wherever storage already exists: an S3 bucket, a Backblaze B2 account, a NAS reachable over SFTP, or a folder on a second machine. Nothing has to run on the other end. A Kopia repository is just a storage location plus a password, and any client that connects to it, a laptop, a server, a second machine pointed at the same bucket, deduplicates directly against whatever is already stored there. Both a command-line binary and a desktop GUI called KopiaUI ship from the same codebase, so scripting a nightly job and clicking through a restore are equally well supported.

Is Kopia actively maintained in 2026?

Yes, and by a comfortable margin. The kopia/kopia repository on GitHub has passed 13,500 stars, 86 tagged releases, and over 4,100 commits, with the latest stable build, v0.23.1, published in June 2026. The official Docker image tracks that cadence through latest, testing, and unstable tags, and the documentation site shows commits landing as recently as July 2026. No archive notice here, and no maintenance gap to explain away, which isn’t something every backup tool in this category gets to say.

What Kopia actually does

A snapshot policy defines what gets backed up, how often, what to skip via .kopiaignore rules, how long old snapshots stick around, and whether data gets compressed before it’s encrypted. The first snapshot uploads everything; every one after that only deals with whatever changed, since unchanged pieces already exist in the repository under the same content hash. Restoring works by pulling files back through the CLI or GUI, or by mounting a snapshot as a browsable read-only filesystem, handy for grabbing one file out of last Tuesday’s backup without restoring everything. An optional maintenance job runs in the background to compact old data and reclaim space once retention policies expire older snapshots.

The repository model: why Kopia doesn’t need a backup server

This is the part that actually separates Kopia from a typical client/server backup tool. Underneath the repository sits a layer Kopia calls Content-Addressable Block Storage: every chunk of data gets hashed with SHA2 or BLAKE2S, that hash becomes the chunk’s identifier, then it’s encrypted with AES256-GCM or CHACHA20-POLY1305 and packed into 20-40MB bundles before it touches the storage backend. Two identical chunks, whether from the same file backed up twice or from two different machines sharing a repository, produce the same hash and get stored exactly once, no server process brokering anything. The object storage backend is the only thing between clients; each one hashes and compares independently. A Kopia Repository Server does exist for teams that want centralized access control, but it’s an add-on for a specific use case, not a requirement.

Installing Kopia with Docker

The official kopia/kopia image expects a repository password through the KOPIA_PASSWORD environment variable, plus a few mounted directories: /app/config for the repository connection file, /app/cache for downloaded data, and the storage location itself if it’s local rather than cloud-based.

$ docker run -e KOPIA_PASSWORD \
-v /path/to/config:/app/config \
-v /path/to/cache:/app/cache \
-v /path/to/logs:/app/logs \
-v /path/to/repository:/repository \
-v /path/to/tmp:/tmp:shared \
kopia/kopia:latest

Running Kopia in server mode, the setup that exposes the web UI on port 51515, looks like this in Compose:

services:
  kopia:
    image: kopia/kopia:latest
    container_name: kopia
    hostname: kopia
    restart: unless-stopped
    ports:
      - 51515:51515
    command:
      - server
      - start
      - --disable-csrf-token-checks
      - --insecure
      - --address=0.0.0.0:51515
      - --server-username=USERNAME
      - --server-password=CHANGE_THIS_PASSWORD
    environment:
      - KOPIA_PASSWORD=CHANGE_THIS_REPOSITORY_PASSWORD
    volumes:
      - ./config:/app/config
      - ./cache:/app/cache
      - ./logs:/app/logs
      - /path/to/data:/data:ro
      - /path/to/repository:/repository
      - /path/to/tmp:/tmp:shared

Homelab use cases

The obvious fit is offsite, deduplicated backup for whatever’s already self-hosted: a Nextcloud data directory, an Immich photo library, a Paperless-ngx archive, or a handful of database dumps, shipped to Backblaze B2 or a relative’s NAS instead of trusting a single disk. Because the repository model doesn’t need a dedicated server, backing up several machines to one shared bucket works without provisioning anything extra; a home server and a laptop can dedupe against the same repository if they happen to store overlapping data. It deploys the same way as any other container through Dockge or Portainer, and like Duplicati, it’s a poor fit for Watchtower-style unattended auto-updates, given how much a mid-snapshot restart could complicate things. The Docker & Containers category, our 3-2-1 backup strategy guide for homelabs, and the homelab setup guide for beginners cover where a backup job like this fits into a wider stack.

Kopia vs Duplicati and Restic

Duplicati and Restic solve a similar problem but land in different spots. Duplicati’s deduplication lives in a per-job local database instead of a shared, hash-addressed repository, so two separate Duplicati jobs don’t dedupe against each other even when backing up to the same destination. Kopia and Restic both use an actual content-addressable repository format, so any client sharing that repository benefits from deduplication automatically. Where they diverge is the interface: Restic is CLI-only with no bundled dashboard, while Kopia ships a GUI in the same package, closer in spirit to Duplicati’s web UI without giving up the scriptability Restic users expect.

Category	Kopia	Duplicati	Restic
Dedup model	Content-addressable block storage, hash-based, shared across any client on the repository	Per-job local database tracking changed blocks; jobs don’t dedupe against each other	Content-defined chunking in a shared repository, similar model to Kopia
Central server required	No, any client with the password connects directly	No, but no cross-job dedup either	No, same repository model as Kopia
Interface	CLI and GUI (KopiaUI) from one codebase	Web UI built in	CLI only, no bundled UI
License	Apache License 2.0	MIT	BSD-2-Clause

Kopia: pros and cons

• Free and open source under the Apache License 2.0, no account or license key required
• Content-addressable repository means shared storage between multiple machines deduplicates automatically, no server process needed
• Both CLI and GUI ship from the same codebase and stay in sync
• Optional ransomware protection via object locks and restricted access keys on supported backends

• No bundled scheduler outside of KopiaUI’s own policies; CLI-only setups need external cron or systemd timers
• Restoring a single file by mounting a snapshot is a less direct workflow than a one-click restore in a pure web UI
• Smaller ecosystem of prebuilt storage integrations than Duplicati’s 40-plus backend list

FAQ

Is Kopia free?

Yes, entirely, under the Apache License 2.0. There’s no paid tier, account, or license key involved.

Is Kopia still actively developed?

Yes. The GitHub repository passed 86 releases and 4,100 commits by June 2026, with the latest stable version, v0.23.1, published that same month.

Does Kopia need a dedicated backup server?

No. A Kopia repository is just encrypted storage with a password; any client with that password connects directly and deduplicates against it. A Kopia Repository Server exists only for centralized access control across multiple users, and it’s optional.

Kopia vs Duplicati: which one should I use?

Duplicati fits better for anyone who wants a web UI handling scheduling and restores without touching a terminal, plus the widest list of supported destinations. Kopia fits better when true cross-machine deduplication matters, or when both a GUI and a scriptable CLI need to work from the same repository.

Kopia sits right next to Duplicati as one of the more actively developed self-hosted backup options going into 2026: an actual content-addressable repository, a release cadence with no gaps to explain, and ransomware protections most backup tools don’t bother with. Anyone running Duplicati and wondering whether the deduplication story is better elsewhere now has a concrete answer, and a link to click instead of a name in a comparison table.