Transfer your account to another region

Firezone support can move an existing account between Firezone Cloud US and Firezone Cloud EU. A transfer moves the account's configuration and identity records to the destination region. It requires scheduled downtime, new credentials, and changes to deployment endpoints. Historical audit logs are not transferred.

Before you request a transfer

You must be an account admin to request a transfer. Review the regional data-handling reference and choose the destination for the whole account. An account cannot span both regions, so all users, Sites, and Gateways move together.

Schedule access downtime

Notify affected users and arrange any access your operators need to update Gateways and integrations while Firezone is unavailable. Assign owners for Client configuration, Gateway deployment, SSO, API integrations, and log exports before agreeing on the maintenance window.

Export and verify historical logs

Historical audit logs are not transferred. Firezone deletes them from the source region when the transfer completes. Export the logs you must retain before the maintenance window.

A Log Sink can backfill existing logs when created with Deliver existing logs enabled. Verify that the required records have arrived at your destination before the transfer. Exported copies follow that destination's location and retention settings.

Inventory credentials and endpoints

Every session, Gateway token, service account token, and API token from the source region becomes invalid. Each region signs tokens with its own keys. Changing only an endpoint is insufficient: deployments need credentials issued in the destination region as well.

Inventory the secrets and automation each owner must update using the reconnection steps. Check Client version support to identify Clients that need manual configuration or MDM changes.

For OIDC authentication, add the destination region's callback URI to your identity provider's OAuth app before switching sign-in endpoints. Use the regional redirect URI reference.

Confirm billing and the data removal timeline

Paid subscriptions are recreated in the destination region. Firezone creates a new billing customer and subscription and applies remaining credit using the exchange rate on the day of transfer. Review this with support when scheduling; see Pricing for current plan information.

Request the transfer

1. Sign in to the admin portal as an admin of the account.
2. Go to Settings → Account.
3. In Data residency, select Request transfer to the European Union region or Request transfer to the United States region.
4. Read the confirmation and select Send request.

Sending a request does not start the transfer. It opens a support ticket. Firezone support contacts the requesting admin at their account email address to agree on a maintenance window.

The 8-hour window is the expected maximum downtime for the scheduled operation. It is not a deadline measured from request submission.

Before the agreed window, finish exporting logs, notify affected users, and make sure the people who manage Gateways, Clients, and integrations can update them afterward.

During the maintenance window

Firezone support disables the account, copies its configuration and identity records to the destination region, and enables it there. Disabling the account prevents changes being written to the source while the copy is in progress.

Wait for support to confirm the transfer is complete before reconnecting deployments. The destination has the same account configuration, but old sessions and tokens cannot authenticate there.

Reconnect your deployments

Use the destination region's endpoints:

Users and desktop or mobile Clients

Have users sign in again. A sign-in through the old admin portal redirects to the new region. Clients at the versions listed in the regional settings reference, or later, follow the redirect and switch regions automatically.

For an older Client, set Auth Base URL and API URL under Settings → Advanced to the new region's URLs. For Clients managed through MDM, update both the authURL and apiURL managed configuration keys.

Gateways

For each Gateway:

1. Create a new Gateway token in the destination admin portal.
2. Replace the token in your secret store and set FIREZONE_API_URL to the destination's Client and Gateway API URL in deployment configuration.
3. Redeploy the Gateway with those values and confirm it is online in its Site.

For Terraform Gateway modules, the URL option is firezone_api_url in AWS and Azure and api_url in GCP. On NixOS, use apiUrl. See the Gateway CLI reference and your deployment guide for the configuration method you use.

Headless Clients

1. Create new service account tokens in the destination region and replace the old tokens in your secret stores and deployments.
2. Set FIREZONE_API_URL to the destination's Client and Gateway API URL. On NixOS, use the apiUrl option.
3. For browser-based sign-in, also set FIREZONE_AUTH_BASE_URL to the destination's admin portal URL and sign in again.

See the headless Client references for Linux and Windows.

REST API, Terraform, and MCP

• REST API: Recreate API tokens in the destination region, replace the tokens in secret stores and integrations, and update the API base URL.
• Terraform: Update the provider's endpoint and API token. Gateway modules also need the control plane URL and Gateway tokens described above.
• MCP: Reconnect clients to the destination's MCP URL and authorize them again.

Verify the move

Before telling users that access is restored:

1. Sign in to the destination admin portal and check the account's region in Settings → Account → Data residency.
2. Check that the expected users, groups, Sites, Resources, and Policies are present.
3. Confirm that each Gateway is online in its Site and a Client can connect to an allowed Resource.
4. Check that headless Clients, API integrations, Terraform, and MCP can authenticate against the destination region.
5. Check that new audit events appear and that your Log Sinks deliver them to the expected destinations. Historical entries will not appear in the new region; use the exports you made before the transfer.
6. Remove obsolete tokens from your secret stores and deployment configuration.

If a deployment cannot reconnect, first verify that both its endpoint and its credentials belong to the destination region. Contact support if the account or its expected configuration is unavailable after the confirmed transfer.

Need help? See all support options.