Upgrades

Arenile follows semantic versioning (MAJOR.MINOR.PATCH). Database migrations are always forward compatible and applied automatically at startup: upgrading means downloading the new version and restarting.

Recommended procedure

1. Read the release notes on the What’s new page (and in the repository’s CHANGELOG.md), especially before a minor or major upgrade.

2. Take a backup:

   cd /opt/arenile
   docker compose exec arenile /arenile backup --out /data/backup/pre-update-$(date +%F).db

3. Upgrade and restart:

   docker compose pull
   docker compose up -d

4. Verify:

   docker compose exec arenile /arenile version
   curl -fsS https://prenota.mio-lido.it/readyz

Pinned version (recommended)

In production pin an exact version in .env and change it yourself when you decide to upgrade:

.env

ARENILE_VERSION=0.4.2

Always the latest

With ARENILE_VERSION=latest (the default) every docker compose pull brings the latest published version. Handy on a trial instance, discouraged in high season.

From source

git fetch --tags && git checkout v0.4.2
make build
sudo systemctl stop arenile
sudo install bin/arenile /usr/local/bin/arenile
sudo systemctl start arenile

In high season

• Upgrade at a quiet time (evening or early morning), never while the cash desk is open.
• Prefer patch releases (fixes) and postpone minor releases to the end of the season, unless they fix security issues.
• During the restart (a few seconds) the public page does not respond: customers halfway through a booking find their hold again until it expires.

Going back

Migrations only go forward: an older version cannot read a newer schema. To go back, restore the backup taken before the upgrade and start the previous version (see Backup and restore).

Tip

arenile migrate status shows applied and pending migrations; with ARENILE_AUTO_MIGRATE=false you can apply them by hand with arenile migrate up before starting the server.

New version notice

When a new version is out, owners and managers see Arenile X is available at the top of the panel, with What’s new and How to update (Docker installs: it leads to this page; remember the backup, then docker compose pull && docker compose up -d) or Download (desktop app and binary). The notice closes with the X and comes back only for the next version. The installed version and the state of the check are also in the user menu, bottom left.

The check is on by default: once a day Arenile reads the public file https://updates.coste360.it/arenile/latest.json. The request contains no data of the beach, no cookie and no identifier: it reveals only the version, edition and operating system in the User-Agent (for example arenile/1.0.1 (server; linux/amd64)) and, like any HTTP request, the IP address to the Coste360 server, which uses this information only for aggregate counts. It is not telemetry: ARENILE_TELEMETRY stays false.

To turn it off set ARENILE_UPDATE_CHECK=false (no network call); ARENILE_UPDATE_URL points it to an internal mirror. When the check fails (no internet, server unreachable) the panel shows no error: the user menu only says “Couldn’t check for updates automatically.”.