[GH-ISSUE #418] Add updater script for non-Docker systemd installs #259

Closed
opened 2026-05-06 12:27:39 +02:00 by BreizhHardware · 3 comments

Originally created by @uefigs139 on GitHub (Feb 17, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/418

Originally assigned to: @maziggy on GitHub.

Problem or Use Case

I run Bambuddy on Debian 12 in an LXC on Proxmox (systemd install, non-Docker).

Updates currently require several manual steps (stop service, git update, pip update, frontend rebuild, restart service). It works, but it is easy to miss a step and it is slower than necessary.

A one-command updater for non-Docker installs would make maintenance much easier and reduce update errors for LXC/systemd users.

Proposed Solution

Add an official updater script for non-Docker installs (for example scripts/update.sh) with this flow:

  1. Stop bambuddy.service
  2. git fetch --prune origin && git reset --hard origin/<branch>
  3. venv/bin/pip install -r requirements.txt
  4. cd frontend && npm ci && npm run build (if frontend exists)
  5. Start service and print status
  6. If update fails, attempt to start the service again

Optional: support env vars for path/service/branch overrides so users can adapt different install layouts.

Alternatives Considered

Manual updates and local custom scripts.

I currently use a local helper script (bbup) that performs the update steps. It works well, but this functionality would be better maintained upstream so users have a standard, documented update path.

Feature Category

Print Archiving

Priority

Nice to have

Mockups or Examples

Summary

Add scripts/update.sh to provide a one-command updater for non-Docker installs (systemd/LXC/bare-metal).

Why

Users running Bambuddy outside Docker currently perform several manual steps to update:

  • stop service
  • pull/reset repo
  • update Python dependencies
  • rebuild frontend
  • restart service

This script standardizes that process and reduces update mistakes.

What this adds

  • scripts/update.sh with:
    • configurable defaults via env vars:
      • INSTALL_DIR (default /opt/bambuddy)
      • SERVICE_NAME (default bambuddy)
      • BRANCH (default main)
      • VENV_PIP (default $INSTALL_DIR/venv/bin/pip)
      • FRONTEND_DIR (default $INSTALL_DIR/frontend)
    • update flow:
      1. stop service
      2. fetch/reset to origin/$BRANCH
      3. install Python deps from requirements.txt
      4. run npm ci && npm run build when frontend exists
      5. start service and show status
    • failure handling: if any step fails, attempts to restart the service

Docs

Adds README section showing:

  • install command for updater script
  • manual run command (bambuddy-update)
  • optional env var overrides

Tested

Tested on:

  • Debian 12 (bookworm)
  • Proxmox LXC
  • systemd service: bambuddy.service
  • install path: /opt/bambuddy

Result:

  • successful update from 38641e9 to ac2aaaa
  • Python deps updated
  • frontend build completed
  • service restarted and running

Contribution

  • I would be willing to help implement this feature

Checklist

  • I have searched existing issues to ensure this feature hasn't already been requested
Originally created by @uefigs139 on GitHub (Feb 17, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/418 Originally assigned to: @maziggy on GitHub. ### Problem or Use Case I run Bambuddy on Debian 12 in an LXC on Proxmox (systemd install, non-Docker). Updates currently require several manual steps (stop service, git update, pip update, frontend rebuild, restart service). It works, but it is easy to miss a step and it is slower than necessary. A one-command updater for non-Docker installs would make maintenance much easier and reduce update errors for LXC/systemd users. ### Proposed Solution Add an official updater script for non-Docker installs (for example `scripts/update.sh`) with this flow: 1. Stop `bambuddy.service` 2. `git fetch --prune origin && git reset --hard origin/<branch>` 3. `venv/bin/pip install -r requirements.txt` 4. `cd frontend && npm ci && npm run build` (if frontend exists) 5. Start service and print status 6. If update fails, attempt to start the service again Optional: support env vars for path/service/branch overrides so users can adapt different install layouts. ### Alternatives Considered Manual updates and local custom scripts. I currently use a local helper script (`bbup`) that performs the update steps. It works well, but this functionality would be better maintained upstream so users have a standard, documented update path. ### Feature Category Print Archiving ### Priority Nice to have ### Mockups or Examples ## Summary Add `scripts/update.sh` to provide a one-command updater for non-Docker installs (systemd/LXC/bare-metal). ## Why Users running Bambuddy outside Docker currently perform several manual steps to update: - stop service - pull/reset repo - update Python dependencies - rebuild frontend - restart service This script standardizes that process and reduces update mistakes. ## What this adds - `scripts/update.sh` with: - configurable defaults via env vars: - `INSTALL_DIR` (default `/opt/bambuddy`) - `SERVICE_NAME` (default `bambuddy`) - `BRANCH` (default `main`) - `VENV_PIP` (default `$INSTALL_DIR/venv/bin/pip`) - `FRONTEND_DIR` (default `$INSTALL_DIR/frontend`) - update flow: 1. stop service 2. fetch/reset to `origin/$BRANCH` 3. install Python deps from `requirements.txt` 4. run `npm ci && npm run build` when frontend exists 5. start service and show status - failure handling: if any step fails, attempts to restart the service ## Docs Adds README section showing: - install command for updater script - manual run command (`bambuddy-update`) - optional env var overrides ## Tested Tested on: - Debian 12 (bookworm) - Proxmox LXC - systemd service: `bambuddy.service` - install path: `/opt/bambuddy` Result: - successful update from `38641e9` to `ac2aaaa` - Python deps updated - frontend build completed - service restarted and running ### Contribution - [ ] I would be willing to help implement this feature ### Checklist - [x] I have searched existing issues to ensure this feature hasn't already been requested
BreizhHardware 2026-05-06 12:27:39 +02:00
Author
Owner

@maziggy commented on GitHub (Feb 18, 2026):

Thanks for the well-structured request! This makes sense — the manual update dance is error-prone and a standardized script would help all non-Docker users.

A few thoughts before implementation:

  1. git reset --hard — this will silently discard any local modifications. We should either add a confirmation prompt or at least a visible warning before resetting.
  2. Root/sudo check — since the script needs to control systemd services, it should verify permissions upfront rather than failing halfway through.
  3. Backup consideration — might be worth backing up data/ (or at least the database) before updating, in case a migration goes wrong.

Would you be willing to share your existing bbup script as a starting point? Since you've already battle-tested it on Debian 12 / Proxmox LXC, it would save time and ensure the script reflects real-world usage rather than assumptions.

<!-- gh-comment-id:3920084320 --> @maziggy commented on GitHub (Feb 18, 2026): Thanks for the well-structured request! This makes sense — the manual update dance is error-prone and a standardized script would help all non-Docker users. A few thoughts before implementation: 1. git reset --hard — this will silently discard any local modifications. We should either add a confirmation prompt or at least a visible warning before resetting. 2. Root/sudo check — since the script needs to control systemd services, it should verify permissions upfront rather than failing halfway through. 3. Backup consideration — might be worth backing up data/ (or at least the database) before updating, in case a migration goes wrong. Would you be willing to share your existing bbup script as a starting point? Since you've already battle-tested it on Debian 12 / Proxmox LXC, it would save time and ensure the script reflects real-world usage rather than assumptions.
Author
Owner

@uefigs139 commented on GitHub (Feb 18, 2026):

Makes sense. Since you have a backup feature in the settings, I agree the updater script should call that (if available) instead of duplicating backup logic.

For now, here is my original field-tested script exactly as used on Debian 12 / Proxmox LXC. I’m sharing it as a baseline, and I suggest adding your 3 improvements on top:

  1. warning/confirmation before git reset --hard
  2. upfront root/sudo check
  3. call Bambuddy’s built-in backup routine before update

Original script:

#!/usr/bin/env bash
set -Eeuo pipefail

INSTALL_DIR="/opt/bambuddy"
SERVICE_NAME="bambuddy"
BRANCH="main"
VENV_PIP="/opt/bambuddy/venv/bin/pip"
FRONTEND_DIR="/opt/bambuddy/frontend"

log() { printf '[bbup] %s\n' "$*"; }

rollback_start() {
  code="$1"
  log "Update failed. Trying to start service again..."
  systemctl start "$SERVICE_NAME" || true
  exit "$code"
}
trap 'rollback_start $?' ERR

cd "$INSTALL_DIR"
old_commit="$(git rev-parse --short HEAD || true)"

log "Stopping $SERVICE_NAME"
systemctl stop "$SERVICE_NAME"

log "Updating git (origin/$BRANCH)"
git fetch --prune origin
git reset --hard "origin/$BRANCH"

log "Updating Python deps"
"$VENV_PIP" install -r requirements.txt

log "Building frontend"
cd "$FRONTEND_DIR"
npm ci
npm run build

log "Starting $SERVICE_NAME"
systemctl start "$SERVICE_NAME"
systemctl --no-pager --lines=8 status "$SERVICE_NAME"

cd "$INSTALL_DIR"
new_commit="$(git rev-parse --short HEAD || true)"
log "Done: ${old_commit:-unknown} -> ${new_commit:-unknown}"
<!-- gh-comment-id:3920792629 --> @uefigs139 commented on GitHub (Feb 18, 2026): Makes sense. Since you have a backup feature in the settings, I agree the updater script should call that (if available) instead of duplicating backup logic. For now, here is my original field-tested script exactly as used on Debian 12 / Proxmox LXC. I’m sharing it as a baseline, and I suggest adding your 3 improvements on top: 1) warning/confirmation before `git reset --hard` 2) upfront root/sudo check 3) call Bambuddy’s built-in backup routine before update Original script: ```bash #!/usr/bin/env bash set -Eeuo pipefail INSTALL_DIR="/opt/bambuddy" SERVICE_NAME="bambuddy" BRANCH="main" VENV_PIP="/opt/bambuddy/venv/bin/pip" FRONTEND_DIR="/opt/bambuddy/frontend" log() { printf '[bbup] %s\n' "$*"; } rollback_start() { code="$1" log "Update failed. Trying to start service again..." systemctl start "$SERVICE_NAME" || true exit "$code" } trap 'rollback_start $?' ERR cd "$INSTALL_DIR" old_commit="$(git rev-parse --short HEAD || true)" log "Stopping $SERVICE_NAME" systemctl stop "$SERVICE_NAME" log "Updating git (origin/$BRANCH)" git fetch --prune origin git reset --hard "origin/$BRANCH" log "Updating Python deps" "$VENV_PIP" install -r requirements.txt log "Building frontend" cd "$FRONTEND_DIR" npm ci npm run build log "Starting $SERVICE_NAME" systemctl start "$SERVICE_NAME" systemctl --no-pager --lines=8 status "$SERVICE_NAME" cd "$INSTALL_DIR" new_commit="$(git rev-parse --short HEAD || true)" log "Done: ${old_commit:-unknown} -> ${new_commit:-unknown}"
Author
Owner

@maziggy commented on GitHub (Feb 19, 2026):

https://github.com/maziggy/bambuddy/pull/434

<!-- gh-comment-id:3925763590 --> @maziggy commented on GitHub (Feb 19, 2026): https://github.com/maziggy/bambuddy/pull/434
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/bambuddy#259
No description provided.