Forgejo Migration Rollback Safety After Schema Changes in v1.20+

Database Migration Rollback Behavior in Forgejo v1.20+

Forgejo implements database migrations through Gitea's existing migration framework, which uses Go scripts stored in the migrations directory to manage schema changes. Each migration consists of a version number, a description, and an upgrade function that applies the schema modification.

The rollback mechanism for migrations is not explicitly documented as safe after schema changes. Unlike some database frameworks that maintain reverse migration scripts, Forgejo's implementation follows Gitea's pattern of forward-only scripts without automated rollback procedures. The codebase uses Gitea's existing migration system rather than implementing Forgejo-specific rollback safeguards.

Database backup procedures are recommended before migrations, but no automated rollback validation exists in the documented workflow. When a migration fails or needs to be reverted, administrators must rely on external backup restoration rather than a built-in mechanism. This creates operational risk for self-hosted deployments where database snapshots may not be immediately available or tested.Questions:

1. Does Forgejo's migration framework provide any built-in capability to safely revert schema changes after a migration has been applied?
2. What is the recommended procedure for recovering from a problematic migration in production environments?
3. Are there any version-specific considerations or known limitations regarding migration rollback behavior?