Migrating between providers

A deployment can move from one hosting provider to another, and the panel gives the operator the two controls that move it. Both call the API directly from the browser with a short-lived bearer token, as the delete control does; the panel holds no migration logic of its own.

• Export, on each row of the deployment list and on the deployment page, reads the deployment's migration string from GET /migration-string/<id> and shows it to copy. That string is the capability the target provider needs: the operator configuration without the settings that belong to the source provider, the name of the deployment method the source used, the module_source pin the deploy ran under, and one state pointer per application that has state to move. It carries live credentials, thus it is a secret. The control stays disabled until the deployment is active, because the string points at snapshots of the deployed state. While a build of the deployment runs, the control is also disabled.

  The export is not a plain read. It stops the applications before the snapshots, so that no write after them is lost, and then suspends the deployment. Thus the control asks the operator to confirm first, with the confirm question of the export action. The modal shows the string once: the API refuses a second export of the suspended deployment. To roll back the move, resume the deployment. To export again, resume it first. A configuration with no enabled application has no snapshot, so its export does not suspend it.

• Import, above the deployment list, makes a new deployment on this provider and sends a pasted string to POST /migration-import/<id>. The string tells the new deployment what to build and where to pull each application's state from, so the operator keeps their configuration, their data and their domain. The new deployment uses the settings of this provider. If this provider has one fixed deployment method, the new deployment uses it. Otherwise it uses the method that the string names, and the import fails if this provider does not offer that method. It registers the domain under the registrar account of this provider, so both providers must hold the same account. It runs new containers at new addresses, and the deploy points the domain's DNS records at them. Before the API accepts the string, it checks that this provider can deploy the configuration of the string, which can take some minutes. The panel shows that the check runs, and waits for its result. When the check fails, the panel shows the options that do not exist or have no value on this provider, and the new deployment stays empty.

The API produces and consumes the string (api/src/fediversity_api/migration.py).