Elza management scripts

Scripts that install, update, run and back up an Elza instance (PostgreSQL + the Elza application) on a Linux host. One config file (elza-env) holds everything environment-specific, so the same scripts serve DEV, TEST and PROD.

Install

On the target host, as a user with sudo:

curl -fsSL https://get.lightcomp.com/elza/elza-bootstrap.sh | bash -s -- --home /opt/elza

This downloads the script bundle (checksum-verified) into /opt/elza/scripts and seeds the configuration file. Then:

1. Edit /opt/elza/scripts/elza-env — uncomment only the values that differ from the defaults (database, directories, CSC account …).
2. If the file holds the CSC secret, restrict it — but keep it readable for the app user (the backup and health services read it as elza through the file's group; do not use chmod 600):

   sudo chgrp elza /opt/elza/scripts/elza-env
   sudo chmod 640 /opt/elza/scripts/elza-env

3. Check the resolved configuration: /opt/elza/scripts/elza-deploy --show-config
4. Deploy a release: sudo /opt/elza/scripts/elza-deploy --auto (or a specific version: elza-deploy 3.3.15).

Add --channel main to the install command for the latest (snapshot) scripts instead of stable; the choice is remembered for updates.

Upgrading — in more detail

1. Updating the scripts themselves

Re-run the installed bootstrap — no arguments needed. It locates the installation from its own path, keeps the channel it was installed from and never overwrites your elza-env. It tells you whether a new build was installed or you were already current (then nothing is downloaded; safe to run as often as you like):

/opt/elza/scripts/elza-bootstrap.sh

2. Updating the Elza application

sudo /opt/elza/scripts/elza-deploy --auto

The flow is: stop service → pre-update DB backup → activate the new release (atomic symlink switch) → start → verify. The result is reported to the Lightcomp Customer Service Center (CSC) when an account is configured.

• With a CSC account (CUSTOMER_ID + CUSTOMER_SERVICE_SECRET in elza-env), --auto installs the version confirmed for this instance in the CSC portal — confirming there is how you control the rollout.
• Without an account, --auto follows the public channel (stable or testing).
• The pre-update dump (…-preupdate-…dump in /opt/elza/backup) is the rollback anchor; the newest ones are kept regardless of age.

Downgrade warning: switching back to an older release is not a safe rollback by itself — Elza migrates the database schema forward on startup. Restore the matching pre-update dump first.

3. Unattended updates

Install the elza-update service (below), then enable per instance in elza-env:

AUTOUPDATE=on

The timer checks hourly and applies a newly confirmed version outside working hours (default Mo-Fr 06:00-18:00, configurable via AUTOUPDATE_WORKHOURS; set it empty to update any hour — typical for TEST instances, see the preset in elza-env).

Setting up the services (systemd)

The bundle ships unit files in /opt/elza/scripts/systemd/, already rendered at install with your install path and the elza service account filled in — copy and enable, no editing. Each service is a separate decision; install only what the instance needs, in any order.

Application — elza.service

Required on every instance. The unit is pre-rendered (user, working dir and heap come from the profile — heap via HEAP); no editing needed.

sudo cp /opt/elza/scripts/systemd/elza.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now elza.service

Verify: systemctl status elza; application log in the work directory (log/elza.log).

Database backup — elza-backup

Recommended on production. Runs weekly as the app user (BACKUP_AS=dbuser — the DB password is read from elza.yaml), so elza-env must be readable by that user (the chgrp/chmod 640 step in Install). Retention is configured in elza-env (BACKUP_KEEP_DAYS, default 14 days); the schedule is OnCalendar= in the timer.

sudo cp /opt/elza/scripts/systemd/elza-backup.{service,timer} /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now elza-backup.timer
sudo systemctl start elza-backup.service   # run one backup now to verify

Verify: a fresh *.dump + .sha512 appears in /opt/elza/backup.

Health heartbeat — elza-health

Install when the instance has a CSC account (CUSTOMER_ID + CUSTOMER_SERVICE_SECRET in elza-env); without one the service is a harmless no-op. Recommended config in elza-env: HEALTH_URL (e.g. http://127.0.0.1:8080/) so the heartbeat distinguishes "process up" from "really serving", and optionally HEARTBEAT_INTERVAL (default 10m, e.g. 1h). Runs as the app user — elza-env must be readable by it (the chgrp/chmod 640 step in Install).

sudo cp /opt/elza/scripts/systemd/elza-health.{service,timer} /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now elza-health.timer
sudo systemctl start elza-health.service   # send one heartbeat now to verify

Verify locally without sending: /opt/elza/scripts/elza-health --check.

Unattended updates — elza-update

Opt-in. The unit deliberately runs as root (it stops/starts the service; no User= to adjust, no sudo setup) and stays inert until you set AUTOUPDATE=on in elza-env. Related knobs there: AUTOUPDATE_WORKHOURS (default Mo-Fr 06:00-18:00; empty = any hour) and AUTOUPDATE_BACKUP (set off on test/dev to skip the pre-update dump) — see the TEST/DEV preset in elza-env.

sudo cp /opt/elza/scripts/systemd/elza-update.{service,timer} /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now elza-update.timer

Verify: systemctl list-timers 'elza-*' shows the next run; activity: journalctl -u elza-update.service -n 50.

Files