https://brick-work.app/changelog/2026-11-10T00:00:00ZUlf Weihboldtag:brick-work.app,2026-11-10:1.0.12026-11-10T00:00:00Z

A fix release: fresh containers set themselves up on first start and no longer log the gunicorn control-socket error. The schema stays 4.2, so a 1.0.0 collection needs no upgrade step, and going back means starting 1.0.0 on the same file. The published image is ghcr.io/ulef1005/brick-work:1.0.1; a new container no longer needs the console brickwork setup step. Back up brickwork.db and secret.key before you upgrade, as always.

tag:brick-work.app,2026-11-09:1.0.02026-11-09T00:00:00Z

The first release after milestone B: its maintainer's real collection was set up from scratch through **Get started** on a test install, and every workflow ran on it. The schema stays 4.2, so a 0.9.0 collection needs no upgrade step, and going back to 0.9.0 means starting it on the same file. It is the first release whose compose.yaml pulls the published image, ghcr.io/ulef1005/brick-work:1.0.0 (amd64 and arm64, with build provenance and an SBOM): install and upgrade with docker compose pull; 0.9.0 and older still build with docker compose build (Upgrade Brick Work). Back up brickwork.db and secret.key before you upgrade, as always.

tag:brick-work.app,2026-11-05:0.9.02026-11-05T00:00:00Z

The first stability release (milestone 1.0): a stable schema with tested upgrades from 0.5.x, a written upgrade and backup guide, and the first published container image, ghcr.io/ulef1005/brick-work (amd64 and arm64; see Releases and the container image). A 0.8.x collection (schema 4.1) is upgraded in place when 0.9.0 first opens it read-write: three columns are added and nothing else changes. The upgrade is one-way: 0.8.x cannot open a 4.2 file and stops with *a 3.3 file must be migrated*; ignore that hint, which is meant for 3.3 files. So back up brickwork.db and secret.key before you upgrade, and to go back, restore that backup (Upgrade Brick Work, Back up and restore). catalogue.db is not touched.

tag:brick-work.app,2026-11-04:0.8.12026-11-04T00:00:00Z

Two fixes found while setting up and testing milestone B. No schema change: a 0.8.0 collection opens as it is, and going back to 0.8.0 needs no restore. Keep the new secret.key with brickwork.db in your backups.

tag:brick-work.app,2026-11-03:0.8.02026-11-03T00:00:00Z

Milestone A, onboarding: a fresh install reaches its own collection through one guided flow, **Get started**. No schema change: a 0.7.0 collection (schema 4.1) opens as it is, and going back to 0.7.0 needs no restore. See Bring your collection in from another app and Settings and maintenance.

tag:brick-work.app,2026-11-03:0.7.02026-11-03T00:00:00Z

A wish gets a maximum price with box, which brings schema 4.1. A 0.6.0 collection (schema 4.0) is upgraded in place when 0.7.0 first opens it read-write. The upgrade is one-way: 0.6.0 cannot open a 4.1 file, so back up brickwork.db before you upgrade. To go back, restore that backup (Back up and restore).

tag:brick-work.app,2026-10-28:0.6.02026-10-28T00:00:00Z

The data-model release: the collection moves to schema 4.0 with a separate local catalogue, and the API to v2. **Breaking:** API v1 answers 410 except /api/v1/health; clients move to /api/v2 (API v2). A 0.5 collection is moved with brickwork migrate4 on a copy first (CLI); the 3.3 file is never changed.

tag:brick-work.app,2026-10-18:0.5.02026-10-18T00:00:00Z

The first public release: a self-hosted web app for a brick collection that helps at the table, not only in the inventory. It is pre-1.0; the schema and the API can still change between minor versions.