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

> ## Agent Instructions
> Agent home for Datum, with what it is, pricing, and how to act: https://agents.datum.net
> If you can only fetch URLs: read https://www.datum.net/docs/llms.txt in full and open the most specific page for the task. Commands, limits, and field paths are on task, operations, and limits pages, not on section overviews. Pages described as "Documentation is coming soon" are placeholders.
> If you have a shell or can save files: download https://www.datum.net/docs/llms-full.txt (every page, about 740 KB) once and search it with grep, instead of fetching pages one at a time.
> datumctl describes itself: `datumctl api-resources` lists resource types and `datumctl explain <resource>` shows a schema. To act on live resources, use Datum MCP or datumctl. To search the docs, use the Docs MCP server at https://www.datum.net/docs/mcp.

# Locations

> Datum's global footprint of Regions and Availability Zones, and how to check which locations are available to use in your project

Datum’s infrastructure footprint is organized into points of presence (PoPs) that are packaged into Regions and Availability Zones (AZs). See our [Locations](https://www.datum.net/locations/) for a visual overview of all PoPs.

Each Region represents a specific geographic and network boundary, while each AZ provides independent capacity within that Region. This structure supports predictable latency, fault isolation, and regulatory alignment.

Similar to the large public clouds, Datum uses a country-anchored naming format with the following elements:

| **Field** | **Description** |
| - | - |
| Geography | Two-letter ISO country code (example: US, DE, IN) |
| Cardinal Direction | Directional indicator within the country: north, south, east, west, or central. |
| Number | Region index within that location. |
| Count | Availability Zone identifier: a, b, c, etc. |

For example, here is how we describe the first region and availability zone in the eastern US.

```text theme={null}
<Geography>-<Location>-<Number><Count>
```

`Example: us-east-1a`

Regions and AZs are defined by distance and policy boundaries.

* When Points of Presence in the same country are separated by more than about 5 milliseconds round-trip time (RTT), Datum creates a new Region.
* If multiple PoPs exist in the same metro but operate independently (for example, separate network clusters or facilities), they become separate AZs. Increment the Count value to the next letter.
* If PoPs are within about 5 milliseconds RTT and part of the same operational domain, they remain in the same Region. Example: us-east-1a, us-east-1b, us-east-1c.

*Note: regulatory and export control requirements may restrict or define where data and workloads can reside. These boundaries take precedence over latency-based placement rules.*

## Regions

| **Region Code** | **Metropolitan Area** |
| - | - |
| ae-north-1 | Dubai |
| au-east-1 | Sydney |
| br-east-1 | São Paulo |
| ca-east-1 | Toronto |
| cl-central-1 | Santiago |
| de-central-1 | Frankfurt |
| gb-south-1 | London |
| in-west-1 | Mumbai |
| jp-east-1 | Tokyo |
| nl-west-1 | Amsterdam |
| sg-central-1 | Singapore |
| us-central-1 | Dallas |
| us-east-1 | Ashburn |
| us-east-2 | New York City |
| us-west-1 | San Jose, California |
| za-central-1 | Johannesburg |

## Check what's available to your project

The table above is Datum's global footprint. What you can deploy into is a narrower, per-project question: Datum represents each usable location as a `Location` resource, and the ones inside your project's own control plane are the ones offered to you.

`datumctl get locations` lists them:

```bash theme={null}
datumctl get locations --project your-project-id
```

```text theme={null}
NAME           CLASS           CITY   AGE   READY   REASON
us-central-1   datum-managed   DFW    20h
us-east-1      datum-managed   IAD    20h
```

Each row is a location you can place work in today. `NAME` is the identifier you reference elsewhere, and matches the region codes in the table above: `us-central-1` is Dallas, `us-east-1` is Ashburn. `CITY` is the airport-style code for the metro it serves. `CLASS` is the kind of capacity behind it, where `datum-managed` is Datum's own footprint.

> [!TIP]
>
> This list reflects your active project scope. If a location you expect is missing, confirm you are pointed at the right project. See [Contexts & scoping](/docs/datumctl/contexts-and-scoping.md).

For the full definition of a location, including its topology, request YAML or JSON:

```bash theme={null}
datumctl get location us-central-1 --project your-project-id -o yaml
```

```yaml theme={null}
apiVersion: locations.miloapis.com/v1alpha1
kind: Location
metadata:
  name: us-central-1
spec:
  locationClassRef:
    name: datum-managed
  topology:
    topology.datum.net/city-code: DFW
    topology.datum.net/region: us-central-1
```

## Region tracing

Visit [https://edge.datum.net/](https://edge.datum.net/) to learn which Datum Region and availability zone you're reaching via anycast. If you're using Datum Tunnels, this will be your entrypoint into our network.

You can also access our zones and locations programmatically:

* JSON structured response [https://edge.datum.net/api/edge-info](https://edge.datum.net/api/edge-info)
* Plaintext [https://edge.datum.net/api/trace](https://edge.datum.net/api/trace)

## Availability commitments

Uptime percentages, service credits, and per-location availability commitments aren't documented yet. Datum is in active development; see [Account setup](/docs/getting-started/account-setup.md) for the current beta terms.


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