---
slug: platform/regions
title: Regions and replication
kind: explanation
surface: platform
summary: How Aetherfy places data and compute across us-east-1, eu-central-1 and ap-southeast-1, why single-region plans pin an account home region, and how asynchronous multi-region replication behaves on the Performance tier and above.
sources:
  - aetherfy-control-plane:shared/regions.py
  - aetherfy-control-plane:api/routes/regions.py
  - aetherfy-control-plane:shared/plan_validator.py
  - dashboard/src/lib/config/regions.js
  - dashboard/pages/api/dashboard/account-region.js
  - landing/src/lib/pricing-tiers.ts
  - vectordb:backend/services/replicationHandler.js
  - vectordb:backend/services/backfill.js
  - vectordb:backend/services/regionForward.js
---

# Regions and replication in Aetherfy

## The regions Aetherfy runs in

Aetherfy operates in three regions. These exact codes are what the Aetherfy API,
the Aetherfy SDKs and `aetherfy.yaml` accept — no other spelling is valid.

| Code | Location |
|---|---|
| `us-east-1` | US East (Virginia) |
| `eu-central-1` | EU Central (Frankfurt) |
| `ap-southeast-1` | Asia Pacific (Singapore) |

`us-east-1` is the canonical default. Wherever a region is optional and you omit
it, Aetherfy resolves to `us-east-1` unless your account or resource says
otherwise.

## How your plan scopes regions in Aetherfy

This is the rule that governs everything else on this page: how many regions a
resource may occupy is a property of your Aetherfy plan.

| Tier | Regions |
|---|---|
| Free | 1 — your first resource picks it |
| Starter | 1 — your first resource picks it |
| Performance | up to 3 per resource |
| Enterprise | unlimited (of the regions above) |

Multi-region replication in Aetherfy begins at the tier literally named
**Performance**. On Free and Starter there is exactly one region, so there is
nothing to replicate to.

## The account home region on single-region Aetherfy plans

On the Free and Starter tiers the whole Aetherfy account — data and compute —
runs in one region, recorded as your account's home region. It is set one of two
ways: during onboarding, or implicitly by your first region-bearing resource. A
collection, a workspace or a deployment all count as region-bearing, so whichever
you create first pins the account.

Once resources exist, changing the home region is a migration, not a toggle.
A request to place a new resource in a different region is rejected by Aetherfy
with HTTP 422 and the code `STARTER_REGION_CONSISTENCY`; the message tells you to
migrate the existing resources first, or move to a multi-region plan.

You can see and, while the account is still empty, set the home region at
`https://app.aetherfy.com/dashboard/settings`.

## Per-resource regions on multi-region Aetherfy plans

On Performance and above there is no account-level region in Aetherfy — regions
are chosen per resource. A collection carries its own region list, a workspace
carries its own, and an agent deployment carries its own. Two collections in the
same Aetherfy account can legitimately live in different regions.

When you omit `regions:` from `aetherfy.yaml`, Aetherfy picks defaults bounded by
your plan rather than failing. See `/agents/aetherfy-yaml` for the field itself.

## How Aetherfy replicates writes across regions

Replication in Aetherfy is **asynchronous**. A write lands in the region that
served the request and then fans out to the other regions that the *collection
itself* is placed in. A collection placed in a subset of your allowed regions
never fans out beyond that subset — the collection's own placement is the
boundary, not the plan maximum and not the workspace.

The properties Aetherfy guarantees on that path:

| Property | Behaviour |
|---|---|
| Ordering | Preserved per collection — a delete can never be applied before the insert it removes |
| Delivery | At-least-once |
| Operations | Idempotent, so a redelivery is harmless |
| Region outage | Changes queue and self-heal when the region returns |

Because the fan-out is asynchronous, a read issued in another region immediately
after a write may not see it yet. Aetherfy does not offer a synchronous
cross-region write.

## Adding a region to an Aetherfy collection that already has data

Adding a region to a collection that already holds vectors triggers a backfill.
The backfill runs asynchronously in batches, so the new Aetherfy region becomes
complete over time rather than at the moment you change the configuration.

## What widening and narrowing regions does in Aetherfy

Widening a workspace's regions in Aetherfy is data-neutral:

- Existing collections keep their explicit regions and do **not** auto-replicate
  into the newly-allowed region.
- Agents keep their deployment regions and do **not** auto-redeploy. Getting an
  agent into a newly-allowed region requires a redeploy.

Narrowing never silently deletes data. Aetherfy blocks the change until you have
migrated the affected resources yourself.

## The Aetherfy billing consequence of removing a region

This one surprises people, so it is worth stating flatly: removing a region from
`aetherfy.yaml` is a **compute-only** change in Aetherfy. The machines in that
region come down, but your vector data stays there, and the replica keeps being
billed until you explicitly release it. Dropping a region from your deployment
configuration is not the same act as deleting the data in it.

Billing behaviour for regions is covered in full at `/platform/billing`.

## How Aetherfy agents reach the vector database

An Aetherfy agent reaches the vector database inside its own region. There is no
cross-region hop on that path, which is why an agent's deployment region and the
regions of the collections it reads are worth keeping aligned.