Repository Structure
Open Wearables follows a monorepo structure with clear separation between backend and frontend:Runtime Stack
Backend
Core Framework:- FastAPI (Python 3.14+) - Modern, fast web framework with automatic OpenAPI documentation
- SQLAlchemy 2.0 - ORM for database interactions
- Alembic - Database migration management
- Pydantic - Data validation and settings management
- PostgreSQL 18 - Primary relational database
- Redis 8 - Task queue broker and caching
- Celery - Distributed task queue for background jobs
- Celery Beat - Scheduled task execution
- Flower - Celery monitoring and administration
- python-jose - JWT token handling
- bcrypt - Password hashing
- cryptography - Encrypted provider settings storage
- Docker & Docker Compose - Containerization and orchestration
- Sentry - Error tracking and monitoring
Frontend
Core Framework:- SvelteKit 2 / Svelte 5 - Server-rendered routing, loaders and form actions
- Bun - Runtime and package manager
- Vite - Build tool and dev server
- Tailwind CSS 4 - Utility-first styling with design tokens
- Lucide - Icon library
- Charts are hand-drawn SVG; dialogs are native
<dialog>elements
- API tokens live in an
HttpOnlycookie that page scripts cannot read; only the frontend server calls the API
- Vitest - Unit tests, and component tests in a real browser
- Playwright - End-to-end tests against a production build
MCP Server (Beta)
Model Context Protocol Integration:- FastMCP - MCP server framework for AI assistant integration
- httpx - Async HTTP client for backend API communication
- Pydantic - Settings and data validation
- Natural language queries for health metrics (sleep, workouts, etc.)
- User discovery and data retrieval tools
- Unified data format regardless of wearable provider
Note: The MCP server is currently in beta and is actively being developed.
Architecture Patterns
Backend Architecture
The backend follows a layered architecture:- API Layer (
app/api/routes/) - HTTP endpoints and request handling - Service Layer (
app/services/) - Business logic and orchestration - Repository Layer (
app/repositories/) - Data access abstraction - Model Layer (
app/models/) - Database schema definitions
Data Flow
Background Processing
Long-running tasks (data synchronization, webhooks) are handled asynchronously:Deployment Architecture
The platform is designed for self-hosting with Docker. For production, use the published images (see Deploying with Docker); the repository’sdocker-compose.yml runs the same stack locally for development:
Services:
app- FastAPI application serverdb- PostgreSQL databaseredis- Redis cache and message brokercelery-worker- Background task processorcelery-beat- Scheduled task schedulerflower- Celery monitoring dashboardfrontend- SvelteKit developer portal, served by Bun
- Single-tenant architecture (one deployment = one organization)
- No external dependencies for core functionality
- All services can run locally with
docker compose up - Stateless application servers (horizontal scaling ready)
Development Workflow
Backend:- Hot-reload enabled via Docker Compose watch mode
- Database migrations via Alembic
- Code quality enforced with Ruff & ty
- Vite HMR (Hot Module Replacement) for instant updates
- TypeScript strict mode, checked by svelte-check
- ESLint and Prettier

