ADR-0006: Use Clerk for WatchTower Authentication
Status
Approved
Date
2026-05-30
Context
WatchTower requires user authentication to support:
- protected dashboard access
- user-specific telemetry views
- secure project ownership
- team/member-based access control
- future role-based permissions
Building authentication from scratch would require implementing:
- secure password storage
- session management
- login and signup flows
- password reset flows
- OAuth support
- token validation
- account security protections
This would add security risk and development overhead that is outside the core scope of WatchTower.
Decision
Use Clerk as the authentication provider for WatchTower.
Clerk will handle:
- user signup and login
- session management
- authentication UI components
- OAuth/social login support
- user identity management
- frontend/backend authentication integration
Rationale
- Clerk provides managed authentication with minimal setup
- Reduces security risk compared to custom authentication
- Speeds up development by providing prebuilt auth flows and UI components
- Integrates well with modern JavaScript and Node.js applications
- Supports protected frontend routes and backend request validation
- Allows WatchTower to focus on observability features instead of authentication infrastructure
- Provides a path for future user/team management and role-based access control
Alternatives Considered
Custom Authentication
Rejected because it would require implementing and maintaining sensitive security functionality, including password hashing, session handling, password resets, and account protection.
Auth0
Rejected because it adds more configuration and platform complexity than needed for the current WatchTower scope.
Firebase Authentication
Rejected because it would couple authentication more closely with the Firebase ecosystem, while WatchTower is currently built around a Node.js and SQLite architecture.
Consequences
Positive
- Faster authentication implementation
- Reduced security burden
- Built-in login, signup, and session management
- Easier route protection
- Supports future team and organization features
- Allows the team to focus on WatchTower telemetry and dashboard functionality
Negative
- Adds dependency on an external authentication provider
- Introduces vendor lock-in risk
- Authentication behavior depends on Clerk service availability
- Some customization may be limited by Clerk’s platform features
- Pricing or plan limits may matter if WatchTower scales
Conclusion
Clerk was selected because it provides a secure, developer-friendly authentication layer that aligns with WatchTower’s lightweight MVP goals while supporting future expansion into protected dashboards, user-owned projects, and team-based access control.