Vorta: a desktop GUI for BorgBackup on Linux and macOS

What Vorta actually adds on top of BorgBackup

BorgBackup is a command line deduplicating archiver. It handles the encryption, the chunk-level deduplication, the compression and the repository format. Vorta does none of that. It is a Python and PyQt6 application that drives the borg binary on your behalf and stores the settings you would otherwise keep in shell scripts.

The README describes the target audience plainly: a backup client for macOS and Linux desktops, built to protect data from disk failure, ransomware and theft. That framing matters. This is a single-machine tool for someone sitting in front of a desktop, not a fleet management system. The repository's own pyproject.toml classifies it as a Qt X11 and macOS application, and the topics list on the repository names linux-desktop and macos rather than server or headless.

The concrete thing Vorta contributes is the profile. A profile groups source folders, a backup destination and a schedule into one named unit. Without Vorta you would reproduce that grouping as a shell script plus a crontab entry plus a repository passphrase stored somewhere. Vorta puts all three in a database and a settings window. The README also lists a single place to view all point-in-time archives and restore individual files, which is the day-to-day task where a GUI earns its keep: picking one file out of a snapshot from three weeks ago is tedious on the command line and trivial in a file browser.

How Vorta drives Borg: profiles, a local database and the borg binary

The dependency list in pyproject.toml is the clearest description of the architecture available from the repository. It includes peewee, a small Python ORM, which is how Vorta persists profiles, archive metadata and settings in a local SQLite database. It includes pyqt6 for the interface. On Linux it pulls in secretstorage, which is the freedesktop Secret Service API, so passphrases go to a system keyring rather than a plain text file. On macOS the equivalent role is played by pyobjc-framework-Cocoa and pyobjc-framework-CoreWLAN, alongside pyobjc-framework-LaunchServices for desktop integration.

The data flow is therefore: the Qt UI reads and writes profile records through peewee, then spawns the borg process with the appropriate arguments. Borg talks to the repository, whether that is a local drive, your own SSH server or a hosted service. Vorta parses what Borg reports back and writes the result into its own database so the archive list stays browsable without re-querying the repository every time the window opens.

That last point is a real design consequence. Because Vorta keeps its own view of archives, the GUI can drift from the repository if archives are created or pruned by something other than Vorta. The README does not document a reconciliation step, and the repository does not describe one. If you mix Vorta with cron-driven borg jobs against the same repository, expect the archive list to be stale until you refresh it. psutil appears in the dependencies, presumably to detect mounted volumes and running processes, which is consistent with a client that schedules work around desktop conditions rather than assuming a server is always up.

Installing Vorta and running a first backup

The README does not put install commands inline. It points to the project website for download links and install instructions, and the badges at the top of the README name the distribution channels: Flathub under the application ID com.borgbase.Vorta, a Homebrew cask, and PyPI as the package vorta. Ubuntu, Debian, Fedora, Arch Linux and macOS are all named as supported platforms. Windows is explicitly not supported, because Borg itself does not support it.

If you want to try the current development version without cloning anything, the README gives this one-liner, which uses uv to fetch and run the package straight from the repository:

uvx --from git+https://github.com/borgbase/vorta vorta

For a working setup rather than a trial, the README's full development instructions install uv, clone the repository and sync dependencies:

curl -LsSf https://astral.sh/uv/install.sh | sh
git clone https://github.com/borgbase/vorta.git
cd vorta
uv sync
uv run vorta

After `uv run vorta`, the Qt window opens. The first real use is to create a profile: point it at a local folder as the source, choose a repository destination, and let Vorta initialise the repository. Borg will ask for a passphrase, and on Linux that passphrase is handed to the system keyring through secretstorage rather than written into the Vorta database. Once the profile exists, the first backup runs from the same window, and afterwards the archive appears in the list where individual files can be restored.

Note that none of these commands install BorgBackup itself. Vorta is a client, and the README's own description of the project says it integrates BorgBackup with your desktop environment. If the borg binary is not present and on your PATH, the GUI will start but backups will fail.

Where Vorta is the wrong tool

The most obvious boundary is Windows. The README states it directly: Windows is currently not supported by Borg, though it adds that this may change. There is no Windows build to look for, and a related search phrase asking about Vorta for Windows has no answer in this repository.

The second boundary is headless and multi-machine work. Vorta is a Qt desktop application, and the pyproject classifiers describe an X11 and macOS environment. Running it on a server means running a GUI, which is the wrong shape for the job. Borg's own command line, or a wrapper designed around configuration files and cron, fits that environment without an X server or a display session.

