Allow to create default user with env variables

[lvde0]

Fixes #4083

[vercel]

@lvde0 is attempting to deploy a commit to the Umami Software Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

This PR replaces the hardcoded admin user seed (previously embedded directly in the initial Prisma migration SQL) with a dynamic approach: a new createDefaultUser() function in scripts/check-db.js that reads DEFAULT_ADMIN_USERNAME and DEFAULT_ADMIN_PASSWORD environment variables at container startup, creating an admin user only when none exists. The Dockerfile is updated to install bcryptjs and uuid as runtime script dependencies.

Key changes and concerns:

• Breaking change for existing deployments (prisma/migrations/01_init/migration.sql): Removing the INSERT statement from an already-applied migration will cause prisma migrate deploy to fail with a checksum mismatch error on all deployments that have already run 01_init. The migration file should be left untouched; the old hardcoded row is harmless because createDefaultUser() already checks for an existing admin before inserting.
• Race condition in createDefaultUser(): The findFirst → create pattern is not atomic. Concurrent container startups can both observe no admin, both attempt to insert the same username, and the second will crash with a Prisma unique-constraint error (P2002) that propagates to process.exit(1).
• No warning for default credentials: When DEFAULT_ADMIN_PASSWORD is unset the well-known default is used silently; a visible log warning would help operators avoid leaving default credentials in production.

Confidence Score: 2/5

• Not safe to merge — modifying the applied initial migration will break prisma migrate deploy on all existing deployments.
• The script-side logic in check-db.js is a sound approach to the feature, but the modification to prisma/migrations/01_init/migration.sql is a hard-breaking change: Prisma records migration checksums and will refuse to deploy if a previously-applied migration has been altered. This single change blocks every operator upgrading from an older version. The race condition in createDefaultUser() adds additional risk in multi-replica deployments.
• prisma/migrations/01_init/migration.sql requires the most attention — the migration should not be modified; the INSERT removal must be handled via a new migration or omitted entirely.

Important Files Changed

Filename	Overview
prisma/migrations/01_init/migration.sql	Removes the hardcoded admin INSERT from the initial migration — this modifies an already-applied Prisma migration and will cause a checksum mismatch error on prisma migrate deploy for all existing deployments.
scripts/check-db.js	Adds createDefaultUser() which reads DEFAULT_ADMIN_USERNAME/DEFAULT_ADMIN_PASSWORD env vars and seeds an admin if none exists; has a TOCTOU race condition in multi-instance deployments and no warning for default credentials.
Dockerfile	Adds bcryptjs and uuid to the script-layer dependencies — correct and minimal change to support the new createDefaultUser logic.

Sequence Diagram

sequenceDiagram
    participant Docker as Docker Container
    participant Script as check-db.js
    participant DB as PostgreSQL

    Docker->>Script: pnpm start-docker
    Script->>Script: checkEnv()
    Script->>DB: checkConnection()
    DB-->>Script: Connected
    Script->>DB: checkDatabaseVersion()
    DB-->>Script: Version OK
    Script->>DB: applyMigration() — prisma migrate deploy
    DB-->>Script: Migrations applied
    Script->>DB: createDefaultUser() — findFirst({ role: 'admin' })
    DB-->>Script: null (no admin found)
    Script->>Script: Read DEFAULT_ADMIN_USERNAME / DEFAULT_ADMIN_PASSWORD env vars
    Script->>Script: bcrypt.hashSync(password, 10)
    Script->>DB: prisma.user.create({ id, username, password, role:'admin' })
    DB-->>Script: User created
    Script-->>Docker: ✓ Admin user created

Loading

_{Last reviewed commit: 1cf30ac}

[aaron3238]

Any updates on this?

[lvde0]

@aaron3238 I don't know what the PR workflow is. Probably one of the maintainers has to look at the code as well. @mikecao