# 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. ## 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. ## Links - Documentation: https://mercure-technologies.gitbook.io/xprem - Getting started: https://mercure-technologies.gitbook.io/xprem/quickstart - Progressive rollouts: https://mercure-technologies.gitbook.io/xprem/eoas/progressive-rollouts - Licensing: https://mercure-technologies.gitbook.io/xprem/open-core-and-licensing - Source: https://github.com/mercuretechnologies/xprem ## Note xprem is an independent open-source project. It is not affiliated with, endorsed by, or supported by Expo (650 Industries, Inc.). ## Frequently asked questions ### Does xprem only work with Expo? It requires expo-updates in your app, yes. That is the protocol xprem implements, and it is what lets you keep the standard runtime instead of a proprietary client. expo-observe is separate: without it xprem still runs your releases, health and rollouts, you just do not get the events, metrics and logs. We bet on the Expo ecosystem on purpose. The packages are MIT, the community is large, and expo-updates is the default release path for React Native. ### Do I need an Expo account? Not in control plane mode. xprem holds the release metadata itself and authenticates publishing with a per-app API key. Stateless mode is the exception: it uses Expo as the source of truth and does need an Expo access token. ### What do I have to run? One Go process, a Postgres database and an object storage bucket. Add ClickHouse only when you want the full Observe layer. Everything ships as a single Docker image, a Helm chart or a static binary. ### Do I have to change my app to migrate? You point expo-updates at your own server URL and publish through the eoas CLI. The manifest, the asset download and the runtime behaviour are the standard protocol, so the client side of your app stays as it is. ### Where do the update bundles live? In your bucket. S3, Google Cloud Storage, Azure Blob, Cloudflare R2, MinIO, DigitalOcean Spaces, Supabase Storage, any S3-compatible provider, or a local volume. xprem writes to it and hands devices a URL into it. ### How is it priced? There is no per-user pricing. Nothing is metered, so unlimited devices and unlimited updates cost you the server, the database and the bucket you already run. The release engine is MIT; only RBAC, SSO, branch protection and custom device attributes need a commercial licence. ### What is MIT and what is commercial? The release engine is MIT: publishing, branches, channels, rollbacks, progressive rollouts, every storage backend, every CDN integration, the dashboard and Prometheus metrics. Enterprise adds RBAC, SSO, branch protection and custom device attributes, and lives in ee/ directories under a commercial licence. A feature released under MIT never moves behind the commercial licence. ### Can I query the data with my own tools? Yes. Observe writes into a ClickHouse you own, so you can point Grafana, Datadog, PostHog or plain SQL at it. Release state is in your Postgres. Nothing is locked behind an API we control. ### How does xprem compare to EAS Update? EAS Update is hosted by Expo and priced per monthly active user, and your update and device data lives on their infrastructure. xprem runs on yours: no metering, data in your own Postgres, ClickHouse and bucket, deployment on a private network, and per-update health, metrics, events and logs. EAS Update is the faster start for a small app; xprem is for teams that need to own the release path. ### Is it affiliated with Expo? No. xprem is an independent open-source project. It is not affiliated with, endorsed by, or supported by Expo (650 Industries, Inc.).