The third boundary is subtler and worth stating plainly: Vorta is a front end, so every failure of Borg is a failure of Vorta, and Vorta cannot fix it. A corrupted repository, a repository locked by a concurrent process, an SSH host key change, a full destination disk: all of these surface in Vorta as errors originating underneath it. The GUI gives you a place to read the error and retry, not a recovery mechanism. Anyone expecting the desktop application to insulate them from Borg's operational model will be disappointed.

There is also a maturity signal worth reading carefully. The pyproject.toml classifies the project as Development Status 4 - Beta. That classification has been carried alongside regular releases, and it is the project's own label rather than an outside judgement. Treat it as a statement that interfaces and stored settings may still move between versions.

Vorta compared with borgmatic, Pika Backup and plain Borg

The alternatives people search for alongside Vorta split into three distinct approaches.

Plain Borg is the engine itself. Using it directly means writing your own borg create, borg prune and borg check invocations, and scheduling them yourself. You get complete control and no additional dependency, and you lose the archive browser, the keyring integration and the profile database. If your backup logic is already a well-tested script, Vorta adds a layer without removing the script.

Borgmatic takes the opposite approach to Vorta. It is configuration-file driven, aimed at unattended and server-side execution, and it has no GUI. The difference in approach is the interface contract: borgmatic asks you to write a YAML file and run it from cron or a systemd timer, while Vorta asks you to click through a Qt window and stores the result in SQLite. If you want the backup definition to live in version control next to your other infrastructure, borgmatic's model is a better fit. If you want a person at a desktop to be able to see and restore their own files, Vorta's model is.

Pika Backup is the closest thing to a direct peer. It is also a graphical front end for Borg, built for the GNOME desktop with GTK rather than Qt. The practical difference for a Linux desktop user is which toolkit and desktop the application integrates with, and which set of features each exposes. Both depend on Borg underneath, so neither escapes Borg's repository format or its passphrase model.

Vorta's stated advantage over all of them is destination flexibility: the README says there is no vendor lock-in, and that you can back up to local drives, your own server or BorgBase, a hosting service for Borg backups. That is a property of Borg rather than of Vorta, but Vorta surfaces it in the profile configuration.

Maintenance, releases and what GPL-3.0 means here

The repository is not archived, and the last push was on 2026-09-26. Releases have been coming at a steady clip: v0.11.4 on 2026-04-28, v0.11.5 on 2026-05-11 and v0.11.6 on 2026-09-07. The version numbering is still in the 0.x range, which is consistent with the Beta classifier in pyproject.toml.

Upgrade cost is where the Beta label translates into real work. Vorta stores profiles and archive metadata in a local database through peewee. The repository does not document a migration policy for that database, and the README does not discuss rollback. Before upgrading across a minor version, the safe move is to copy the Vorta configuration directory aside; the platformdirs dependency is what determines where that directory lives, and it differs between Linux and macOS. That is a precaution you take yourself, not something the project promises.

On licensing: Vorta is GPL-3.0-only, as stated in pyproject.toml and the LICENSE.txt file. The README credits PyQt and Qt, and notes that icons come from Fork Awesome under the SIL Open Font License and from Material Design under Apache License 2.0, with copies of the applicable licences in the src/vorta/assets/icons folder. GPL-3.0-only means you may use, modify and redistribute the software under the same terms. If you intend to embed Vorta in a product you distribute under different terms, that is a question for a lawyer, not for this article. Note also that PyQt itself is dual-licensed by its vendor, which is a separate consideration from Vorta's own licence.

One more maintenance detail visible in the repository: the development workflow uses uv for dependency management, pre-commit for hooks and black for formatting, with a Makefile exposing targets including test, lint, pypi-release and release-preflight. The release-preflight target refuses to proceed if the working tree is dirty or the branch is not master. That is a small but telling sign of a project that ships through a defined process rather than ad hoc.

Editorial conclusion

Adopt Vorta if you already want Borg's encrypted, deduplicated archives and would rather configure them through a Qt window than through shell scripts and cron. Skip it if you run Windows, since Borg does not support that platform, or if you need to manage many servers from one place, where a scriptable wrapper fits better. Before trusting it with real data, verify that Borg itself is installed and reachable on your PATH, since Vorta is only the front end.

Frequently asked questions

Official sources

1. borgbase/vorta on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases