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
|
|
| Image |
evoapicloud/evolution-api:homolog (pushed 2026-07-14) |
| Evolution |
2.4.0 |
| Baileys |
7.0.0-rc13 |
| Prisma |
^7.8.0 (from the image's package.json) |
| Database |
PostgreSQL, reachable, already provisioned by v2.3.7 |
| Config |
DATABASE_PROVIDER=postgresql, DATABASE_CONNECTION_URI=<set> |
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
- Take any working
v2.3.7 deployment with PostgreSQL.
- Change only the image tag to
homolog.
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.
Summary
The
evoapicloud/evolution-api:homologimage (Evolution 2.4.0, baileys7.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.7normally — reverting the tag brings the service straight back.Environment
evoapicloud/evolution-api:homolog(pushed 2026-07-14)^7.8.0(from the image'spackage.json)DATABASE_PROVIDER=postgresql,DATABASE_CONNECTION_URI=<set>What happens
The container restarts in a loop, logging:
Cause, as far as we could inspect
Inside the image, the datasource block declares no
url:Prisma 7 expects the connection URL to come from a
prisma.config.ts, and thatfile does not exist in the image:
So there is no place for the URL to come from, and
migrate deployrefuses torun 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
v2.3.7deployment with PostgreSQL.homolog.docker compose up -d <service>.Result: crash loop with the error above, no HTTP listener.
Notes
clean. We confirmed our schema intact afterwards: 37 tables, row counts
unchanged, instance reconnected as
open.vprefix(
2.4.0-rc1,2.4.0-rc2,homolog), unlike the 2.3 line (v2.3.7). That iseasy to miss when looking for
v2.4*.2.4.0-rc2as an alternative: it ships thesame baileys
7.0.0-rc.9asv2.3.7, so it is not a way to pick up baileysfixes.