Preview Deployments - Also run database migrations only for each Preview Deployment

What problem will this feature address?

When using Preview Deployments with an application backed by Postgres, there’s no built-in way to safely handle database migrations. Database migrations need to run in isolation for each preview, but currently all previews point to the same Postgres database. This creates conflicts when multiple branches introduce new migrations, as they attempt to modify the same schema. Ideally, Dokploy should provide a mechanism (or documented best practice) for preview deployments to use isolated schemas or databases (e.g., by leveraging DOKPLOY_DEPLOY_URL to generate unique identifiers) so that migrations can be applied automatically in each preview environment without affecting others or production.

Describe the solution you'd like

It would be helpful if Dokploy provided a mechanism (or documented pattern) to isolate databases or schemas per preview deployment. For example:

• Allow environment variables like DOKPLOY_DEPLOY_URL (already available in previews) to be used in connection strings. This would let applications dynamically generate a unique schema or database name per preview.

• Provide lifecycle hooks for Preview Deployments (e.g., “on create” and “on delete”) where a database or schema could be provisioned and later cleaned up automatically.

• Document best practices for common stacks on how to integrate preview-specific migrations safely.

This would ensure each preview has its own isolated database state, allowing migrations to run without conflicts and making previews much closer to real production testing.

Describe alternatives you've considered

• Running migrations only locally before pushing changes, but this doesn’t validate them against the actual preview environment.

• Manually creating separate databases/schemas for each branch in Postgres and wiring them up with custom connection strings, but this is error-prone and hard to automate within the Dokploy workflow.

• Skipping migrations entirely in preview deployments and only applying them on staging/production, but this defeats the purpose of previews for testing schema changes.

These workarounds either add too much manual overhead or reduce confidence in preview deployments. Having a built-in or officially documented approach in Dokploy would make the process reliable and seamless.

Additional context

No response

Will you send a PR to implement it?

No

No files, tests, or entry points are named. Start by locating Preview Deployment lifecycle handling and the PostgreSQL integration, then clarify whether the deliverable is isolated schemas or databases, lifecycle hooks, documentation, or a combination; done means previews can run migrations independently without affecting other previews or production.