Database migration fails on fresh Docker deployment: relation "galleries" / "site_configs" does not exist

[LucasJay2027]

Hi, I ran into an issue while trying to deploy Jyzrox with Docker Compose on my NAS.

I’m not a developer, so I may not describe everything perfectly, but I’ll include the commands and logs I saw.

Environment

• Deployment method: Docker Compose

• Host: Linux-based NAS

• Project path: /vol1/1000/docker/Jyzrox

• Containers involved:

  • jyzrox-postgres-1
  • jyzrox-redis-1
  • jyzrox-api-1
  • jyzrox-worker-1

PostgreSQL and Redis both seem to start normally.

What happened

After running:

docker compose up -d

the worker container keeps restarting.

The main error in the worker logs is:

relation "site_configs" does not exist

Relevant log:

sqlalchemy.exc.ProgrammingError:
<class 'asyncpg.exceptions.UndefinedTableError'>:
relation "site_configs" does not exist

[SQL: SELECT site_configs.source_id, site_configs.overrides, site_configs.adaptive, site_configs.auto_probe, site_configs.updated_at 
FROM site_configs 
WHERE site_configs.adaptive != $1::JSONB]

I checked the PostgreSQL database manually:

docker exec -it jyzrox-postgres-1 psql -U vault -d vault -c "\dt"

The output was:

Did not find any tables.

I also checked the Alembic version table:

docker exec -it jyzrox-postgres-1 psql -U vault -d vault -c "SELECT * FROM alembic_version;"

The output was:

ERROR:  relation "alembic_version" does not exist

So it looks like the database is empty after the Docker setup.

Manual migration attempt

I also tried running the migration manually:

docker compose run --rm api sh -lc 'cd /app && python -m alembic upgrade head'

It started like this:

INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
INFO  [alembic.runtime.migration] Running upgrade  -> 0001, initial schema (consolidated baseline)
INFO  [alembic.runtime.migration] Running upgrade 0001 -> 0002, add local library patterns and gallery source paths

But then it failed with:

relation "galleries" does not exist

Relevant log:

File "/app/migrations/versions/0002_library_patterns_source_path.py", line 20, in upgrade
    op.add_column("galleries", sa.Column("source_path", sa.Text(), nullable=True))

sqlalchemy.exc.ProgrammingError:
<class 'asyncpg.exceptions.UndefinedTableError'>:
relation "galleries" does not exist

[SQL: ALTER TABLE galleries ADD COLUMN source_path TEXT]

What I expected

Since this was a fresh Docker deployment, I expected the database tables to be created automatically, or at least for the documented Docker setup to complete without the worker repeatedly restarting.

What actually happened

• PostgreSQL starts
• Redis starts
• The database has no tables
• The worker keeps restarting
• Manual Alembic migration also fails because galleries does not exist

Could you please take a look? I’m not sure if I missed a setup step, or if there is something wrong with the fresh Docker migration process.

[patrick3399]

Thanks for the detailed report — this turned out to be a real bug, now fixed in main.

What was wrong

The database schema was only ever created by PostgreSQL's docker-entrypoint-initdb.d mechanism, which runs once when the data directory is first initialized and is silently skipped otherwise. There was no migration step to fall back on, so if that one-shot init didn't run (or a previous partial start left a half-initialized volume), you ended up exactly where you were: a healthy Postgres with no tables and a worker crash-looping on relation "..." does not exist.

On top of that, db/init.sql contained an invalid statement — ALTER TABLE users ADD CONSTRAINT IF NOT EXISTS ..., which isn't valid PostgreSQL syntax. It had gone unnoticed because the file only ran on older databases created before that line was added, but on a fresh database it fails with syntax error at or near "EXISTS".

The fix

• A dedicated one-shot migrate service now owns schema setup. It runs automatically before api/worker start and is idempotent:
  • empty DB → applies the schema, then stamps the migration version
  • existing DB → just applies any pending migrations (no-op if already current)
• The fragile initdb.d mount was removed; the migrate service handles everything.
• The invalid SQL was corrected.

No manual alembic commands are needed anymore.

What to do

Pull the latest main, then since your database never finished initializing (it's empty), do a clean reset and bring it back up:

git pull
docker compose down -v          # safe here — your DB has no data yet
docker compose build
docker compose up -d

Watch the migration run:

docker compose logs migrate     # should end with: Bootstrap complete (init_then_stamp).

Then open http://localhost:35689 — the first visit starts the setup flow. The worker should no longer restart.

⚠️ docker compose down -v deletes the database volume. It's safe in your case because the install never completed, but don't run it once you have data you care about.