Skip to main content
Storage location is a property of the bucket. Each bucket carries a datacenterId, and objects written to that bucket are stored in the location it identifies. This page explains what that binding does and does not guarantee.

​
Location binding

Do not infer jurisdiction from the shape of a datacenterId, and do not hardcode identifiers. Available locations depend on the deployment and the customer’s plan.

​
What residency means here

Everabyte can state that an object is stored in the location bound to its bucket, that it is encrypted by the application layer before it reaches that location, and that the storage infrastructure applies its own encryption at rest. Everabyte does not automatically:
  • replicate the object to a second region,
  • fail over to another region,
  • maintain a cross-region disaster-recovery copy,
  • guarantee a recovery point objective or recovery time objective for standard plans.

​
Metadata and platform records

File contents live in the bucket’s location. Platform records needed to operate the service — account data, key envelopes, audit events, and usage records — are held in the platform’s operational systems. A strict residency requirement should be discussed explicitly rather than assumed. If your requirement is “no data of any kind leaves jurisdiction X”, raise it during enterprise onboarding before you build. It is a contractual conversation, not a configuration toggle.

​
Designing for jurisdictional requirements

  1. Create buckets in the location that matches your requirement.
  2. Keep a written record of which bucket serves which jurisdiction.
  3. Do not reuse one bucket across jurisdictions just because it is convenient.
  4. If two jurisdictions require isolation, prefer separate company workspaces with separate keys.
  5. Keep an independent copy if the data is business-critical, and test restoring from it.
  6. Confirm location availability with Everabyte before committing to a design.

​
Multi-region durability is your decision

Because there is no automatic second copy, geographic durability is an application-level decision:
  • An independent copy in storage you control is the only way to survive the loss of a region.
  • Versioning, object lock, retention, and trash protect against logical deletion and corruption, not against regional loss.
  • Define your own RTO and RPO. Everabyte does not publish guaranteed values for standard plans.
  • Test restores from your own copy, not only from Everabyte.

​
Changing location

There is no public API to migrate a bucket between locations. If you need to relocate data:
  1. Create a new bucket in the target location.
  2. Copy files with the copy endpoint, or re-upload from your source of truth.
  3. Verify counts and sizes.
  4. Repoint your application.
  5. Retire the old bucket through the dashboard.
Plan the cutover as a data migration with verification, not as an in-place toggle.

Storage regions

The conceptual model behind bucket binding.

Encryption architecture

How objects are protected before storage.

Buckets

Reading bucket location and capacity.

Enterprise onboarding

Discuss contractual residency requirements.