BorgWarehouse: a web control plane for a central BorgBackup server

The manual work BorgWarehouse removes

BorgBackup gives you deduplicating, client-side encrypted archives. It does not give you a way to hand ten colleagues their own repository on one server. The README describes that work plainly: create a system user, attach an SSH key, set a quota, carve out storage, and repeat for every repository. Each add, edit or delete is a terminal session, and each one is a chance to mistype a path or forget a quota. BorgWarehouse targets exactly that layer. Its stated promise is that you create a repository in a few clicks, hand the ready-to-paste SSH command to the client, and stop touching the terminal for routine repository changes. The audience is therefore narrow and specific: the person who already runs BorgBackup on a server and is tired of provisioning it by hand. If you have one laptop backing up to one external disk, this project has nothing to offer you. It is infrastructure for a shared repository host, not a desktop backup tool.

What the server actually manages, and what it refuses to

The README draws a boundary and repeats it: BorgWarehouse manages the server side (repositories, users, SSH access, quotas, monitoring) and is not meant to take over client-side responsibilities. It never asks for, stores or has access to the repository passphrase. Backups are encrypted on the client before they reach the server, so the application cannot read, decrypt or browse repository contents. The README states that any feature requiring the passphrase will simply never be built. That is a design constraint with real consequences. You get provisioning and health signals; you do not get a file browser, a restore button or a preview of what is inside an archive. Recovery stays a Borg operation performed where the key lives. For an operator this is the right shape, because the web UI holds no secret that would make a compromise of the server equivalent to a compromise of the backups. It also means the UI cannot tell you whether the data inside a repository is any good, only whether the repository is reachable and recently written to.

Repository lifecycle: quotas, mounts and append-only

Each repository gets its own storage quota, and each can be placed on a different mounted storage. The README lists SSHFS, NFS, SMB/CIFS, a dedicated disk and an rclone mount as options, selectable from the UI at creation time, with a live reachability check. That check matters: pointing a repository at a mount that is not currently available is a common failure in self-hosted setups, and doing it at creation time is cheaper than discovering it during a backup window. Append-only mode is offered per repository to protect backups against ransomware or a compromised client. The README does not spell out the interaction between append-only and your retention policy, and that is the question to settle before enabling it broadly. Borg pruning and compaction need to remove data; an append-only repository is designed to prevent exactly that from a client. How BorgWarehouse layers that on top of Borg is documented on the project site rather than in the README, so read the docs page for append-only before you turn it on for repositories you intend to prune on a schedule.

Monitoring, alerts and where the signals come from

The dashboard shows a real-time status per repository (healthy or down) and supports a no recent backup alert driven by a per-repository threshold. Notifications go out over SMTP email, through Apprise (which the README says reaches 100+ services including Discord, Telegram, Slack, Gotify and ntfy), or as webhooks with an optional custom secret header so the receiver can validate the payload. Read the alert semantics carefully before you trust them. A healthy status is a statement about reachability and recency, not about the integrity of the archive. A client that runs, connects, writes a small archive and exits will look healthy. A client whose cron job silently stopped will show up as a no recent backup alert once the threshold passes, which is the more useful signal of the two. Set the threshold per repository rather than globally, because a nightly database dump and a weekly archive have different acceptable gaps.

Getting it running and the API surface

The README gives one install command: curl -fsSL https://raw.githubusercontent.com/Ravinou/borgwarehouse/main/docker/install.sh | bash. The project ships as a single Docker image, borgwarehouse/borgwarehouse on Docker Hub, and the full documentation lives at borgwarehouse.com with the introduction under /docs/prologue/introduction/. First run goes through a setup wizard and the README states there are no default credentials, so there is no shipped admin password to forget to change. Authentication supports local accounts and SSO via OAuth or OIDC with GitHub, Google, Microsoft, GitLab or any generic OIDC provider, plus account linking to an existing local account and an optional mode that disables password login entirely. There is an admin tool to reset a password or revoke sessions. For automation the README describes a versioned and idempotent REST API covering the same operations as the UI. Idempotent is the claim worth verifying against the docs for the specific endpoints you script, because it determines whether a retried request creates a second repository or reconciles the existing one. The README does not enumerate endpoints, so treat the API reference on the project site as the source of truth.

The operational cost you are signing up for

BorgWarehouse provisions system users and SSH access on the host, which means it needs privileges that a plain web application does not. That is the trade: convenience in exchange for a service with a meaningful footprint on the machine it runs on. The README does not describe the privilege model, how the application talks to the system, or what isolation exists between the web process and the accounts it creates. If you are evaluating this for a shared or multi-tenant host, that is the gap to close first, by reading the deployment documentation and the container's configuration rather than assuming. On upgrades, the release history shows frequent patch releases (3.6.1, 3.6.2 and 3.6.3 within roughly two weeks in August and September 2026), which is normal for an actively developed project but implies you should be comfortable redeploying the container regularly and reading release notes before you do. The licence is AGPL-3.0. If you only self-host it for your own organisation, that is the ordinary case. If you intend to offer it to third parties as a hosted service, the network-copyleft terms of AGPL-3.0 are the thing to have your own counsel review. Nothing here is legal advice.

Where it is the wrong tool, and what to use instead

The clearest wrong fit is a team that wants one product to install on the laptop and one dashboard to restore from. BorgWarehouse is deliberately half of that: the server half. If your requirement includes browsing archive contents, restoring a single file from a web page, or letting the backup server hold the encryption key so it can verify data, this project will not do it and the README says it never will. For that shape of problem, look at a client-and-server backup suite with its own agent and restore interface, such as Vorta for the desktop Borg client, or a different product family entirely like Restic with a REST server and a web front end. The difference in approach is where the key lives. BorgWarehouse keeps the passphrase on the client and treats the server as a storage and access-control layer; a suite that offers server-side restore browsing has to hold or receive key material, which is a different threat model. Neither is wrong. They answer different questions, and picking the wrong one shows up the first time you need to restore.

Who should adopt it and what to check first

Adopt it if you already run BorgBackup against a central repository host and the recurring cost is provisioning and drift: new machines, new SSH keys, quota changes, and the quiet question of which client stopped backing up. The per-repository quota, storage mount selection with a reachability check, append-only option and no recent backup alerts map directly onto that work, and the REST API gives you a path to drive it from configuration management instead of clicking. Do not adopt it if you need the server to hold keys, browse archives or perform restores, or if you are not prepared to run a privileged service next to the accounts it manages. Before you commit, verify four things against the project documentation rather than this article: the exact install and upgrade path for your host, the append-only semantics versus your pruning schedule, the privilege model the container expects, and the REST API's idempotency guarantees for the endpoints you plan to automate. Each of those is a decision the README leaves to the docs, and each one is cheaper to answer before the first repository exists than after.

Editorial conclusion

Adopt BorgWarehouse if you already run BorgBackup and the bottleneck is provisioning: creating system users, attaching SSH keys, carving storage and tracking which client stopped backing up. Skip it if you want a backup product with a client agent, restore browser or passphrase custody, because the README states the project will never ask for your repository passphrase. Before committing, verify the documented install path on your host, confirm your Borg version and storage mount type against the docs, and check whether the append-only setting matches how you plan to prune.

Official sources

1. License: AGPL-3.0
2. Project website
3. Ravinou/borgwarehouse on GitHub
4. README
5. Releases