#Migrations not running automatically when upgrading Docker image - manual schema fixes required

1 messages · Page 1 of 1 (latest)

vale cape
#

When upgrading Twenty via Docker between versions (e.g., v1.16.7 → v1.17.x → v1.18.x), the database migrations don't run properly:

  1. New columns defined in code entities aren't created automatically
  2. No entries added to _typeorm_migrations table
  3. Workspace version doesn't auto-update

Steps to reproduce for me:

  1. Update TAG in .env file to new version (e.g., TAG=v1.18.1)
  2. Run docker compose pull && docker compose up -d
  3. Check logs - see errors like "column X does not exist"

Workaround (with coding agents) after each upgrade, I manually:

  1. Check server logs for errors: docker logs server --since 2m | grep "does not exist"
  2. Add missing columns: ALTER TABLE core.workspace ADD "columnName" TYPE;
  3. Update version: UPDATE core.workspace SET version = 'X.Y.Z';

Question:

  • How can we escape this manual migration hell?
split galeBOT
#
Searched Docker upgrade database migration version
Found 6 results
#
Searched upgrade Twenty self-hosting docker compose
Found 6 results
#
Searched upgrade guide database migrate prod command upgrade steps
Found 5 results
#

Let me search for information about Docker upgrades, database migrations, and the proper upgrade process for Twenty.This is a well-known pain point. The issue is that simply pulling a new image and restarting is not enough — Twenty requires you to explicitly run migration commands after updating the image. Here is the documented upgrade process:

Proper Upgrade Steps (Docker Compose)

1. Back up your database first:

docker exec -t {db_container_name_or_id} pg_dumpall -U {postgres_user} > databases_backup.sql

2. Update the image tag in your .env and pull:

docker compose pull
docker compose up -d

3. Run the database structure migration:

docker exec -it {server_container} yarn database:migrate:prod

This applies migrations to the core and metadata schemas and populates the _typeorm_migrations table.

4. Run the version-specific upgrade command:

docker exec -it {server_container} yarn command:prod upgrade-X.YZ

For example, for upgrading to v0.35: yarn command:prod upgrade-0.35. This handles data migration for all workspaces and updates the workspace version.

Why your current approach breaks

Steps 2 and 3 above are the ones you are missing. The new Docker image contains the migration files and upgrade commands, but they are not executed automatically on container startup. You need to run them manually after the container is up.

Important notes

  • Upgrade one version at a time. If you are going from v0.32 to v0.35, you need to go v0.32 -> v0.33 -> v0.34 -> v0.35, running the migrate and upgrade commands at each step.
  • Always back up before each upgrade.
  • Check the upgrade guide for each specific version, as some versions have additional steps or breaking changes.

This should get you out of the manual ALTER TABLE cycle entirely — the migration commands handle all schema changes, new columns, and workspace version updates for you.

These pages cover the full details:

vale cape
#

do I need to run these commands in the next version?

for example:

  1. Update TAG in .env (e.g., TAG=v1.19)
  2. docker compose pull
  3. docker compose down && docker compose up -d

docker exec twenty-server-1 yarn database:migrate:prod
docker exec twenty-server-1 yarn command:prod upgrade
docker exec twenty-server-1 yarn command:prod cache:flush

in the mean time docs says:
v0.55
Upgrade your Twenty instance to use v0.55 image
You don’t need to run any command anymore, the new image will automatically care about running all required migrations.