Deployment regions and strategies

When creating a Coveo organization, you select a primary deployment region. This is the physical center of your organization, which hosts all services and data required for your organization to function. Coveo also offers the possibility of deploying to additional satellite regions, which duplicate only the contents required to perform search requests. As such, satellite regions don’t replace your primary region, but can respond to end user queries to improve query time.

This article provides details on primary and satellite deployment regions, and explains how to leverage them to implement two deployment strategies:

  • Data residency, where you only deploy to a primary region in order to have all of your data reside in the target region.

  • Multi-region deployments, where you deploy to satellite regions in addition to your primary region to improve search response times for international users.

The currently available regions are:

  • US East

  • Ireland

  • Australia

For pricing or information about additional regions that may be added in the future, contact Coveo Sales.

  • These various deployment regions are only available for non-HIPAA, production (i.e., not non-production) Coveo organizations.

  • For the production organizations of all Coveo paying customers, multiple AWS availability zones (AZ) are used to provide higher availability and fault tolerance.

About primary and satellite regions

Your primary deployment region holds all of your Coveo data and is where your main organization processes take place. Satellite regions only contain duplicates of the content and services required for your end users to perform queries, namely your index, ML models, and the Search API. The Coveo indexing pipeline, Usage Analytics service, and main Platform services remain exclusively in the primary region.

Primary region Satellite regions

Complete Coveo organization:

  • Search API
  • ML - Model building and serving
  • Index and indexing pipeline
  • Usage analytics
  • Logs
  • etc.

Only what's required to handle search requests:

  • Search API
  • ML - Model serving
  • Index

Data residency

Data residency is a deployment strategy that aims at storing all your Coveo data in a single region. A typical use case is companies based outside of the United States that don’t want their data to be stored in the United States. To handle such scenarios, select another primary deployment region, such as Ireland or Australia, as your primary deployment region, with no satellite deployment.

Data residency configuration

Assuming you have contacted Coveo Sales and have completed the administrative tasks required to deploy exclusively in your target primary region, the technical configuration is almost seamless. You only need to use the dedicated domain name in your Coveo API requests and when navigating to the Administration Console.

When using the Push API:

Region Domain

US East



When using all other Coveo APIs, and when navigating to the Administration Console:

Region Domain

US East



Configuring your search interface for European data residency

You have contacted Coveo Sales and have taken care of the administrative tasks required to make Ireland your primary and only deployment region.

JavaScript Search Framework

If using the Coveo JavaScript Search Framework, you set your search endpoint to rather than

Coveo.SearchEndpoint.configureCloudV2Endpoint(<YOUR_COVEO_CLOUD_ORGANIZATION_ID>, <YOUR_SEARCH_TOKEN>, "");

If using the Atomic library, you can set your platformUrl when initializing your atomic-search-interface, as seen below:

(async () => {
  await customElements.whenDefined('atomic-search-interface');
  const searchInterface = document.querySelector('#search');

    await searchInterface.initialize({
    organizationId: '<ORGANIZATION_ID>',
    platformUrl: '',


If using the Headless library, you can set the platformUrl as part of your SearchEngineConfiguration when initializing a Headless Search Engine, as seen below:

export const headlessEngine = buildSearchEngine({
  configuration: {
    organizationId: "<ORGANIZATION_ID>",
    accessToken: "<ACCESS_TOKEN>",
    platformUrl: ""

Multi-region deployments

The goal of multi-region deployments is to reduce query times for international end users by deploying satellite regions. Rather than having all end user queries travel to and from your primary deployment region, the service automatically routes them to your closest deployment [1], primary or satellite, which can dramatically reduce query response time. Additionally, if a satellite deployment encounters an issue, the service routes queries to your primary deployment region. For Search API requests specifically, the closest region will always be favored first, and if the Search API can’t connect to it, the main region and satellites regions alike redirect requests to each other as needed. This increases the overall resiliency of your search solution.

Search response time examples


While the following is a real-life example, it’s merely an example, meant to illustrate the logic of multi-region deployments. Exact figures vary significantly from organization to organization, from query to query, and from caching along the Internet.

You have no satellite deployment. When an end user located in Paris makes a query, this query goes to your primary and only deployment, in the US East Region. The results then travel back to Paris. The query suggestions reach the end user after a total of 283 milliseconds, and the results after a total of 441 milliseconds.

You now add a satellite deployment in Ireland. When an end user located in Paris makes a query, this query is now automatically routed to your Ireland deployment. The query suggestions reach the end user after a total of 102 milliseconds, and the results after a total of 168 milliseconds.

The following table summarizes the above scenarios:

Before After
Query time (ms) 441 168
Query suggest time (ms) 283 102


Assuming you have contacted Coveo Sales and have taken care of the administrative tasks required to deploy your organization over satellite regions, the technical configuration is almost seamless. As soon as a new region is added, a custom domain is created: <ORG_ID> Use this dedicated domain name in your Coveo Search API and UA write requests.

Instead of or, you need to use <ORG_ID>

Concretely, that will mean using this domain name when making requests to the Search API and UA Write API directly or when configuring your search interface endpoints, as shown in the JavaScript Search Framework example below:

  // ...
  Coveo.SearchEndpoint.configureCloudV2Endpoint("<ORG_ID>", "<SEARCH_TOKEN>", "https://<ORG_ID>");
  // ...
// ...
<div class="CoveoAnalytics" data-endpoint="https://<ORG_ID>"></div>
// ...

If you’re unsure what your custom domain is, you can call the global configuration endpoint via Swagger UI (swagger-eu | swagger-au) to find out.

1. You can’t manually force queries into one particular region.