High Availability and Disaster Recovery v2
Use this guide with the deployment details confirmed for your subscription. See the infrastructure overview for Tenant routing and explicit sign-in to the primary or secondary region.
Flowgear provisions dedicated infrastructure for each Tenant, regardless of subscription. Availability is increased on select plans by provisioning multiple compute hosts (VMs) and adding a secondary region for disaster recovery.
Flowgear manages configuration data backup, configures underlying required storage appropriately for high availability, and load balances across compute resources. Where a secondary region is provisioned, Flowgear automatically fails over to that region when health probes show that the Tenant remains unresponsive for an extended period.
Define the service boundary
Document which responsibilities belong to Flowgear-managed cloud infrastructure, customer-managed Cluster hosts and networks, external providers, and your Workflow configuration. A resilient runtime cannot compensate for an unavailable provider, expired credential, single local host, unsafe replay, or client pinned to an obsolete address.
Prepare local Clusters
A Local Cluster can contain multiple hosts. Install multiple hosts and always update hosts one at a time. Wait for each host to come online and verify that it can run Workflows before updating the next. A single-host Cluster has downtime while that host is unavailable. Ensure each host has appropriate outbound connectivity and the correct certificate. See Local Cluster - Update.
Workflow placement does not automatically switch to an incompatible cloud or Local Cluster. Review every placed Workflow and Connection in the continuity design. See Local Cluster for placement requirements.
Prepare and test Workflows
Published enabled Workflows with schedule or listener triggers are managed automatically only by the region currently recognized as the active primary. A secondary region does not run an additional set of these automatic triggers just because you sign in to it. This regional control does not change a Workflow's configured cloud or Local Cluster selection.
When the active primary changes, schedule management resumes in the new active primary region. Listener management stops listeners owned by the region that is no longer primary and starts the required listeners from the active primary. Allow time for these changes to converge, and verify that the expected schedules and listeners have resumed.
This restriction concerns automatic schedules and listeners. Explicit HTTP or MCP requests still require a reachable regional endpoint, the correct Environment hostname, an enabled published Workflow, and valid authorization. Do not assume that a successful request proves that automatic triggers have also recovered.
Use idempotent operations, bounded retries, Environment-specific Connection values, revision history, redacted logs, and external reconciliation.
Run controlled exercises that verify:
- Target Environment hostnames and OAuth or MCP discovery.
- HTTP and MCP invocation with real authorization boundaries.
- Schedule and listener convergence.
- Connection reachability and provider allowlists.
- Local Cluster host loss and recovery.
- Revision rollback and Environment-specific Workflow status.
- App frontend and backend compatibility.
- Log, audit, and reconciliation evidence.
Do not change DNS, host headers, production Workflow status, Cluster placement, or provider allowlists without an approved plan and rollback path.