`homolog` image cannot start: Prisma 7 migrations fail with "datasource.url property is required"

Start with the image's package.json, runWithProvider.js, and prisma/postgresql-schema.prisma, then reproduce the migration command shown in the report. Trace how the image is built and configured around the missing prisma.config.ts; done means the homolog container completes PostgreSQL migrations and starts serving without changing the existing database.

Summary

The evoapicloud/evolution-api:homolog image (Evolution 2.4.0, baileys
7.0.0-rc13) never finishes startup. It enters a crash loop during the migration
step, before serving anything. The same host, same database and same environment
run v2.3.7 normally — reverting the tag brings the service straight back.

Environment

What happens

The container restarts in a loop, logging:

Deploying migrations for postgresql
> node runWithProvider.js "rm -rf ./prisma/migrations && cp -r ./prisma/DATABASE_PROVIDER-migrations ./prisma/migrations && npx prisma migrate deploy --schema ./prisma/DATABASE_PROVIDER-schema.prisma"
Prisma schema loaded from prisma/postgresql-schema.prisma.
Error: The datasource.url property is required in your Prisma config file when using prisma migrate deploy.
Error executing command: rm -rf ./prisma/migrations && cp -r ./prisma/postgresql-migrations ./prisma/migrations && npx prisma migrate deploy --schema ./prisma/postgresql-schema.prisma
Migration failed

Cause, as far as we could inspect

Inside the image, the datasource block declares no url:

datasource db {
  provider = "postgresql"
}

Prisma 7 expects the connection URL to come from a prisma.config.ts, and that
file does not exist in the image:

$ docker run --rm --entrypoint sh evoapicloud/evolution-api:homolog \
    -c 'ls -la /evolution/prisma.config.* 2>/dev/null || echo "no prisma.config"'
no prisma.config

So there is no place for the URL to come from, and migrate deploy refuses to
run regardless of how the environment is configured. Setting
DATABASE_CONNECTION_URI (the 2.3.x variable) has no effect on this path.

Steps to reproduce

1. Take any working v2.3.7 deployment with PostgreSQL.
2. Change only the image tag to homolog.
3. docker compose up -d <service>.

Result: crash loop with the error above, no HTTP listener.

Notes

• Migrations fail before touching the database, so reverting the tag is
  clean. We confirmed our schema intact afterwards: 37 tables, row counts
  unchanged, instance reconnected as open.
• The tags for the 2.4 line are published without the v prefix
  (2.4.0-rc1, 2.4.0-rc2, homolog), unlike the 2.3 line (v2.3.7). That is
  easy to miss when looking for v2.4*.
• Worth noting for anyone testing 2.4.0-rc2 as an alternative: it ships the
  same baileys 7.0.0-rc.9 as v2.3.7, so it is not a way to pick up baileys
  fixes.