Jurisdiction Failover prepares a supported application on another server you own, in a different reported country. You verify a restored copy, review the planned interruption and explicitly confirm the change. The reviewed catalog workflow supports Memos 0.31.0 and Uptime Kuma 2.5.5, using an Impreza-managed HTTPS hostname. This guide keeps Memos as its example; the same reviewed steps also apply to a matching Uptime Kuma pair. Custom projects from an image, Git or Compose have a separate eligibility path, explained below.
This is a cold standby: it uses a completed backup rather than continuously replicating writes. Data written after that backup can be lost. Prepare the workflow while the source is reachable; the platform does not promote a second writer merely because the source stops responding.
Check that both sides are eligible
- Two compatible servers and enough capacity, owned by the same account, in different reported countries.
- The same app and reviewed version on both sides: Memos 0.31.0 or Uptime Kuma 2.5.5. Do not pair different apps or versions. A different app or version needs its own compatibility review.
- A running primary using its managed hostname, without unsupported live database bindings.
- A healthy standby created without a public hostname or onion route.
- Account-level permissions for the workflow and access to completed app backups in your account’s Impreza S3 storage.
Managed VPS locations are checked against the service. For an external server, the country is declared by you and is not verified by Impreza. A managed VPS can be recognized through its normalized public IPv4 or IPv6 address when that address belongs to the same service on your account. Country, ownership and Agent compatibility checks still apply; an address belonging to another service does not qualify. Pairing does not buy servers or cancel either service.
A supported public onion route can accompany the managed hostname. Private onions with authorized clients and a customer’s own domain are outside this initial workflow. See the current compatibility and prerequisites before choosing servers. Review the service terms and your own recovery requirements.
Check disk-encryption compatibility before pairing
The first customer-held encrypted-root release does not provide failover for an encrypted server. It also refuses snapshots and server migration for that workflow. Do not assume that choosing an encrypted-disk image makes this application standby procedure compatible with it.
Decide which recovery model the workload needs before configuring the pair. Use the encrypted-root limits alongside the failover prerequisites. An exported app backup has its own protection and recovery rules; neither a backup nor an unlock passphrase establishes a supported standby.
Start with Protect this app
For a running Memos 0.31.0 or Uptime Kuma 2.5.5 app with an unchanged reviewed recipe and an owned hostname, open My Apps → Protect this app. Choose an online compatible server on your account in another reported country. If you do not have one, supply an eligible server separately; the assistant never purchases a server.
The assistant guides three separately confirmed steps: create the unrouted standby, pair the two apps, then run the first restore drill. Review the exact app, destination and action each time, and complete the fresh confirmation for that step. Opening or resuming the assistant does not authorize the next write. It never switches traffic.
With the hosted connector, or local impreza-mcp 0.50.0 or later, request the impreza_protect_app prompt using the primary deployment ID and, optionally, a target Agent ID. The prompt checks visible tools, credential permissions and the reported countries before guiding the same operations. An external server’s declared country remains unverified. Updating the MCP package and updating the server Agent are separate actions.
Help me protect this Memos app in another country. Check the compatible servers and explain standby creation, pairing and the first drill. Ask me before each change. Do not purchase a server or move traffic.
After an uncertain response, resume the saved operation and read its receipt before requesting another copy. A queued or failed drill is not verified protection. A verified drill reports the dated copy age and the measured restore-drill duration; neither is a promise of zero data loss or the time needed to complete a traffic cutover.
The guided assistant currently covers those two reviewed catalog apps. Use the separate custom-project workflow below for image, Git or Compose deployments. Customer-domain cutover and arbitrary live database stacks are not added by this assistant. Read the assistant reference for the current requirements.
Prepare the standby and its copy
Create the second Memos deployment
In My Apps, choose Memos and Create a cold standby in the install dialog, then select the second server. This option is available in Simple and Advanced mode and disables domain and onion inputs. Wait for the healthy deployment. Creating the empty standby does not copy the primary’s data. For monitoring, choose Uptime Kuma 2.5.5 on both servers and use the same standby option.
With a supported MCP connection, use impreza_deploy_catalog_app with the second server, the reviewed Memos version and standby: true. Omit domain and onion arguments. Use local MCP 0.48.1 or later for the Kuma workflow, or the current hosted connector. Existing local installations need an explicit package update. Use the standby creation reference for the exact parameters.
Pair the two apps
Open the primary application’s failover panel. Select the healthy standby, review the app identities and countries, and pair in cold mode. Both servers remain separate services. This association does not restore data or move traffic.
Restore an exact completed backup
Back up the current primary. Restore that completed backup to the paired standby and wait for its healthy redeploy. Read all three results: backup, restore and deploy command. Do not substitute an old or unrelated recovery point.
Confirm the verified copy
Confirm sync using those exact receipts. Check the last verified sync time before preparing a cutover; a ready label is revalidated. If the copy is too old, create and verify another. The current workflow refuses preparation from a cold copy more than one hour old.
Prepare a standby for your own application
For an eligible custom project, use the hosted connector or local MCP 0.49.0 or later. Deploy the second instance with impreza_deploy_custom and standby: true, on the other server. Do not give the standby a domain or onion address: it must stay unrouted until a reviewed cutover.
Both sides must use the same frozen source: an image digest, the exact Git commit, or matching frozen uploaded Compose/build content. Declare every persistent data folder and named volume for every service; a missing volume is refused instead of silently excluded from the copy. Compatible Agent startup-health support is also required.
Move variables and secrets with the configuration export, review and apply workflow. The app-data backup does not transfer that configuration for you. Keep secret references intact, and enter new secret values outside AI chat.
Pair the apps, restore a completed backup, verify the copy and complete a verified drill for that same pair before requesting cutover. The platform refuses a custom cutover without that drill. A successful drill measures a particular recovery attempt; it is not a guarantee for every future failure.
Read the custom standby requirements before preparing the source and storage. This adds a path for eligible custom applications; it does not make every Docker stack or live database binding supported.
Review before changing traffic
Prepare a cutover and read the source, destination, countries, managed hostname, backup age and planned interruption. The review expires after 15 minutes. Preparation alone does not stop the primary or redirect visitors.
Prepare a review for this paired Memos app. Explain the destination, backup age and interruption. Do not apply the cutover.
After the responsible person confirms that exact review, apply its returned identifier and unchanged review digest. Use the panel’s confirmation or the documented MCP operation. A request being accepted means the work is queued; it is not a successful switch.
Wait for a verified result
The workflow prevents the old primary from writing and serving through its managed route before activating the restored target. This source fence protects against two active writers. If the source is isolated and cannot acknowledge it, the target waits; recovery of a lost source requires operator assistance rather than a bypass flag.
Read the cutover until verified or an actionable failure is reported. Check the destination app, its content, the managed hostname and HTTPS response. DNS caches can delay what a visitor sees. The age of the restored backup is still a data-loss boundary; a successful route switch does not bring back newer writes.
Verify a monitoring app after the move
For Uptime Kuma, open the destination dashboard and check its restored monitors, recent results and notification settings. Trigger a controlled check to verify the integrations you rely on. A healthy web response does not prove that every monitored service or notification channel works, and a standby is not a second active monitoring instance.
Use the self-hosted monitoring page for the application overview. For integration clients, the REST API reference now includes standby creation, sync, cutover, return and drill operations. Follow the same ownership, review and confirmation requirements as My Apps and MCP.
Exercise recovery before an incident
A drill takes a backup, refreshes and checks the standby, and leaves traffic on the primary. Review the exact copy and measured drill results. Scheduled drills can refresh the standby, but they are not continuous replication or automatic promotion.
Declared recovery objectives are goals. Drill timings exclude human review and do not measure the duration of a DNS cutover. Use the drill reference to set a policy and interpret results.
Watch the standby between recovery tests
After a pair’s first verified sync, the platform creates two enabled alert rules on its primary app. Open My Apps → Advanced → Metrics & alerts to review them. An empty standby or a requested sync is not a verified pair.
| Rule | What the default condition means |
|---|---|
standby_stale | The scheduled sync is at least 30 minutes past its deadline, with no drill running. A pair without a drill policy has no sync deadline, so this rule stays quiet until a policy exists. |
drill_failed | The latest finished drill for that pair failed. Inspect its result and evidence before retrying. |
The failover panel now also shows open standby notices beside the pair’s recovery information. Before preparing a move, read any delayed-sync or failed-drill notice, its UTC opening time and the available condition evidence. Check the pair’s latest verified sync and drill result to decide what needs attention. The current REST and hosted MCP standby read include the same account-scoped notices.
The rules do not open while a drill or cutover is in progress. Disabling failover resolves open alerts and prevents new ones. A notice disappears when its condition resolves, but a quiet rule is not proof that the copy is current or recovery-ready: keep checking verified sync and drill receipts. Reading a warning never grants permission to promote the standby.
To keep either alert off, disable the rule rather than delete it. A deleted rule is recreated on the next verified sync. Alerts appear in My Apps and can reach a separately configured account webhook as deployment.alert; they do not trigger a cutover, move DNS or guarantee that someone saw the notification.
Follow metrics and alert delivery and the standby alert reference for the current conditions. This release adds controls in My Apps and the current REST contract; it does not establish support for every new field in an installed local MCP package.
Return or retire deliberately
Returning is a separate reviewed workflow: release the previous fence while keeping the old app stopped, invert the pair, copy current data back, verify the new sync and review another cutover. Inverting the pair alone moves no traffic. Never restart the old stale copy as a shortcut.
If you choose to retire the old managed VPS instead, end that exact service through the normal server procedure first. After its state is Terminated, use the retirement action and verify its receipt. Retirement does not cancel billing for you or delete backup objects. External and dedicated hosts require their operator procedure. Read return and retirement before either decision.
The reviewed catalog path supports Memos 0.31.0 or Uptime Kuma 2.5.5. Eligible custom projects add a separate path with pinned source, declared persistent data and a verified drill. Both use a managed hostname and a verified cold copy. Unreviewed stacks, customer-domain cutover, private onion migration, unsupported live database bindings, automatic health-based promotion, zero data loss and zero interruption remain outside this workflow. Keep ordinary backups and your provider’s server-recovery plan.
For a first setup, use app backups and restores and the Memos hosting page. The technical failover reference is the source for current eligibility and operation details.