Borg-UI

Name of the Script

Borg-UI

Script Type

CT (LXC Container)

Does this script support arm64?

arm64 supported

📋 Script Details

Web frontend for BorgBackup — create and browse repositories, schedule backups, inspect archives, restore files, without the borg command line. Requested in discussion #10581.

Initially dismissed as Docker-only — that was wrong. The repo ships pyproject.toml, requirements.txt and app/main.py; the Dockerfile is packaging, not a constraint.

Stack: FastAPI backend + Vite frontend. npm ci && npm run build in frontend/, then uv pip install -r requirements.txt into a venv.
Start command taken from the upstream entrypoint.sh: gunicorn app.main:app --worker-class uvicorn.workers.UvicornWorker on 8081.
borgbackup and openssh-client are installed alongside — the UI shells out to borg, and remote repositories need SSH.
ENABLE_STARTUP_LICENSE_SYNC=false so the container does not phone home to license.borgui.com on every start. Documented, flip it if you hold a paid licence.
Note: the container backs up only what it can see — directories have to be mounted into the LXC.

Not implemented: the separate agent/ component (borg-ui-agent on PyPI), which runs on the machines being backed up. That is a distinct deliverable and arguably an addon rather than part of this container.

Source: https://github.com/karanhudia/borg-ui

The Borg-UI script is ready for testing:

bash -c "$(curl -fsSL https://github.com/community-scripts/ProxmoxVED/raw/main/ct/borg-ui.sh)"

Create your account through the web UI at http://:8081 on first visit.
This container backs up what it can see. Mount the directories you want to protect into the LXC, and for remote repositories deploy an SSH key from the UI to the target host.
ENABLE_STARTUP_LICENSE_SYNC is set to false in /opt/borg-ui/.env so the container does not contact the upstream licence service on every start. Set it to true if you use a paid licence.
Application data lives in /opt/borg-ui_data. The Borg repositories themselves are wherever you point them - those are the ones that actually matter for backups.

Note: This is not in the official repo yet—it's just a dev version! After merging into ProxmoxVE, it will need to be recreated.

Discord testing thread: https://discord.com/channels/1302816934508630047/1534101428753142011

on first screen says password incorrect, so cannot enter webui. tried reinstall twice. as advertised create credentials seems to have issue. once did default install and once used advanced install to see if can correct. best regards

default login is admin/admin123

on first screen says password incorrect, so cannot enter webui. tried reinstall twice. as advertised create credentials seems to have issue. once did default install and once used advanced install to see if can correct. best regards

sorry, forgot to add it, its added now in website. Next refresh its displayed

@MickLesk

Installed throught the community script without problem. Login (with subsequent password change) was also ok and borg-ui app looks to be working well.
Howevever there is some discrepancy:

community scripts log during installation: Deployed: borg-ui (2.2.6)
borg-ui version in web after installation: UI 2.2.3

@MickLesk Thanks for your work.

Borg1 version is also lower 1.4.0 with borg-ui 2.2.3. It should be B1 1.4.4. in borg-ui 2.2.6 (these are the versions in my production docker borg-ui:latest).

I think thats an bug in the package.json ^^ (yes it is, i take a look in tarball) - so its upstream related. For the 2.3.0 it seems ok

Thanks.
Any ETA when released from TESTING?

BTW I dug into this and it looks like the bug is in the community script, not upstream's package.json:

The UI's version comes from the backend, not frontend/package.json — SidebarVersionInfo.tsx just renders systemInfo.app_version from an API call. That value is produced by get_runtime_app_version():

python
app_version: str = "2.2.3"   # stale hardcoded fallback

def get_runtime_app_version() -> str:
    version_file = Path("/app/VERSION")
    try:
        file_value = version_file.read_text().strip()
        if file_value:
            return file_value
    except FileNotFoundError:
        pass
    return os.getenv("APP_VERSION", settings.app_version)

Priority is: /app/VERSION file → APP_VERSION env var → hardcoded "2.2.3".

Docker works because the Dockerfile uses WORKDIR /app, does COPY VERSION ./VERSION (which is 2.2.6 at that tag), and also sets ENV APP_VERSION. So /app/VERSION always exists and is correct.

