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

# Storage regions

> How buckets bind to locations, and what the platform does and does not guarantee about redundancy.

## Buckets are bound to a location

Each bucket has a `datacenterId` that binds it to a storage location. The location determines where the bucket's objects are written.

Region and datacenter selection happens when a bucket is created in the dashboard. The public API can read the binding through bucket records, but cannot move a bucket between locations.

## One region per object

An object lives in **one region of Everabyte's storage infrastructure**. Everabyte does not automatically replicate objects to a second region.

This is a deliberate, documented limit. Versioning, object lock, retention, and trash protect against logical deletion and corruption. They do not protect against the loss of an entire region.

> [!WARNING]
>
> Everabyte does not provide automatic multi-region redundancy, cross-region disaster recovery, or a guaranteed recovery point objective. These are not part of the standard service.

## What you can rely on

| Property | Status |
| - | - |
| Object stored in the bucket's bound location | Yes |
| Encryption before storage, plus encryption at rest in the storage infrastructure | Yes |
| Version history for overwritten files | Yes, within plan limits |
| Soft-delete trash window | Yes |
| Automatic cross-region replication | No |
| Automatic failover to another region | No |
| Customer-selectable region per bucket | Through dashboard bucket creation, subject to available locations |

## Availability of locations

Available datacenters and regions depend on the deployment and the customer's plan. Do not hardcode region identifiers in your application. Read `datacenterId` from bucket records and treat it as opaque.

If your integration needs a specific jurisdiction or location, confirm availability with Everabyte before committing to a design. See [Data residency](https://docs.everabyte.com/security/data-residency.md).

## Designing for regional failure

Because there is no automatic second copy, durability against regional loss is an application decision:

* Keep an independent copy in storage you control, if the data is business-critical.
* Use version history and retention for logical protection, not as a substitute for geographic redundancy.
* Test restores from your own copy, not only from Everabyte.
* Define your own RTO and RPO; Everabyte does not publish guaranteed values for standard plans.

For enterprise arrangements, discuss durability requirements during [onboarding](https://docs.everabyte.com/enterprise/onboarding.md).


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