Deploy and Host Open Wearables on Railway

Open Wearables is an open-source platform that unifies wearable and fitness data behind one normalized API. Instead of building separate OAuth integrations for Garmin, Whoop, Oura, Fitbit, Polar, Suunto, Strava, and more, you connect once and get consistent, deduplicated health data from every provider. It ships open health-scoring algorithms and an MCP server for AI reasoning over the data — and because it's self-hosted, every user's health data stays on infrastructure you control. This template gets it running on Railway.

What This Template Deploys

Service	Purpose
Open Wearables	The unified API, developer portal, OAuth handlers, and health-scoring engine
PostgreSQL	Normalized health data, user connections, and provider tokens

Both run on Railway's private network. Open Wearables normalizes each provider's data into one consistent schema, so your application code never needs provider-specific logic. A persistent database holds the synced data.

About Hosting

Open Wearables solves a specific, painful problem — every wearable provider has its own API, OAuth flow, and data format — and self-hosting it has a few things worth understanding.

One API instead of a dozen integrations. The platform handles OAuth, syncing, and normalization for cloud providers (Garmin, Oura, Whoop, Suunto, Polar, Ultrahuman, Strava, Fitbit) and SDK-based sources (Apple HealthKit, Samsung Health, Google Health Connect). Data arrives deduplicated with consistent timestamps in a single schema, so an app reads HRV or sleep the same way regardless of device. That normalization is the core value — the months of integration work you skip.

You bring each provider's developer credentials. The template deploys the platform, but connecting a provider means registering a developer app with that provider and adding its client ID and secret. Each connects via OAuth 2.0 or an SDK — the one setup step per device; the platform handles everything after.

Single-organization by design — no multi-tenancy. Each deployment serves one organization, which keeps it simple and is right for a self-hosted instance: your data, your infrastructure, full control over access and retention. That single-tenant model is also why it's HIPAA-eligible when you add the appropriate controls.

It's early-stage — pin your version. Open Wearables is under active development and pre-1.0, so APIs may change between releases. Pin a specific version rather than tracking latest, and follow the changelog before upgrading.

The included MCP server lets an LLM reason over the unified health data, enabling AI health assistants and natural-language health automations on top of the platform.

Typical cost: ~$10–15/month on Railway for the platform and database. Open Wearables is MIT-licensed with no per-user fees at any scale — where commercial wearable-API vendors bill per connected user.

How It Compares

	Open Wearables (self-hosted)	Terra / Vital (SaaS)	Building it yourself	Per-provider APIs
Cost model	Flat infra	Per connected user	Engineering time	Free but complex
Data ownership	Full — your infra	Vendor	Full	Full
Providers	10+ unified	Many	One at a time	One each
Normalized schema	Yes	Yes	You build it	No
Health scoring	Open algorithms	Proprietary	You build it	No
Self-hostable	Yes	No	Yes	N/A

Commercial aggregators like Terra and Vital are polished but bill per connected user and keep data on their servers. Building integrations yourself means months of per-provider OAuth and normalization work. Open Wearables gives you the same unified, normalized API — plus open health-scoring algorithms and an MCP server — self-hosted, with your users' health data on infrastructure you own and no per-user fees.

Deploy in Under 5 Minutes

Click Deploy on Railway — Open Wearables and PostgreSQL build automatically (~3 minutes)
Confirm the database is wired and the app is healthy
Set your instance's base URL and any required secrets
Register a developer app with a provider (e.g. Garmin or Oura) and add its OAuth credentials
Connect a device through the portal and make your first call to the unified API

Add more providers the same way — each needs its own developer credentials, then normalizes automatically.

Common Use Cases

Health & fitness apps — read normalized sleep, recovery, HRV, and activity from any device through one API
Adaptive coaching — adjust training or recommendations based on real recovery state across mixed device fleets
Remote patient monitoring — aggregate wearable data on HIPAA-eligible, self-hosted infrastructure for clinical use
AI health assistants — use the MCP server to let an LLM reason over unified health data in natural language
Personal quantified self — individuals self-host to own their wearable data instead of leaving it with each vendor

Configuration

Variable	Required	Description
`DATABASE_URL`	Auto-injected	PostgreSQL connection via Railway reference variable
`BASE_URL`	Required	Your Railway public domain — OAuth callbacks build from it
`SECRET_KEY`	Required	Signs sessions and encrypts stored provider tokens — keep stable
`GARMIN_CLIENT_ID` / `GARMIN_CLIENT_SECRET`	Per provider	Developer credentials for each provider — one pair per provider
`WHOOP_CLIENT_ID` / `WHOOP_CLIENT_SECRET`	Per provider	Add only the providers you want to support

Each provider needs its own developer credentials. Connecting Garmin, Whoop, Oura, and others means registering a developer app with each and adding its OAuth client ID and secret. The template deploys the platform; you supply the per-provider keys as you enable devices. BASE_URL must match your domain, and keep SECRET_KEY stable. OAuth callbacks are built from BASE_URL, so it must be your real Railway domain. SECRET_KEY encrypts stored provider tokens — changing it can invalidate existing connections.

Dependencies for Open Wearables Hosting

Railway account — ~$10–15/month for the platform and database
PostgreSQL (included in the template)
Developer/API credentials for each wearable provider you want to connect
Optional: an LLM for the MCP server's AI health reasoning features

Deployment Dependencies

Implementation Details

The template runs Open Wearables against a Railway PostgreSQL service over the private network. The platform exposes a unified REST API and a developer portal, handling per-provider OAuth 2.0 flows and (for Apple Health, Samsung, and Google Health Connect) SDK-based ingestion, then normalizing every provider's data into one schema with deduplication and aligned timestamps. Recent versions add webhook streaming for near-real-time sync.

Provider connections require developer credentials registered with each provider and supplied as environment variables or through the portal; BASE_URL must match the deployment's domain so OAuth callbacks resolve, and SECRET_KEY signs sessions and encrypts stored tokens. On top of the normalized data layer, open scoring algorithms compute standardized sleep, recovery, strain, stress, HRV, and VO2 max metrics, and an included MCP server exposes the data to LLMs. Because the project is pre-1.0, pin a specific version and review the changelog before upgrades. Each deployment is single-tenant, serving one organization with full control over data and retention.

Frequently Asked Questions

What does Open Wearables actually do? It connects to wearable providers (Garmin, Whoop, Oura, Fitbit, and more), handles their OAuth and syncing, and normalizes everything into one API and schema — so your app reads health data the same way regardless of device, instead of you building each integration.

Do I need credentials from each provider? Yes. Each provider requires you to register a developer app and add its OAuth client ID and secret. The template runs the platform; you supply per-provider credentials for the devices you want to support.

Is it HIPAA-compliant? It's HIPAA-eligible because it's self-hosted — health data stays on your infrastructure, and you control access, encryption, retention, and audit logging. Production HIPAA deployments still require you to configure those controls appropriately.

Is my data private? Fully — it's self-hosted and single-tenant, so all wearable data stays on your Railway deployment with no third-party aggregator in the path.

Is it production-ready? It's actively developed but pre-1.0, so pin a version and follow the changelog. The core unification and scoring are usable now; test your providers before relying on it.

Why Deploy 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 a unified wearable-data API in one click — the platform and PostgreSQL wired over private networking, with automatic HTTPS for OAuth callbacks. Connect Garmin, Whoop, Oura, Fitbit, and more through one normalized API, with open health scores and an MCP server for AI, and every user's health data on infrastructure you own.