--- title: "Deploy Open Wearables" description: "Self-host one API for Garmin, Oura, Whoop and Apple Health data." category: "AI/ML" url: https://railway.com/deploy/self-hosted-open-wearables --- # Deploy Open Wearables Self-host one API for Garmin, Oura, Whoop and Apple Health data. **[Deploy Open Wearables on Railway](https://railway.com/template/self-hosted-open-wearables)** Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/self-hosted-open-wearables/manifest.json - **Creator:** blueorange - **Category:** AI/ML ## Template content ### Redis https://cdn.sanity.io/images/sy1jschh/production/0ce0bfdcfbdbf69662b1116671f97c2dd788b655-157x157.svg - **Image:** redis:8.2.1 - **Start command:** `/bin/sh -c "rm -rf $RAILWAY_VOLUME_MOUNT_PATH/lost+found/ && exec docker-entrypoint.sh redis-server --requirepass $REDIS_PASSWORD --save 60 1 --dir $RAILWAY_VOLUME_MOUNT_PATH"` ### frontend - **Source:** the-momentum/open-wearables ### celery-flower - **Source:** the-momentum/open-wearables ### celery-beat - **Source:** the-momentum/open-wearables ### celery-worker - **Source:** the-momentum/open-wearables ### backend - **Source:** the-momentum/open-wearables ### Postgres https://devicons.railway.app/i/postgresql.svg - **Image:** ghcr.io/railwayapp-templates/postgres-ssl:18 ## Documentation # Deploy and Host Open Wearables on Railway ![Open Wearables logo](https://openwearables.io/favicon.svg) Open Wearables is an MIT-licensed, self-hosted platform that turns data from a dozen wearable brands into **one normalized health API**. Garmin, Oura, Whoop, Polar, Suunto, Strava, Withings, Ultrahuman and Google Health connect through OAuth. Apple Health, Health Connect and Samsung Health come in through mobile SDKs. Your app reads one schema for sleep, workouts, heart rate, HRV and daily summaries, and AI agents can query it through a built-in MCP server. This template runs the full stack on Railway: the FastAPI backend, the developer portal, Celery worker, scheduler and monitor, Postgres and Redis. Hosted wearable APIs such as Terra and Junction start at $300–499/month. Here the infrastructure costs about $15–30/month, and health data never leaves your database. --- ## What This Template Deploys | Service | Purpose | |---|---| | **backend** | FastAPI app with the unified REST API, provider OAuth callbacks, webhooks, the MCP server and Swagger docs at `/docs`. | | **frontend** | SvelteKit developer portal: API keys, users, connection links, sync history, webhook debugging and provider credentials. | | **celery-worker** | Pulls data from providers, processes uploads such as Apple Health exports, and delivers webhooks. | | **celery-beat** | Schedules recurring syncs for every connected user. | | **celery-flower** | Dashboard for watching the task queue. | | **Postgres** | PostgreSQL 18 with SSL. Users, normalized health records, API keys and encrypted provider tokens. | | **Redis** | Redis 8.2.1, password-protected and saved to a volume. Celery broker and cache. | All five app services build from the `the-momentum/open-wearables` repository and share the backend's secret key, the database and Redis through Railway references. --- ## About Hosting Open Wearables Every wearable vendor has its own OAuth flow, data format, rate limits and webhook style. Supporting even three of them in a health or fitness app is months of integration work, and it keeps breaking as vendors change their APIs. Aggregators like Terra and Junction sell that layer as a service, priced per month and per connected user, with your users' biometrics flowing through their servers. Open Wearables is the same layer as software you run. A user opens a connection link from your app, approves access with their provider, and the worker starts syncing. Your app then calls one API and gets the same fields whatever device the data came from. **Why so many services?** Syncing is background work. The backend answers API calls and OAuth callbacks quickly, the worker does the slow provider requests, beat triggers scheduled syncs, and Redis queues the jobs between them. **Set the admin login first.** With `ENVIRONMENT=production`, Open Wearables won't accept its default admin password. Set `ADMIN_EMAIL` and `ADMIN_PASSWORD` on the backend before the first deploy. They are only used to create the first admin account, so changing them later has no effect. **Provider credentials come next.** Each cloud provider needs a developer app (client ID and secret) with your backend's callback URL. You add these in the portal, so you can start with one provider and add more over time. Typical cost: **~$15–30/month** on Railway for all seven services at small scale. Terra's Quick Start plan is from $499/month, and Junction's Launch plan is $300/month. --- ## Deploy Open Wearables in Under 10 Minutes 1. On the **backend** service, set `ADMIN_EMAIL` and a strong `ADMIN_PASSWORD`. 2. Click **Deploy on Railway**. The first build of the five app services takes several minutes. 3. Make sure **backend** and **frontend** each have a public domain under **Settings** and **Networking**. Generate any that are missing, then redeploy so the URL variables pick them up. 4. Open the frontend domain, sign in, and create an API key. 5. Register a developer app with Garmin, Oura or another provider, add its credentials in the portal, and send a test user a connection link. Data then syncs on a schedule, and your app reads it from the API or by webhook. --- ## Common Use Cases - **Fitness and coaching apps.** Show workouts, recovery and sleep from whatever device each client wears. - **Digital health and research.** Collect wearable data from study participants in a database you control. - **Corporate wellness.** Aggregate step, sleep and activity data across many device brands. - **AI health assistants.** Let an agent answer questions about a user's sleep or training through the MCP server. - **Replacing a paid aggregator.** Move off per-user wearable API pricing to flat infrastructure costs. - **Mobile apps with Apple Health.** Use the iOS, Android, Flutter or React Native SDKs to send on-device data to your backend. --- ## Configuration | Variable | Required | Description | |---|---|---| | `ADMIN_EMAIL` | ⚠️ Set before deploy | First admin account. Empty uses `admin@admin.com`. | | `ADMIN_PASSWORD` | ⚠️ Set before deploy | First admin password. The default is refused in production. | | `SECRET_KEY` | 🔐 Auto-generated | 64-character key that signs logins and encrypts provider tokens. Shared by all app services. | | `FRONTEND_URL`, `CORS_ORIGINS` | ✅ Auto-set | The portal's public URL, used for redirects and allowed origins. | | `API_URL`, `VITE_API_URL` | ✅ Auto-set | The backend's public URL, used by the scheduler and the portal. | | `DB_HOST`, `DB_PORT`, `DB_NAME`, `DB_USER`, `DB_PASSWORD` | ✅ Auto-injected | Postgres connection details. | | `REDIS_HOST`, `REDIS_PORT`, `REDIS_USERNAME`, `REDIS_PASSWORD` | ✅ Auto-injected | Redis connection for Celery. | | `REDIS_DB` | ✅ Set | `0`. | | `ENVIRONMENT` | ✅ Set | `production`, which turns off debug features. | | `ACCESS_TOKEN_EXPIRE_MINUTES` | ✅ Set | `60`, the portal login session length. | | `SENTRY_ENABLED` | Optional | `false`. Set to `true` with a Sentry DSN to report errors. | **Keep `SECRET_KEY` stable.** It encrypts stored provider tokens, so changing it disconnects every user's devices. **Connecting AI clients.** Point your MCP client at the Open Wearables MCP server with an API key. Records it reads are sent to the model provider behind that client, so check your privacy rules first. --- ## Open Wearables vs. Alternatives | | Open Wearables on Railway | Terra | Junction | Building it yourself | |---|---|---|---|---| | **Monthly cost** | ~$15–30 usage | From $499 | From $300 | Engineering time | | **Self-hosted** | ✅ Yes | ❌ No | ❌ No | ✅ Yes | | **Per-user fees** | ✅ None | ❌ Credits per connection | ⚠️ User tiers | ✅ None | | **Unified data model** | ✅ Yes | ✅ Yes | ✅ Yes | ❌ You design it | | **Mobile SDKs** | ✅ iOS, Android, Flutter, RN | ✅ Yes | ✅ Yes | ❌ You build them | | **MCP server for AI** | ✅ Built in | ⚠️ Not core | ⚠️ Not core | ❌ No | | **License** | ✅ MIT | ❌ Proprietary | ❌ Proprietary | ✅ Yours | --- ## Dependencies for Open Wearables Hosting - Railway account. Hobby fits testing; Pro for more workers and larger databases. - Developer apps with each cloud provider you want to support (Garmin, Oura, Whoop and others). - Optional: a mobile app using the Open Wearables SDK for Apple Health, Health Connect or Samsung Health. ### Deployment Dependencies - [Open Wearables on GitHub](https://github.com/the-momentum/open-wearables): source code, SDKs and docs - [Open Wearables website](https://www.openwearables.io): overview and guides - [Railway Private Networking](https://docs.railway.com/guides/private-networking): how services connect - [Railway Volumes](https://docs.railway.com/volumes): persistence for Postgres and Redis ### Implementation Details The backend, frontend and three Celery services all build from the same GitHub repository. Each one reads its own database and Redis settings as references, so credentials live only on the Postgres and Redis services. The portal is built with the backend's public URL baked in through `VITE_API_URL`, so redeploy the frontend after changing the backend's domain. --- ## Frequently Asked Questions **What is Open Wearables?** An MIT-licensed platform that connects many wearable providers and exposes their data through one normalized REST API, with webhooks, mobile SDKs and an MCP server. **How much cheaper is it than Terra or Junction?** About $15–30/month on Railway for the whole stack, with no per-user charges. Terra's entry plan is from $499/month and Junction's Launch plan is $300/month. **Which devices are supported?** Garmin, Oura, Whoop, Polar, Suunto, Strava, Withings, Ultrahuman and Google Health over OAuth, plus Apple Health, Health Connect and Samsung Health through the mobile SDKs and Apple Health export uploads. **Why can't I log in to the portal?** In production the default admin password is refused. Set `ADMIN_EMAIL` and `ADMIN_PASSWORD` on the backend before the first deploy, and use those to sign in. **Is my users' health data shared with anyone?** No. Data goes from the provider straight to your backend and Postgres on Railway. It leaves only if you send it somewhere, for example through webhooks or an MCP client. **Why is data not syncing?** Check that celery-worker and celery-beat are running and connected to Redis, and that the provider's client ID, secret and callback URL are set in the portal. --- ## Why Deploy and Host Open Wearables on Railway? Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it. By deploying Open Wearables on Railway, you get your own wearable data API with background syncing, a developer portal and AI access, at a flat monthly cost instead of per-user fees. ## Similar templates - [Chat Chat](https://railway.com/deploy/-WWW5r) — Chat Chat, your own unified chat and search to AI platform. - [Weaviate](https://railway.com/deploy/weaviate-1) — Vector database with hybrid search and an API key-protected API - [Möbius v0.1 Personal AI OS](https://railway.com/deploy/mobius-v01-personal-ai-os) — Self-hosted AI agent that builds and runs apps for you, with memory. Open this page in a browser: https://railway.com/deploy/self-hosted-open-wearables