@mark-robustelli I haven't tested it again since, but I build a docker image using the base fusionauth image (fusionauth/fusionauth-app) because I have a custom plugin and kickstart file.
So my upgrade process is simply to update the base fusionauth image in my dockerfile, and then update my container in Azure. This has worked fine since 1.56, and updated through all the updates with migrations.
Edit: I just noticed that the downloaded schemas does contain a migration for 1.65, and running it on the database does make the container start now. Would have expected this migration to run on start up like the other updates though.

Lots of options!

Self-service password recovery — SMS or Email based forgot password flows out of the box, with hosted pages that require no custom UI. If a user's login ID is a phone number, the reset is delivered via SMS automatically. API-driven recovery — The full forgot password flow is triggerable via POST /api/user/forgot-password with an email, phone, or username as the login ID, giving teams complete control over the UI and recovery experience. Admin and support-assisted recovery — Support staff can trigger resets or force password changes directly from the admin UI, no email required. Admins can also remove MFA methods directly from the user record. MFA recovery — Recovery codes generated at MFA enrollment let users bypass a lost second factor. Self-service MFA configuration — Users can add, remove, and manage their own MFA methods (TOTP, SMS, email) from a hosted self-service account page without any admin involvement. Removing a method requires completing an MFA challenge first, which prevents unauthorized removal. If an admin removes a user's MFA method and the tenant or application policy is set to Required, the user will be prompted to set up MFA again on next login. Webhooks and event-driven recovery — FusionAuth fires events like user.login.failed and user.password.reset that your backend can listen to and act on, enabling custom recovery logic, audit trails, and downstream notifications. Account linking and IdP recovery — For users who log in via a social or enterprise IdP, FusionAuth can be configured to link that identity to a FusionAuth user record. If the IdP connection is the issue, the user can still go through the standard forgot password flow as long as an phone number or email is on their account, so recovery isn't solely dependent on the IdP being available.

You want to use search parameters like those outlined in this sample script.

use a key limited to POST on /api/user/search set accurateTotal on the request set numberOfResults to 1 on the request

In the response, look at the total field.

This will let you get exact numbers while reducing load on your instance.

Beginning in version 1.65.0, FusionAuth offers Complete Registration. Full docs here.

How this would work:

enable a registration form for the application your users are logging into select certain attributes as required. If you are using a basic form, you could select 'birth date'. If you are using an advanced form, you can select whatever profile attributes you need set the Registration mode to Complete registration. This setting means that users cannot self-register, but can complete missing information from an existing registration. save the application

Now, your admin user can create a user with a minimal amount of data (perhaps just an email address).

The user will, at first login, be prompted to fill out their profile data, including all fields you've marked required.

This is not full progressive registration, but can be useful in certain circumstances.

@kevin-doran This is a great question to ask FusionAuth support.

Have you opened a ticket?

Thank you for letting us know.

This is an open issue. To see when this is resolved, you can follow along with the github issue here: https://github.com/FusionAuth/fusionauth-issues/issues/3439