Borg UI: a web front end for BorgBackup, and what its Docker install actually commits you to
Replace complex Borg Backup terminal commands with a beautiful web UI. Create, schedule, and restore backups with just a few clicks.
At a glance
- What is it?
- Borg UI wraps BorgBackup repositories, schedules, restores and remote machines in a browser interface. It lowers the entry cost of Borg, but it also puts a web login in front of an encryption key store, so the deployment details matter more than the screenshots.
- Who is it for?
- Adopt Borg UI if you already run Borg on a home server, NAS or single VM and want schedules, archive browsing and restore flows in a browser instead of shell history. Do not adopt it if your threat model treats the backup host as untrusted, or if you need a documented, versioned REST API and a published upgrade path; the README does not supply either.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Borg UI fills: Borg's command surface versus a browser
BorgBackup is a deduplicating, encrypted archiver. Its interface is a CLI: borg init, borg create, borg prune, borg mount, borg extract. That is a reasonable interface for a script and a poor one for a person who wants to answer a simple question at 11pm, which is whether last night's backup ran and what is inside it. Borg UI targets that person. The README describes it as a modern web interface for Borg Backup that lets you run backups, browse archives, restore files, manage repositories and automate schedules from one interface. The audience is the self-hosted crowd: the repository topics list docker, raspberry pi and sbc, and the highlights mention multi-architecture containers for amd64, arm64 and armv7. So the intended deployment is a small always-on box, not a fleet. If you already have a working Borg cron job and never look at it, Borg UI adds a service to maintain without changing what Borg does underneath.
What sits between the browser and the borg binary
The architecture visible in the material is a web application that drives Borg rather than replacing it. The Docker command mounts three things: a named volume borg_data at /data, a named volume borg_cache at /home/borg/.cache/borg, and a host path /home/yourusername at /local inside the container. That layout tells you where the state lives. /data holds the application's own database and configuration, the Borg cache volume holds Borg's chunk index, and /local is how a host directory becomes visible to the container so it can be added as a backup source. Repositories themselves are not pinned to a volume in the example, which is consistent with the highlights listing local, SSH and SFTP destinations: the repository can be a path inside a mount or a remote reachable over SSH. The feature list also covers pre and post backup hooks, maintenance actions, and notifications through 100+ Apprise services, so the app is orchestrating Borg invocations and reading their output rather than reimplementing the archive format. That is the right call. It also means Borg UI inherits Borg's behaviour, including the fact that a repository passphrase is required to do anything useful, and the README does not describe where that passphrase is stored or how it is protected.
Getting it running: the docker run line and the default login
The README gives one Docker command and one native install path. The Docker route is a detached container named borg-web-ui, publishing port 8081, with the two named volumes and one host bind mount described above, using the image ainullcode/borg-ui:latest. The README states you then reach the app at http://localhost:8081 with admin / admin123. Those are the credentials printed in the documentation, which means the first thing anyone deploying this should do is change them; a backup console that can read your archives is not something to leave on a documented default. The native route is aimed at Debian or Ubuntu hosts, including bare metal, a VM or an LXC container. It downloads install.sh from the latest GitHub release, downloads install.sh.sha256, verifies it with sha256sum -c -, and only then runs sudo bash install.sh. The checksum step is written as a chained command, so a failed verification stops the install. That is a better pattern than piping curl straight into bash, and it is worth copying if you script this yourself. The README points to docs.borgui.com/installation for the full option set; the material here does not enumerate the native install's configuration keys, service unit name, or data directory, so treat those as things to read before you commit.
Version churn is the real operational cost here
The release list is the part of this project worth reading twice. v2.2.6 shipped in mid July, v2.2.5 a month earlier, and v2.3.0-alpha.1 landed in August. A monthly patch cadence on a backup tool is normal, but the presence of an alpha line alongside stable means you have to be deliberate about which tag you pull. The README's own example uses :latest, which is the least predictable choice available and may hand you pre-release behaviour on a schedule you did not choose. Pinning to a specific tag such as v2.2.6 is the safer default for anything holding your only copy of a file set. The second cost is Borg itself. The highlights claim support for BorgBackup 1.x and BorgBackup 2 beta workflows. Borg 2 changes repository format and command surface, so a UI spanning both has to branch internally, and the beta label means the Borg 2 path is not a settled target. If your repositories were created by Borg 1.x, verify which Borg binary the container ships and whether it can read them before you migrate anything. The material does not state the bundled Borg version, so that is a question for the docs or the image itself.
The limitation the README does not discuss: a web UI is a new attack surface for your keys
Borg's security model assumes the client holds the passphrase and the repository host may be untrusted. Borg UI changes the shape of that: a long-running network service now has to hold or obtain the passphrase to run scheduled backups, and it exposes repository contents through a browser session. The README does not describe authentication beyond the default admin login, does not mention TLS termination, and does not say how passphrases are stored at rest in /data. Any of those omissions is a real gap for a tool whose whole job is reading encrypted archives. The practical consequence is a deployment constraint: bind port 8081 to localhost or a private network and put a reverse proxy with TLS in front of it, rather than publishing it on a public interface as the example command does. The second limitation is scope. This is a single-host management UI. There is no mention of a documented REST API, role-based access control, or an audit log, so it is a poor fit for a team that needs to prove who restored what and when. If that is your requirement, the browser interface is the wrong layer to solve it at.
Where Borg UI is the wrong tool, and what to use instead
Two cases argue against it. The first is a fleet of machines with a central backup server. Borg UI's remote machine management covers SSH key deployment and storage visibility, which is useful for a handful of hosts you administer personally, but it is not a scheduler with job queues, retention policies expressed as code, or per-tenant isolation. For that shape of problem, a configuration management approach is a better fit: keep borg create and borg prune in Ansible roles or systemd timers, commit the playbooks, and let your existing monitoring read the exit codes. The difference in approach is that Borg UI makes the schedule a row in its own database, visible only through its interface, while an Ansible role keeps the schedule in a file you can diff and review. The second case is anyone already comfortable with Borg. The CLI gives you borg list, borg diff, borg mount and borg extract with full flags, pipeable into whatever you want. Borg UI exposes the workflows its authors built, and the README does not claim full flag parity. If you regularly reach for a Borg option the UI does not surface, you will end up in a shell anyway, and now you have two places to look. The honest comparison is not Borg UI against a competitor; it is Borg UI against the shell you already use.
Licence and the upgrade decision
Borg UI is AGPL-3.0. For a self-hosted deployment where you run the software for yourself, that is unremarkable. It becomes a consideration if you intend to offer the interface to others as a network service, or to modify and redistribute it, because the AGPL's source-availability condition attaches to network use. That is a description of the licence, not legal advice; read the LICENSE file and talk to someone qualified if you are building a product on it. On upgrades, the material supports only a modest claim: releases are frequent, the project is not archived, and the last push is recent. There is no migration guide in the supplied material, and /data holds the application state, so a container image swap is not automatically a safe upgrade. Back up the borg_data volume before you change tags, and read the release notes for the tag you are moving to. The one thing you can verify cheaply before adopting is whether the Borg binary inside the image can read your existing repositories and whether the app stores passphrases in a form you are prepared to protect. Those two answers decide more than the dashboard screenshots do.
Editorial conclusion
Adopt Borg UI if you already run Borg on a home server, NAS or single VM and want schedules, archive browsing and restore flows in a browser instead of shell history. Do not adopt it if your threat model treats the backup host as untrusted, or if you need a documented, versioned REST API and a published upgrade path; the README does not supply either. Before you deploy, change the admin/admin123 password, check whether the release you pull is the v2.2.6 stable line or the v2.3.0-alpha.1 pre-release, and confirm that the /data and Borg cache volumes in your docker run line point at storage you actually back up.
Community notes