Deploy and Host Open Wearables on Railway

Open Wearables is an open-source unified API for wearable health data. It pulls activity, sleep, heart rate and body metrics from Fitbit, Garmin, Oura, Polar, Strava, Suunto, Withings and Google Health Connect, normalises them into one schema, and serves them over a documented REST API with webhooks, API keys and a web dashboard. This template runs it as six services: the API, a Celery worker, a Celery beat scheduler, the dashboard, PostgreSQL on a volume and Redis on a volume.

About Hosting Open Wearables

Open Wearables is a FastAPI application with a Celery pipeline behind it, and its own deployment scripts assume a machine you configure by hand. On Railway three things go wrong without help, and this template fixes all three.

The admin account is sealed at deploy time. Upstream's seeding script creates the first developer from admin_email / admin_password in app/config.py, whose defaults are admin@admin.com and a password published in the upstream repository. A template that leaves those variables blank ships every deploy with the same publicly known login on a public URL. This image refuses to start unless an admin email and password are given, rejects the upstream default password outright, seeds the account before the container's port is opened, and re-applies the password on every boot — so a redeploy is a working password reset, which the product otherwise has no path for.

The dashboard is a Vite build, so its API URL is baked in at build time. Setting an environment variable on the container cannot move it. This template builds the dashboard against a placeholder, restores a pristine copy of the built tree on every boot, rewrites the placeholder to this deployment's own API domain, and exits with an error if any placeholder survives — so the dashboard can never come up silently pointing somewhere else.

Every service agrees on one secret key and one CORS origin. SECRET_KEY derives the Svix webhook JWT and the provider webhook secrets, so the API, the worker and the scheduler must share it exactly. CORS_ORIGINS is parsed as a JSON list by pydantic settings, and a value the app cannot parse is a crash at import time, before anything listens.

Images: ghcr.io/bon5co/open-wearables-railway and ghcr.io/bon5co/open-wearables-railway-frontend, both built from upstream 0.7.0 and pinned. Source: bon5co/open-wearables-railway.

Why Deploy Open Wearables on Railway

Wearable data is a long-running ingestion workload: OAuth token refreshes, scheduled pulls, webhook deliveries and backfills that run whether or not anyone has the dashboard open. Railway gives you the private networking, the two volumes and the always-on worker processes that shape needs from a single deploy, with no VM to patch and no queue broker to install. The API and the dashboard each get an HTTPS domain, and PostgreSQL and Redis stay private to the project.

Common Use Cases

Give a health, fitness or research app one API instead of eight vendor integrations.
Collect study participants' wearable data with consent, on infrastructure you control.
Backfill and normalise sleep and activity history for analysis or model training.
Receive provider webhooks and fan them out to your own systems.

Dependencies for Open Wearables Hosting

PostgreSQL and Redis, both included in this template and both on their own volumes. Provider credentials (Fitbit, Garmin, Oura, Strava, Suunto, Withings, Polar, Google) are added from the dashboard after deploy; none of them is required to boot.

Deployment Dependencies

Upstream project: the-momentum/open-wearables
Wrapper images and build: bon5co/open-wearables-railway
Developer accounts with the wearable vendors whose data you intend to pull.