The LXC script doesn't, because install/borg-ui-install.sh deploys the source tarball to /opt/borg-ui, not /app — so /app/VERSION never exists there. The script also never sets APP_VERSION in /opt/borg-ui/.env (it only writes PORT, ENVIRONMENT, TZ, DATA_DIR, ENABLE_CRON_BACKUPS, ENABLE_STARTUP_LICENSE_SYNC). So it falls through both checks and hits the stale hardcoded "2.2.3" default — exactly what I reported.

fetch_and_deploy_gh_release already caches the fetched tag in /root/.borg-ui, so the fix should just be adding to the install/update script's .env:

APP_VERSION=$(cat /root/.borg-ui)

Worth checking whether the same root cause (a runtime-file lookup that only exists inside the Docker image) applies to the Borg1/Borg2 version fields too, since those were also reported as stale (B2 is not shown at all in LXC).

Hi, Borg UI founder and maintainer here. Thank you for putting this together and for the careful testing and investigation.

The next stable Borg UI release will fix the displayed app version in the LXC installation. It now resolves VERSION from the installed application directory, so it will work from /opt/borg-ui as well as Docker's /app.

The Borg version discrepancy is separate. The LXC script currently installs Debian's borgbackup package, while our Docker image ships both Borg 1 and Borg 2. To keep the LXC installation feature-equivalent, it should install both borg and borg2.

The intended versions are maintained in our docker/runtime-base.env file. We would like the LXC installer and its update path to use that as the source of truth rather than carrying independent version numbers.

What would be the most maintainable way for the Community Script to consume those versions and update the binaries safely with each Borg UI update? We are happy to provide a small manifest or installer from our side if that would make the integration cleaner.

Thanks again. We appreciate the work and are happy to help test the next iteration.

@MickLesk

Hi @MickLesk - any progress on this? The developer of Borg-UI is available to help you build the script, and I’m available to help you test it on three Proxmox machines.

Should all available since some days. Did you Test it?

@karanhudia

Should all available since some days. Did you Test it?

Oh, you already implemented everything @karanhudia instructed you to do?

yep, since 8days and 4 days before a little fix

yep, since 8days and 4 days before a little fix

Great, installed it from scratch - all versions (UI/B1/B2) are on the right numbers now.
Will test it more with the real backup jobs and will let you know.

Installation went smoothly 👍

Only ran into a small issue when setting up the Hetzner StorageBox as a remote machine. Seems like the SSH key wasn’t transferred. Not sure if that’s an issue with Borg-UI itself or something related to the helper script installation (maybe different paths compared to the Docker setup?). Didn’t dig into it any further.

After manually adding the SSH key to the StorageBox, everything worked flawlessly. Initial backup of ~1 TB went through without any issues, and restore + mounting work fine as well.

LXC script works fine for me as well:

scheduled offsite SSH backup plan execution - OK
browsing of archives (both from Full and Observer only repositories) - OK
repository Info - OK
repository Check - OK
repository Prune - OK
repository Compact - OK
apprise notifications - OK

A PR has been created for borg-ui: community-scripts/ProxmoxVE#17258

Merged with #17258 in ProxmoxVE

Files deleted with PR #2265

Navigation Menu

Repository navigation

Borg-UI #2133

Name of the Script

Script Type

Does this script support arm64?

📋 Script Details

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Borg-UI #2133

Description

Name of the Script

Script Type

Does this script support arm64?

📋 Script Details

Activity

github-actions commented on Aug 4, 2026

randall11GB commented on Aug 13, 2026

baloo2 commented on Aug 28, 2026

MickLesk commented on Aug 28, 2026

baloo2 commented on Aug 28, 2026

baloo2 commented on Aug 28, 2026

MickLesk commented on Aug 28, 2026

baloo2 commented on Aug 28, 2026

baloo2 commented on Aug 28, 2026

karanhudia commented on Sep 3, 2026

baloo2 commented on Sep 11, 2026

MickLesk commented on Sep 11, 2026

baloo2 commented on Sep 11, 2026

MickLesk commented on Sep 11, 2026

baloo2 commented on Sep 11, 2026

PeewX commented on Sep 14, 2026

baloo2 commented on Sep 14, 2026

github-actions commented on Sep 14, 2026

MickLesk commented on Sep 14, 2026

github-actions commented on Sep 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions