Updates

You update Lalabase by pulling the new image and running migrations.

Before updating

Always back up first

Take a fresh backup before every update. Database migrations are not always backward-compatible.

Performing the update

# Pull the new version
docker compose pull

# Restart containers with the new image
docker compose up -d

# Run migrations
docker compose exec web bin/rails db:migrate

Data tasks after the migration

Some updates ship a one-off data task alongside the migrations. It is kept separate because it rewrites data rather than schema, and it belongs immediately after db:migrate. All of these tasks are idempotent: a second run costs nothing.

This update ships two. The operator switch for code indexing is now called code_indexing_enabled; it used to be named after a surface that no longer exists. The task copies the old value into the new column:

docker compose exec web bin/rails organisations:backfill_code_indexing DRY_RUN=1
docker compose exec web bin/rails organisations:backfill_code_indexing

Skip this run and code indexing switches itself off

The rename spans three versions. The middle one reads both columns so nothing falls over. Skip the run and install the version after that, and your organisations lose code indexing silently: the new column is empty and the old one is no longer read. Running the task fixes that at any later point, and a second run costs nothing.

Codebase imports. The mappings of a CodebaseHQ import now belong to the organisation that imported. Before, one organisation's import could pick up tickets, billing groups and people of another organisation when both had loaded the same export. The task assigns the existing mappings and lists imported time entries that an earlier import linked across organisations; it does not change those entries:

docker compose exec web bin/rails codebase_import:scope_mappings DRY_RUN=1
docker compose exec web bin/rails codebase_import:scope_mappings

Run it before the next import

Until this run a new import does not see the old mappings and creates already imported tickets again. People who cannot be assigned to exactly one organisation stay unassigned; running the user import again in that organisation maps them by e-mail.

Mind the architecture

Lalabase runs on x86_64. If you build your own images, always build them on the target architecture — native extensions are not portable between ARM and x86_64.

Rollback

If something goes wrong, roll back to the previous image tag and restore the backup if needed. In production, pin specific version tags instead of latest so rollbacks stay reproducible.

One exception concerns the help texts the assistant reads. Lalabase never syncs them back to older files by itself, so that a process of the old version cannot turn them back during an update. After a rollback the assistant therefore keeps reading the newer texts until you sync them:

docker compose exec web bin/rails product_knowledge:sync