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 first catalog workflow supports Memos 0.31.0 with an Impreza-managed HTTPS hostname.
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 reviewed Memos 0.31.0 build on both sides. 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 registered by its Agent with a public IPv6 address is temporarily excluded from the available server list. 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.
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.
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 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.
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.
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.
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.
This initial catalog path supports Memos 0.31.0, a managed hostname and a reviewed cold copy. It does not include arbitrary apps, customer-domain cutover, private onion migration, automatic health-based promotion, zero data loss or zero interruption. 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.