Independent review
Assessment — Hexclave has expanded beyond a narrow authentication server. The reviewed materials cover passkeys, OAuth, passwords, magic links, users and teams, nested roles, API keys, payments, usage, credits, transactional email, webhooks, analytics, session replay, and encrypted user-supplied secrets. That breadth can simplify an application architecture, but it also concentrates identity, authorization, billing, communications, and sensitive data in one operational plane.
The hosted developer path is more approachable than the full platform suggests. Framework SDKs and a local CLI/dashboard support common JavaScript and server environments, with client/server objects and application providers. Self-hosting is advanced. The bundled server combines backend and dashboard, while the development dependencies represent PostgreSQL, ClickHouse, webhook delivery, email testing, object storage, queues, telemetry, Stripe simulation, and other services. Operators need to choose and secure production equivalents rather than copy the development topology blindly.
Setup difficulty — moderate for hosted SDK integration and advanced for complete self-hosting. Identity infrastructure needs disciplined key rotation, cookie and redirect review, email-delivery controls, backup restoration, webhook replay handling, authorization tests, and staged upgrades. Hexclave's own self-host guidance puts reliability, security, and updates on the operator. The large feature surface means an outage or configuration mistake can affect several application capabilities simultaneously.
The best fit is a team that actively wants one extensible layer for most user-facing infrastructure and accepts that platform as a core dependency. Teams needing only simple authentication, a permissively licensed server, or a minimal data footprint should compare narrower products. Clerk, Auth0, and WorkOS overlap as managed alternatives, but Hexclave's all-in-one module set is not an exact one-for-one match.
GitHub reports the dev branch active, enabled, and not archived. The current root license is intentionally mixed: client and example areas are generally described as MIT, server components generally as AGPLv3, and enterprise licensing is offered; GitHub therefore reports NOASSERTION rather than one repository-wide SPDX license. The former Stack Auth name remains in configuration aliases and some checked-in guidance, so verify current variable names and documentation. The latest reviewed commit fixed date mutation and asynchronous billing/test behavior, reinforcing the need to test eventual-consistency and payment paths.
Practical fit
Best for teams seeking a broad user-infrastructure layer and able to secure and operate a high-impact dependency; narrower auth needs may be better served by a smaller component.
Useful for
Authentication, sessions, passkeys, OAuth, and magic-link flows Team membership, invitations, roles, permissions, and scoped API keys Integrated payments, email, webhooks, analytics, and encrypted user secrets
Dependencies
Node.js 22.13+ and pnpm monorepo tooling PostgreSQL for the bundled server ClickHouse and supporting webhook, email, storage, queue, and telemetry systems for represented features
External services
SMTP delivery and S3-compatible storage for represented self-hosted features Svix-style webhooks and optional payment/analytics integrations
Deployment notes
Pin the reviewed commit, replace every example secret, map legacy STACK_* and current HEXCLAVE_* variables deliberately, run migrations as a controlled step, and test auth, entitlement, webhook, email, backup, and recovery paths before routing production users.
Limitations
The broad security-critical scope increases outage and misconfiguration impact. Server and client areas have different license declarations rather than one repository-wide SPDX license. The Stack Auth to Hexclave rebrand leaves legacy names in configuration and documentation. Complete self-hosting requires several stateful and asynchronous dependencies.
Project media
