You can deploy a single global FusionAuth instance in one region (e.g., US or Japan) and store email addresses and authentication credentials there, while keeping other personal data (like names) in regional profile services.

In this model:

This approach works well when:

For strict data residency requirements, FusionAuth recommends physical isolation where each region gets its own completely separate FusionAuth instance with its own database and web server. This approach:

Tradeoffs: This is more expensive (servers scale linearly with regions), and cross-region reporting requires network calls. Users would also need separate accounts per region, which may not meet your "single identity" requirement.

To maintain consistent configuration across these separate instances, you can use Terraform to sync application and tenant configurations between deployments while keeping user data isolated.

Another pattern involves using IdP hints to route users to region-specific authentication flows while maintaining a unified user experience. With IdP hints, you can bypass the login page and route users directly to the appropriate identity provider based on attributes like email address or domain. This can help direct users to region-specific instances based on their location or organization.

Before finalizing your architecture, consider:

Data classification: Clearly define which identity data must be region-specific vs. what can be stored globally. Under GDPR, email addresses and authentication credentials are considered personal data.

Token validation: Ensure your regional services can validate JWT tokens efficiently. FusionAuth supports distributed token validation where services in any region can verify tokens locally without calling back to the authentication server. See the guidance on JWT validation in microservices architectures.

Compliance review: Verify your chosen approach meets your specific regulatory requirements (GDPR, etc.). FusionAuth is designed with GDPR compliance in mind and supports features like data export, deletion, and consent management.

Cross-domain SSO: If using separate instances per region, note that FusionAuth supports cross-domain single sign-on through OAuth/OIDC flows, though users would still need to authenticate to each regional instance separately unless you implement additional federation layers.

This is a complex architectural decision that benefits from detailed discussion of your specific requirements.

Important Note:
If you choose to use a database migration tool, proceed with caution:

Combining API-driven data migration for sensitive information with Terraform for configuration and a reliable database migration tool can significantly reduce the time and effort required for this migration.

It looks like we can transport with the API using Theme Update Endpoints and sharing environment API keys so one environment can see the next environment to copy the themes over.

Yes, that's what I'd recommend. You could have different API keys for each environment and have the script that promotes the theme pull the API key from a secrets store. Make sure you limit the API key to the themes endpoint.

You also might be interested in this post: https://fusionauth.io/community/forum/topic/1306/parameterizing-themes which indicates how you can have the same theme files point to different resources in staging/prod/dev/etc.

If you have user data you'd like to retain, please request a database dump before destroying your deployment.

Here's the action: https://github.com/FusionAuth/fusionauth-github-action

Here's doc about how to use it: https://fusionauth.io/docs/get-started/run-in-the-cloud/github-actions

However, there is a community supported project with a "Deploy to Heroku" button. This is provided and tested by a community member.