> For the complete documentation index, see [llms.txt](https://mercure-technologies.gitbook.io/expo-open-ota/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mercure-technologies.gitbook.io/expo-open-ota/controle-plane-mode/overview.md).

# Overview

## Control plane mode

Control plane mode lets you run the complete OTA release workflow yourself.

Expo Open OTA stores release state in PostgreSQL. It manages apps, credentials, branches, channels, and update history.

Use this mode for several applications or independent release management.

### How it works

The dashboard creates an application and its signing identity. It provides a certificate for the Expo project.

Your CI publishes with an API key scoped to that application. The server records the update and its release metadata in PostgreSQL.

When a client requests an update, the server resolves its app, channel, and branch locally. It returns the matching manifest and serves assets from your storage.

Publishing and serving updates need no Expo account or Expo API call.

```mermaid
flowchart LR
    CLI["eoas CLI"] -->|publish| SRV["Expo Open OTA"]
    APP["expo-updates clients"] -->|manifest| SRV
    SRV --> ST[("Your storage (bucket)")]
    SRV --> PG[("Postgres")]
```

### What the control plane manages

Each application has isolated state:

* **Identity:** App ID, signing certificate, and encrypted private key.
* **Access:** Named API keys for publishing and their usage history.
* **Release routing:** Branches, channels, and update history.

This state lives in your database. Your storage bucket continues to hold update assets.

The control plane also manages who operates the dashboard itself: user accounts live in the same database, each one an admin or a read-only member. See [Users](/expo-open-ota/dashboard/users.md).

#### Multiple apps, one deployment

A single deployment can host many Expo projects. Each application has its own signing keys, API keys, branches, and channels.

Clients select their application with the `expo-app-id` header.

```mermaid
flowchart TD
    C1["client · app A"] --> SRV["Expo Open OTA<br/>one deployment"]
    C2["client · app B"] --> SRV
    C3["client · app C"] --> SRV
    SRV --> PG[("Postgres")]
    PG --> A["App A<br/>keys · API keys · branches · channels"]
    PG --> B["App B<br/>keys · API keys · branches · channels"]
    PG --> C["App C<br/>keys · API keys · branches · channels"]
```

Stateless mode reads one app ID. Each additional app needs another server, storage configuration, and key setup.

In control plane mode, create additional applications from the dashboard.

#### Credentials and signing

Create an app and the server generates an RSA key pair. It encrypts the private key at rest.

Download the code-signing certificate from the dashboard. Add it to your project to enable signed updates.

API keys are scoped to one application. Use separate keys for each CI environment or workflow.

Keys are stored as hashes. The server verifies a key but cannot reveal it.

### When to use it

We strongly recommend control plane mode for new deployments. Future release-management capabilities will focus on this mode.

Choose control plane mode when you need one or more of these:

* Several Expo applications behind one OTA deployment.
* Per-application publishing credentials and code signing.
* Release metadata and channel mappings managed outside Expo.

If you operate one app and value minimal infrastructure, use [stateless mode](/expo-open-ota/stateless-mode/overview.md).

### Control Plane vs stateless

| Feature                          | Stateless                                | Control plane                  |
| -------------------------------- | ---------------------------------------- | ------------------------------ |
| **Apps per server**              | One                                      | Many                           |
| **Adding an app**                | Deploy another server                    | Create it in the dashboard     |
| **Infrastructure for many apps** | One server per app                       | One server and PostgreSQL      |
| **Signing certificates**         | Generate and manage them                 | Generate and download them     |
| **Publish authentication**       | Expo access token                        | Per-app API key                |
| **Channel mapping**              | Expo API                                 | Your database                  |
| **Manage apps and keys**         | Edit environment variables and redeploy  | Dashboard at runtime           |
| **Dashboard accounts**           | One, from `ADMIN_EMAIL`/`ADMIN_PASSWORD` | Many, managed in the dashboard |
| **Expo account required**        | Yes                                      | No                             |
| **Progressive Rollouts**         | No                                       | Yes                            |

### Security model

The server encrypts stored keys with a master key you provide. Keep that key outside PostgreSQL.

PostgreSQL never stores private signing keys in plaintext. A database dump alone cannot recover them.

Each encrypted key is bound to its application. A misplaced key fails to decrypt rather than signing another application's updates.

### Operational requirements

* **PostgreSQL:** Provision, monitor, and back up a production database.
* **Master key:** Store it in your secret manager. Back it up separately from the database.

{% hint style="warning" %}
Losing the master key makes its protected signing keys unrecoverable.
{% endhint %}

Control plane mode fits multi-app deployments. It also fits teams that need complete ownership of their OTA release state.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://mercure-technologies.gitbook.io/expo-open-ota/controle-plane-mode/overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.