When setting up under docker using a managed database from DigitalOcean, the startup hangs

[AlexEscalante]

I am trying to setup Twenty in a DigitalOcean droplet using a managed Postgres database. The database setup, which includes configuring a certificate, seems to be working, but when the docker container starts, it hangs showing only these logs:

Running database setup and migrations...
Database appears to be empty, running migrations.
Performed 'create schema "public"' successfully
Performed 'create schema "core"' successfully
Performed 'create extension "uuid-ossp"' successfully
Performed 'create extension "unaccent"' successfully
Performed 'create immutable unaccent wrapper function' successfully

I can see in the database that the ' core` schema is created, but no tables appear.

I have another instance running much like this, but on my local server, the database is also local and shared with other processes and everything is running fine under Coolify

The only difference should the Postgres instance, which in this case is managed and requires a certificate, so... do you have any ideas?

[sonarly]

🟠 Sonarly Analysis — High Severity

Migration process stays alive after database setup

The container completes the schema and extension setup, but the setup process never exits, so TypeORM migrations are never started. This blocks first-time initialization against an empty PostgreSQL database.

Root Cause

The proximate failure is that packages/twenty-server/src/database/scripts/setup-db.ts initializes rawDataSource, executes the five setup queries, and then returns without calling rawDataSource.destroy() or otherwise terminating the process. The datasource in packages/twenty-server/src/database/typeorm/raw/raw.datasource.ts creates a PostgreSQL connection pool but does not configure allowExitOnIdle; unlike the main core datasource, it has no pool-exit configuration and no shutdown path. The idle PostgreSQL client therefore remains referenced by the Node process.

The Docker entrypoint invokes yarn database:init:prod when the core schema is absent (packages/twenty-docker/twenty/entrypoint.sh). That script is defined as:

node dist/database/scripts/setup-db.js && yarn database:migrate:prod --force --include-slow

Because the commands are chained with &&, the migration command cannot start until setup-db.js exits. The reported logs end immediately after create immutable unaccent wrapper function, which is the final setup query in setup-db.ts; this explains why the database contains the core schema but no tables.

The triggering state is an existing but empty managed PostgreSQL database: it has no core schema, so the entrypoint takes the initialization branch. The comparison local installation already has a core schema, so it skips setup-db.js and does not expose the lifecycle bug. The managed provider itself is not proven to be the cause: all reported setup statements succeeded, which demonstrates that the connection had already authenticated and completed the relevant DDL. The difference that triggers the failure now is database state, not application traffic.

The current raw datasource was introduced in e976a1bdfcb13b64e0755cfc70e4a7ea33047828 and is still used by the setup path; git show confirms that commit added raw.datasource.ts, while git blame places the datasource definition on that commit. No later commit searched in the setup/database history adds teardown for this setup datasource.

Blame commit: e976a1bd by charlesBochet — Uniformize datasources (#5196)

Suggested Fix

Updated the database setup script to close rawDataSource after initialization work completes, including the early-return path when FDW setup is disabled. The datasource is destroyed only when initialized, preventing a teardown error if connection initialization itself fails.

Applied the same lifecycle cleanup to truncate-db.ts, the other direct caller of rawDataSource, so it cannot retain an idle PostgreSQL pool after schema cleanup.

---

Analyzed by Sonarly · View full analysis

[Shinu-Cherian]

Hi @charlesBochet! I investigated this container startup hang and identified the exact root cause and fix:

🔍 Root Cause

In packages/twenty-server/src/database/scripts/setup-db.ts, rawDataSource.initialize() opens a TypeORM database connection pool to run schema and extension queries.

Once setup-db.ts completes the query execution (ending at create immutable unaccent wrapper function), rawDataSource.destroy() is never called to close the active connection pool.

In Node.js (especially over managed PostgreSQL connections with active SSL keepalive sockets like DigitalOcean Managed Postgres), open connection pools prevent the Node.js event loop from exiting. Because the setup-db.ts script process stays alive indefinitely, the container initialization sequence hangs and never reaches the subsequent typeorm migration:run step.

🛠️ Suggested Fix

In packages/twenty-server/src/database/scripts/setup-db.ts, wrap query executions in a try...finally block to ensure rawDataSource.destroy() is always called, followed by process.exit():

rawDataSource
  .initialize()
  .then(async () => {
    try {
      await performQuery(
        'CREATE SCHEMA IF NOT EXISTS "public"',
        'create schema "public"',
      );
      // ... existing queries ...
    } finally {
      if (rawDataSource.isInitialized) {
        await rawDataSource.destroy();
      }
    }
    process.exit(0);
  })
  .catch(async (err) => {
    console.error('Error during Data Source initialization:', err);
    if (rawDataSource.isInitialized) {
      await rawDataSource.destroy();
    }
    process.exit(1);
  });