22-Oct-2026 — Moving an environment between Fly organisations

Part of Moving existing NGX groups and areas onto Ramblers-held infrastructure.

This procedure uses the Platform Management UI on NGX staging, not the group website being moved. It moves the running Fly app; MongoDB, S3 and Brevo remain where they are. Check their placement separately if the whole environment must move to different accounts.

The examples below are fictional: environment example-group, destination organisation example-org, preferred app ngx-example-group, and public website https://group.example.org.uk. Use the actual values from the selected environment. The environment name, Fly app name and public hostname can be different.

Screenshots below were captured during an end-to-end move. Environment names, hostnames and account labels have been replaced with fictional examples; token fields remain masked.

1. Check the destination and record the starting state

1. Sign into Fly and select the destination organisation. Check its Billing page. A payment warning for a Personal organisation says nothing about billing on another organisation. If payment details are hidden by your role, ask an organisation administrator to confirm that deployment is enabled.
2. On NGX staging, open Admin → Platform Administration → Environment Management → Environment Setup → Create or Modify. Choose Change existing environment, then select the trial environment.
3. Record its current organisation, app name, memory, scale, public hostname and running build. Confirm that the website works before starting.
4. Start with an agreed trial environment. Allow a maintenance window: the workflow can report completion before a newly requested public HTTPS certificate has finished issuing.

Select the environment and the organisation move action.

2. Create and keep the organisation token

1. In Fly, select the destination organisation and open Tokens.
2. Enter a descriptive name, such as NGX Platform Management. Choose an expiry that fits your operating policy; an empty expiry currently creates a token that never expires.
3. Select Create Organization Token. Save the generated value immediately in the approved password manager or another private credential store. Fly displays the full value once.
4. Keep the complete token on one logical line, including its FlyV1 prefix. Display wrapping is harmless; inserted line breaks, missing characters and a literal <redacted> placeholder are not usable credentials.
5. Retain the source token as well. A destination organisation token does not give access to the source app. Do not overwrite the source credential before the migration form has both values.

Do not put tokens in documentation, source control, screenshots or correspondence. A locally saved copy containing secrets should be outside the repository and readable only by its intended owner.

3. Fill in the migration form

Select Move Fly organisation (cutover to new org token) for the chosen environment.

For an initial trial, clear Destroy previous Fly app after the new app is healthy. This retains the source app and its credentials while the destination is tested. The control can default to selected when reopening the form, so check it on every run.

If the site uses its free NGX hostname, select Re-attach free NGX subdomain. Leave it off for a site using only a custom domain. The workflow also attempts to re-point configured custom hostnames; verify every hostname that visitors use.

Select Detect cutover state after entering both tokens and the organisation and app names. Do not rely on status badges calculated with an empty destination token or before editing the fields. Resolve authentication or configuration errors before starting.

Trial settings retain the source app while the destination is tested.

4. Run the trial move

1. Select Move to this Fly organisation, or Resume cutover if the form detects an existing partial run.
2. Follow progress in the staging UI. NGX creates the destination app, imports its deployment secrets, deploys the configured container image, applies the environment's memory and scale, and updates the environment record and selected hostnames. Check the image before starting: migration deploys the image configured in Platform Management. It does not automatically preserve the source app’s running build. If the configured tag is latest, the move can also upgrade the application. Record the intended build and verify it afterwards.
3. If the preferred app name is still owned by the source, the workflow uses a temporary destination name such as ngx-example-group-cutover. With source deletion disabled, this is the expected trial state.
4. Check the destination app in the correct Fly organisation. Confirm its region, machine size, scale and health checks. Fly can briefly create a second machine during deployment before NGX applies the configured scale.
5. Open the destination app and check real content: the home page, walks and photographs. At the public website, open About this version and confirm the Fly app identity and running build. An HTTP 200 alone does not prove traffic reached the destination; an old app can also return 200.

A trial can finish with the temporary cutover app still serving the site.

5. Confirm public HTTPS separately

A successful deployment message, or Deploy Complete, does not prove that the public hostname is ready.

1. In staging's Modify view, use Hostnames → Re-check. Confirm DNS points to the destination and HTTPS is serving.
2. In Fly, open the destination app's Certificates, select the public hostname and use Check again. Validation can move from Not verified to Issuing... before the certificate becomes Active.
3. Wait for Active, then reload the public site and check its running app identity again. DNS caches and existing browser connections may briefly reach the previous address.
4. If validation stays blocked, compare the DNS or ownership requirements shown by Fly with the configured hostname. Investigate the specific mismatch; repeating a deployment is not evidence that a certificate problem has been fixed. Do not bypass certificate warnings.

Treat a failed public HTTPS check as unfinished work, even if the app's Fly hostname works. Check this after the trial move and again after the final name is restored.

Confirm that the public hostname certificate is Active.

6. Remove the temporary cutover name

Only do this once the trial has passed and the operator has explicitly approved deleting the source app. Source removal ends that rollback option. Review the old app name and organisation before continuing.

1. Return to the same environment's Move Fly organisation form on staging.
2. Confirm the source fields still identify the original app and the destination token belongs to the intended organisation. Keep New app name set to the preferred final name, not the temporary -cutover name.
3. Select Destroy previous Fly app after the new app is healthy. Select Re-attach free NGX subdomain again if that hostname is in use.
4. Select Detect cutover state, then Resume cutover.
5. The workflow uses the temporary app while it removes the source app to free the preferred name. It then creates and deploys the preferred app in the destination organisation, updates hostname routing, removes the temporary app and clears the saved previous Fly credentials when finalisation succeeds.
6. Repeat the public HTTPS and app-identity checks above. A new preferred app can need a new certificate; deleting the temporary app does not mean certificate issuance has finished.

If interrupted, inspect Detect cutover state and use Resume cutover to finish the remaining steps. Do not manually delete apps or revoke the source token while the run still depends on them.

After approval, select source removal and retain the preferred final name.

Completion shows the final app name without the cutover suffix.

7. Confirm where the token is stored

Open Platform Configuration Values → Configuration inventory → Site values, choose Fly.io and filter to the environment. Refresh the inventory after migration. Confirm the organisation and app name match the destination and Fly API token is present.

This inventory is read-only. The migration saves the environment's runtime token; the inventory displays that saved value. Use Show secret values only when the actual token is needed, or use Offline export with Include secrets in pack for an approved private copy. A presence-only export containing SET is not a token backup.

System Logins holds human vendor logins, not deployment API tokens. Do not put an organisation token in a website password field. Saving a token for this environment also does not, by itself, select a new default organisation for all future registrations.

The move is complete when the preferred app is healthy in the destination organisation, the temporary app is gone, the public site has active HTTPS and reports the expected final app and build, the inventory matches, and the operator has a usable private credential copy.