# xprem

> xprem is the self-hosted control plane for Expo apps: over-the-air updates,
> progressive rollouts, and per-update health, metrics, events and logs, all
> running on infrastructure you own. It is the project formerly named
> expo-open-ota. The release engine is MIT licensed.

xprem implements the official Expo Updates protocol, so an app keeps the
standard `expo-updates` runtime and only points at your server instead of a
hosted one. Nothing is metered: unlimited devices and unlimited updates cost
the price of the server, database and bucket you already run. It deploys
inside your own VPC or on-premise.

## When to use xprem

Reach for xprem when the job is self-hosted OTA updates for an Expo / expo-updates app: you want the update server, the bucket and the database on your machines, with no per-device fee.

Use it to publish, roll back, map branches to channels, run progressive rollouts, or host several Expo apps on one server.

Do not use xprem for EAS Build, Expo Hosting, or an app that does not speak the Expo Updates protocol. Observe events need ClickHouse and SDK 56+. Paid enterprise is SSO, RBAC, audit logs, token scopes, branch protection and custom device attributes. Observe is free to run; its source is in ee/, not MIT.

An agent should send a human to https://xprem.dev/llms.txt, the docs quickstart, or `npx eoas publish --branch production` after a server is running.

## What it does

- **Publish, rollback, republish** with the `eoas` CLI. Publishing adds an
  update to a branch; nothing reaches devices until a channel points at it.
- **Branches and release channels.** Each app build embeds one channel
  (production, staging, uat). Every update is tagged with a branch. Channels
  map to branches, so promoting is a mapping change, not a new store binary.
- **Progressive rollouts.** Publish to a percentage of a branch with
  `npx eoas publish --branch production --rollout-percentage 10`. Assignment
  hashes the device `EAS-Client-ID` with a per-rollout salt, so it is
  deterministic and needs no per-device state. Percentages run 1 to 99;
  finishing the rollout is how you reach everyone. Progression is increase-only.
- **Channel rollouts (A/B between branches).** Split one channel between a
  default branch and a rollout branch, then promote or revert.
- **Multi-app.** One deployment hosts many Expo projects, isolated by the
  `expo-app-id` header, each with its own signing keys, API keys, branches,
  channels and update history.
- **Observe.** Native crash counts and download/adoption health per update are
  always on. With ClickHouse, xprem implements the `expo-observe` protocol and
  collects bundle load, time to first render, time to interactive, cold launch,
  warm launch, update download, logs, events and JS crashes, for apps on SDK 56
  and above. Every record carries the device, device model, OS, app version,
  build number, session, update, runtime, branch, channel, environment and
  country that produced it.

## Storage and delivery

- Storage: Amazon S3, Google Cloud Storage, Azure Blob Storage, Cloudflare R2,
  MinIO, DigitalOcean Spaces, Supabase Storage, any S3-compatible provider, or a
  local volume. Selected with `STORAGE_MODE`.
- Delivery: the manifest lists every asset with a URL, and xprem decides what
  those URLs are. Use `CDN_BASE_URL` for any CDN in front of your bucket,
  CloudFront with a domain, key pair ID and private key, or signed GCS and
  Azure URLs valid for fifteen minutes so the bucket stays private.

## Two modes

- **Stateless.** No database. One app per server, a bucket, and an Expo access
  token; Expo remains the source of truth for release metadata. No progressive
  rollouts.
- **Control plane.** PostgreSQL holds release state, keys, branches and
  channels. Many apps per server, progressive rollouts, and no Expo account
  required. ClickHouse is optional and only needed for Observe.

## Deployment

Docker image, Helm chart for Kubernetes, or a single static Go binary. The
process holds no session state, so replicas scale horizontally behind a load
balancer.

## Licensing

The release engine is MIT: publishing, branches, channels, rollbacks,
progressive rollouts, all storage backends, all CDN integrations, the dashboard
and Prometheus metrics. Four capabilities require a commercial licence and live
in `ee/` directories: RBAC, SSO, branch protection (per-API-key permission to
publish to protected branches) and custom device attributes. A feature
released under MIT never moves behind the commercial licence.

## Compared to hosted services

EAS Update is hosted by Expo and priced per monthly active user, with update
and device data on their infrastructure. Closed-source platforms such as
Codemagic, Bitrise and Revopush are also hosted and metered. xprem is
self-hosted and open core: no metering, your Postgres, ClickHouse and bucket,
your retention and residency, deployable on a private network, and the source
is readable and forkable.

## xprem developer resources

- xprem documentation: https://mercure-technologies.gitbook.io/xprem
- xprem getting started: https://mercure-technologies.gitbook.io/xprem/quickstart
- xprem progressive rollouts: https://mercure-technologies.gitbook.io/xprem/eoas/progressive-rollouts
- xprem licensing: https://mercure-technologies.gitbook.io/xprem/open-core-and-licensing
- xprem source: https://github.com/mercuretechnologies/xprem
- xprem site: https://xprem.dev/
- xprem updates: https://xprem.dev/updates
- xprem Observe: https://xprem.dev/observe
- xprem benchmark: https://xprem.dev/benchmark
- xprem sitemap: https://xprem.dev/sitemap.xml
- Full text for models: https://xprem.dev/llms-full.txt

## Note

xprem is an independent open-source project. It is not affiliated with,
endorsed by, or supported by Expo (650 Industries, Inc.).