# Locations & replicas

A service runs in one or more locations — the places in the world its replicas run — and each location carries its own replica count. This page covers where locations come from, adding and removing them, and how traffic reaches a service that runs in several.

## What a location is

A location is a cloud region Koo's hosting layer runs in. Its id names the cloud provider and that provider's region code — `aws-us-east-2`, for example — and the console shows each one as the provider plus the region code.

Your account has a set of enabled locations. Every environment offers that same set, and each service picks its own subset — locations belong to the service, so two services in the same environment can run in different places.

## Add or remove a location

1. 
2. 
3. 
4. 
5.

Location edits are [staged changes](/docs/projects/staged-changes) — nothing moves until you deploy.

## Replicas per location

Each location row carries its own replica count — a fixed number, not an autoscaling range. Every replica runs at the service's CPU and memory; see [Resources & scaling](/docs/services/resources-and-scaling) for sizing and the per-location replica ceiling your plan sets.

For a serverless service the count is the scale ceiling — it scales from zero up to that many replicas in each location; see [scale to zero](/docs/services/scale-to-zero). A [cron service](/docs/services/cron-jobs) has no replica count: it runs one instance per location on each tick.

## Single-location services

Databases always run in exactly one location, with exactly one replica — see [Postgres](/docs/databases/postgres). A web service with a [persistent volume](/docs/services/volumes) is pinned to one location too, because the disk lives there.

For these, the **Locations & replicas** card shows one pinned row with a **Change** button that swaps the location. Data does not travel with it: moving a volume service destroys the disk's data — the volumes page covers that warning — and moving a database leaves its stored data behind, so the database starts empty in the new location.

## Plan limits

> **Note:**
>
> Running a service in more than one location requires a paid plan, and each plan caps how many locations a single service may run in — the numbers are on [usage and limits](/docs/account/usage-and-limits).

At your plan's cap, the console stops offering **Add location** and names the plan that lifts the cap. The [API](/api/services) rejects a write over the cap with a `quota_exceeded` error naming that plan.

## How traffic reaches your service

A service has one public URL no matter how many locations it runs in. Each request is routed to the nearest location, so visitors reach the replicas closest to them.