Buy capacity without giving away readability
Your health records may belong on your own phone for processing. That does not mean your phone must contain their only durable copy, or that every storage provider must become someone you trust to read them.
Legra separates the places that execute queries from the places that retain encrypted blocks. This gives a workspace two independent ways to scale: more authorized serving capacity and more encrypted storage capacity.
The commercial opportunity follows from that separation. Compare storage offers across the network while keeping the plaintext trust boundary as small as your application requires.
Two layers, two jobs
| Layer | Replicated material | What a provider can do |
|---|---|---|
| Workspace Host | Governed workspace state, branch heads and serving context | Decrypt and execute authorized queries when given the required keys |
| Block custodian | Opaque encrypted blocks identified by content | Store, retrieve and replicate protected bytes without reading their contents |
A Host replica need not preload every block. It can fetch the working set needed for a query. Custodians can each hold a different subset of the workspace's blocks, with several holders for each block.
A large workspace can therefore span many disks and providers. Its storage capacity is not capped by the disk on the phone that processes its private knowledge. Growth still requires available capacity, connectivity and funding.
Make cost a policy decision
Workspace policy expresses the outcome you want: enough copies, selected regions, independent operators, acceptable service and a price ceiling. Provider offers describe available capacity and terms.
Prefer cheaper eligible providers while satisfying those constraints. The cheapest offer overall may have the wrong region, insufficient capacity or an unsuitable service class. The useful objective is a low-cost placement that meets your requirements.
Include storage, ingest, retrieval and transfer costs when evaluating the arrangement. Moving every block whenever a cheaper offer appears can cost more than it saves. A cost-aware policy needs to consider the work of achieving its desired placement as well as the advertised storage price.
Encryption widens the pool of providers you can use without giving them decryption keys. Provider reliability and actual holder evidence still matter: unreadable ciphertext is private, but it is not a useful surviving copy.
Put performance near demand
Place an authorized Host near the people or operations it serves. Keep its frequently accessed blocks nearby through demand-driven custody caching, while preserving durable copies in the required failure domains.
Hot data can acquire additional holders through reads; cold data still has a minimum durability requirement even if nobody queries it. A provider reclaims space only where the replication floor allows it.
This supports regional performance without forcing every custodian to store an entire workspace. Latency still depends on the execution location, working-set availability, network path and load. Adding a storage copy in a region does not by itself place an authorized query executor there.
Turn failures into ordinary repair work
Policy-driven reconciliation compares desired counts and placement with observed live Hosts and block holders. When a holder disappears or its evidence ages out, surviving participants recruit replacements and pull the missing ciphertext. Deficits remain visible until satisfied.
With an eligible Host and readable committed state outside a failed site, queries can continue through that surviving service. Replacement nodes can catch up through replication instead of requiring an operator to rebuild the workspace from a cold archive after every machine loss.
For example, an illustrative policy could ask for two approved serving Hosts and three encrypted copies of each committed block across two regions, including independent storage operators. These are separate counts: three custodians do not count as three query-serving Hosts.
A minimum is a maintained target, not a statement that failures cannot temporarily reduce the live set. Failure detection, network reachability, replacement capacity and repair time determine the remaining exposure.
Keep personal-device sovereignty intact
If only your phone may decrypt a workspace, losing connectivity to the phone pauses its query service even while encrypted blocks survive elsewhere. Routing cannot manufacture another trusted executor.
Authorize your own laptop as a second serving Host if you want continuity between your personal devices. Workspaces used by the same application can make different choices: personal records on owner-controlled devices, shared business data on approved regional Hosts, ciphertext spread more widely.
Recoverable keys remain essential. Redundant encrypted storage protects bytes; it cannot replace lost decryption authority.
Choose the transaction's replication condition
High-availability transaction publication needs an explicit boundary. Local transaction durability, additional block copies and serving-Host readiness are separate conditions.
Synchronous block replication waits for the configured copy evidence before publishing the branch head. Asynchronous replication can publish after the required transaction durability barrier, then close additional copy deficits. Host replication has its own timing policy. Journal-enabled publication also requires durable journal evidence for the transaction.
Waiting for more independent copies strengthens the publication condition and adds latency. If the required holders are unavailable, that policy may prevent publication. An asynchronous choice keeps a different availability and exposure tradeoff explicit. Neither creates one atomic transaction across an entire distributed Use Case.
Make continuity the normal path, keep recovery points
Live replicas can absorb covered failures and keep repairing redundancy. That reduces how often a service needs a disruptive archive restore. It does not remove the need for a disaster-recovery plan.
An erroneous change can replicate too. Retained history and independently preserved archives provide recovery points for mistakes, destructive actions or failures outside the supported topology. Test both continuity and restoration.
See policy-driven replication, Host selection, encryption authority, high availability and backup and restore for the individual controls.
Try it in Legra
Use the connection guide to check which node you reach and diagnose connection failures before testing your availability setup.