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.