Upgrade

An upgrade can change database schemas, plugin compatibility, and data layout. Verify the target release and protect the data before replacing the Server binary or image.

Before upgrading

1. Identify the installed Server version, database backend, data directory, and artifact storage.
2. Review the target release notes and compatibility requirements.
3. Create and test a consistent backup .
4. Download the matching release asset and verify its checksum.

Do not assume a product version string alone proves compatibility with your current database or plugins.

Apply a compatible upgrade

Use the deployment-specific release procedure to replace the binary or container image while retaining the intended data root. Start the new release and watch its startup logs and migration status. Stravia applies its supported database migrations during startup; this does not create a missing PostgreSQL database for you.

Troubleshoot a rejected data layout

Some older data-root layouts are refused rather than replaced with an empty database. Do not delete or move individual files to make startup proceed. Follow a documented migration route for the installed source format, or restore the pre-upgrade backup with the matching prior release.

Verify after upgrade

Confirm Server reaches the expected ready state, the administrator can sign in, and existing models, keys, request history, and stored files remain usable. Send a test request and check Request history before returning production clients to the endpoint.

Next steps

For recovery boundaries see Backup and restore . If startup fails, see Troubleshooting .