Deploy and Host Open Wearables on Railway

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

On the backend service, set ADMIN_EMAIL and a strong ADMIN_PASSWORD.
Click Deploy on Railway. The first build of the five app services takes several minutes.
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.
Open the frontend domain, sign in, and create an API key.
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: source code, SDKs and docs
Open Wearables website: overview and guides
Railway Private Networking: how services connect
Railway 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.