> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackshift.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Support EU placement and recovery

> Verified resource inventory, owner storage moves and independent current authority for quarantined recovery.

<Note>
  **Not yet released.** This guide describes implemented changes awaiting rollout. Availability requires the corresponding backend and dashboard release.
</Note>

## Goal

Inspect the current implementation and its blockers without assuming production readiness or numerical recovery objectives.

## Prerequisites

* Use the coordinated platform-runtime or backend release for the placement migrations. The deploy guard stops old API, Mail and Assets writers and verifies a backup before migration; partial API/worker releases are refused. Resume a failed cutover with matching new binaries.
* Implementation in progress. Pending migrations 000554-000557 and coordinated matching API, existing Assets/Mail worker and recovery CLI versions; no production migration or move has been performed.
* Separate Support live/recovery storage credentials, exact EU jurisdiction endpoints and verified database/index/backup/WAL/worker/scratch/cache/log/processor evidence. Region auto and location flags are insufficient.
* Current owner processing disclosures and operator authority. Shared control-plane release reconciliation, post-release runtime activation and Linux restore verification are still unfinished.

## Workflow

<Steps>
  <Step>
    Read organization or standalone workspace residency capability and policy. Availability comes from current verified bindings, independent authority progress and compatible running components. Unconfigured or stale evidence returns blockers.
  </Step>

  <Step>
    Request an EU storage move with current If-Match, Idempotency-Key, target profile and owner processing exceptions. Operators advance the returned allowed actions through maintenance, drain, verified copy, cutover, reopening and cleanup.
  </Step>

  <Step>
    Shared production recovery is unavailable until platform job/payment reconciliation is implemented. Capture and source fencing reject that schema before maintenance or disabling logins. For a supported isolated boundary, the control-db support-recovery-backup helper inspects the actual repository, PostgreSQL instance, start/stop time and WAL boundary; JSON boundary files cannot authorize capture.
  </Step>

  <Step>
    Inspect bounded object-copy and independent authority checkpoints. Restore requires actual isolated PostgreSQL/API/Assets/Mail containers, their running executables and a matching Unix-socket target connection. Legacy quarantine flags and journal files are insufficient.
  </Step>

  <Step>
    After source logins are fenced, recovery-plan selects a backup using independent EU storage without a database connection. The control-db support-recovery-prepare helper restores the exact selected whole-cluster backup into a new private target, stages WAL before booting PostgreSQL with network mode none, and records a measured receipt. It requires an immutable matching Linux image and protected read-only repository credentials. Existing targets are never overwritten. Actual Linux restore verification remains outstanding.
  </Step>

  <Step>
    Current sealed authority is reapplied before restoring permitted objects and rebuilding local search. Shared-schema release remains blocked until platform queue and financial reconciliation are implemented and verified.
  </Step>
</Steps>

## Storage moves and processing boundaries

Existing uploads and exports continue using SourceUpload storage when regional profiles are unconfigured. Persisted regional bindings never silently fall back if credentials disappear. Worker readiness heartbeats retry after temporary failures, and successful copy retries or deletion during a move advance the durable checkpoint. Operator actions reflect the supported current state. Deletion is complete only after object absence is verified. Organization audit files retain maintenance fencing even without attached workspaces.

One EU control plane retains the shared database, indexes, API and existing workers. Organization storage moves cover all attached workspaces; standalone workspace selection requires its owner. Per-organization database separation and additional regional control planes are excluded. Legacy objects retain their recorded profile.

External processors require exact current versioned exceptions. Shared account and billing metadata remains in the EU control plane with an explicit owner disclosure. Maintenance fences content reads and dispatch, including bootstrap, stream replay, organization detail/list responses and SAML identity paths. Lists containing a maintained scope return retryable maintenance. Current directory-token/invitation revocation and its audit continue during source maintenance. Rollback after reopening first captures a fresh manifest of subsequent writes. Retained historical copies keep coverage incomplete.

## Current authority and recovery limits

Release Compose projects matching live/recovery storage to API and Assets/Mail workers with unique component IDs. Preflight rejects partial or non-EU bindings, reused credentials and mismatched worker/slot configuration. A separate isolated Compose file starts API and worker binaries in an early quarantine path that validates the private read-only Unix-socket target, restricted snapshot-bound database role and restored profiles, then acknowledges its generation without starting handlers, job consumers or providers. Live inspection rejects normal startup, duplicate environment entries, operator database identities and weakened runtime privileges. The target binds heartbeats to its recorded snapshot role. The nobody peer identity can write only the heartbeat ledger; content/control writes and operator-role escalation are denied. Set the runtime database role from the preparation receipt. It does not activate runtimes after release.

A content-free independent baseline and hash-chained journal supply current deletions, membership, identity and processing authority when content comes from an older snapshot. Current custom-role permissions and composite inbox/team/directory grants replace snapshot grants. Signed role-only labels and creation timestamps permit later organization/workspace roles and memberships for existing accounts. Final role metadata is applied atomically, preserving legitimate label swaps without retaining temporary labels. Distinct role dependencies are bounded to 100,000. Older incomplete role authority requires a fresh baseline. Missing current accounts/scopes, changed role identities and unrepresented stale name collisions stop reconciliation and remain unfinished implementation. Restore revokes old sessions and secrets, removes tombstoned media derivatives and validates SQL/vector search locally without external AI.

Restored uncertain provider actions, charges and refunds are never automatically replayed. Financial reconciliation remains required. Target quarantine blocks ordinary shared-schema mutations. Import checks the prepared receipt against the live container, image, postmaster instance and independent sealed plan. The dedicated operator CLI inspects actual containers and PostgreSQL identity; a stored flag cannot replace isolation.

Object copies preserve standard HTTP/custom metadata and compressed bytes, including raw HTTP Expires values on single-part and multipart copies. Captured metadata binds restore replay; expiry changes block restore even when bytes match. Older seals that omitted existing expiry require a fresh capture. Object tags and lifecycle-deletion expiry remain unfinished.

The release generation transition is implemented locally but the whole shared release workflow is unfinished and blocked. Reconciliation duration is distinct from measured physical restoration. Numerical RPO/RTO remain null. The backend runbook records implementation gaps and exact local verification separately from deployed qualification.

## Expected result

<Check>
  Current state, revision, generation and explicit blockers are inspectable. Local fixture success does not establish deployment, EU coverage, provider qualification or numerical RPO/RTO.
</Check>

## Common failures

<Warning>
  * The checked-in control-db repository lacks an EU jurisdiction endpoint; capture refuses it. An operator must verify the repository transition and retained-copy handling before use.
  * Active dispatch, running jobs, outstanding presigned access, expired evidence or stale runtime generations block maintenance or activation. Retry from the current revision after the blocker is resolved.
  * Corrupt copied bytes, changed seals or current tombstones prevent publication. Privacy cleanup tracks recorded original, target and recovery keys without enumerating unrelated bucket data.
  * Full shared-schema release explicitly fails because shared platform jobs and financial dependencies are not yet reconciled. Keep the target quarantined; this is unfinished implementation.
  * Offline restore staging currently accepts a single WAL timeline and at most 4096 segments. Unsupported boundaries fail before startup. Preparation supports explicit same-plan resume under a target lock: partial downloads use delta verification and an already booted database is never restaged. Preparation does not start API/workers or activate the target; runtime activation configuration remains unfinished.
</Warning>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.