v0.0.92

What's Changed

• update/figma-colors-and-opencode-installer by @ckakgun in #471
• Add custom folder icons with an icon picker dialog by @heym-coder in #472
• update/version-and-docker-named-volume by @mbakgun in #473

---

Breaking change: PostgreSQL now uses a Docker named volume

Heym used to store its database in the ./data/postgres folder on your machine. It now stores it in a Docker volume named heym-postgres-data.

You need to migrate before your next deploy. Nothing happens automatically and nothing is deleted. Heym refuses to start rather than come up on an empty database.

Why we changed this

Docker on macOS and Windows does not pass PostgreSQL the write guarantees it depends on when the database sits in a host folder. On affected systems this shows up as:

• PostgreSQL crashing with PANIC: could not close file ... Input/output error, sometimes several times a day
• The database dropping into recovery after each crash, which stalls every workflow running at that moment
• In the worst case a table left with a missing data page, which breaks every write to it until it is repaired

Linux was never affected, but all platforms now use the same setup.

Migrating with ./deploy.sh

Run this once, then deploy as usual:

./deploy.sh --migrate-pgdata
./deploy.sh

• ./deploy.sh now stops before it builds anything if it finds the old folder, so you cannot accidentally start on an empty database.
• Your ./data/postgres folder stays where it is as a backup. Delete it once you have confirmed your workflows are intact.
• If any step fails the new volume is removed, so you can never end up deploying a half-migrated database.
• Expect a short outage while the copy and the index rebuild run.

Migrating a GHCR image setup

The release image does not include a database, so the PostgreSQL behind your DATABASE_URL is yours to move. Running & Deployment has the commands step by step.

Two things to watch:

• Give each Heym deployment on the same machine its own volume name. Two instances pointed at heym-postgres-data would end up sharing one database.
• Start the migrated database with the same PostgreSQL image you were using before. Extensions such as pgvector live inside the image rather than in your data folder, so a database that uses them will fail under a plain postgres:16 image.

Why the migration also rebuilds indexes

Copying a data folder copies it exactly, including any damage the old setup left behind. That damage usually takes the form of index entries pointing at rows that are no longer there, and pg_amcheck reports a clean result even when it is present, so a passing check is not proof your database is healthy.

--migrate-pgdata therefore rebuilds every index after the copy. That repairs those entries, though it cannot bring back data pages that were already lost.

If your database is large and you are confident it is healthy, skip the rebuild with ./deploy.sh --migrate-pgdata --skip-reindex.

Using ./run.sh for local development

Nothing to do. Your existing database container and its data are reused exactly as before.

Full details in Running & Deployment.

---

Full Changelog: v0.0.91...v0.0.92