Prisma migration rollback strategy for Hoppscotch self-hosted schema changes

Context

Hoppscotch self-hosted applies database schema changes through Prisma migrations tracked in the prisma/migrations directory. Prisma does not ship a built-in migrate rollback command, leaving administrators without a documented single-command path to revert a schema change safely.

Constraints

Reverting a migration currently requires either authoring a new Prisma migration that inverses the prior change or manually repairing both the database and the _prisma_migrations table. Manual SQL against a production database risks corrupting the migration history, and the Hoppscotch deployment documentation does not describe a supported rollback procedure. Behavior may also differ between self-hosted versions and the managed cloud service.

Open questions

1. What is the recommended, version-agnostic procedure for rolling back a failed or unwanted schema migration in a production self-hosted deployment?
2. Does the project maintain a documented inverse-migration template or CI check that validates rollback safety before a migration is merged?
3. Are there plans to expose a controlled rollback workflow—such as a prisma migrate deploy --to target or a dedicated admin endpoint—for self-hosted operators?