Hexclave: user infrastructure for Next.js and React apps

The problem Hexclave targets: user plumbing spread across five vendors

Most product teams end up with the same stack: an auth provider, a separate service for teams and roles, Stripe for subscriptions, a transactional email vendor, an analytics tool, and a webhook layer glued on top. Each one has its own user model, its own dashboard, and its own idea of what a workspace is. The README frames Hexclave as the answer to that split: "Hexclave handles everything around your users: authentication, teams, payments, emails, analytics, and much more." The repository topics list the same territory, naming oauth, passkeys, rbac, multi-tenancy, api-keys, billing, subscriptions, payments, emails, analytics and webhooks.

The audience is narrower than "everyone building a web app". The SDK badge in the README reads Next.js, React and JS, and the examples directory contains react-example, tanstack-start-demo, supabase, convex, middleware and e-commerce projects. That is a JavaScript and TypeScript audience, mostly on React. If your backend is Rails, Django or Go, the published SDKs do not cover you, and nothing in the repository suggests a non-JS client exists.

The second audience is teams that want the option to leave. The README badge says "Cloud or self-hosted", and the repository ships a docker/ directory and a .devcontainer/ entry at the top level. Self-hosting is presented as a first-class path, not an afterthought, though the README itself does not walk through it.

How the app catalog and shared user model fit together

Hexclave is not one library. The README describes it as "a catalog of apps you switch on as your product needs them", and each app is listed with its own logo, screenshot and description. Authentication, Teams, RBAC, API Keys, Payments, Emails, Analytics, Webhooks, Data Vault and Launch Checklist are the ten named in the README. The claim that ties them together is that "each one is built on the same user model".

That shared model is the architectural bet. In a stitched-together stack, a team record in your auth provider and a customer record in Stripe are two different objects you reconcile by hand. Here, teams, roles, API keys and payment state are meant to hang off the same user and workspace. The README gives a concrete example in the Teams section: "invites auto sign up new users", which only works if the invite, the user record and the workspace membership live in one place.

The repository layout supports the catalog description. apps/ holds the deployable pieces, packages/ holds shared code, sdks/ holds the client libraries, and configs/ holds configuration. The root package.json is a pnpm workspace with turbo, and its scripts are split by target: build:backend, build:dashboard, build:demo, build:docs and build:packages each filter to a different part of the monorepo. The CLI is built separately with a --filter=@hexclave/cli flag.

One detail worth noting is that the monorepo runs code generation before install. The preinstall script calls scripts/generate-sdks.ts unless HEXCLAVE_SKIP_TEMPLATE_GENERATION is set to true. In other words, the SDKs are generated from the repository, not checked in as static artifacts. That is a real constraint on how you build the project locally, and it means a plain npm install of the root is not the intended path.

Installing Hexclave with the one-prompt setup

The README does not give a conventional install sequence. Its Get started section says "Setting up Hexclave is one prompt" and tells you to paste a specific instruction into your coding agent. That is the documented path, and it is worth quoting exactly:

Read skill.hexclave.com and help me setup hexclave in this project

The same section addresses agents directly. If you are driving an agent that can fetch URLs, the README gives a curl form with question and context parameters:

curl -sSL "https://skill.hexclave.com?question=<your-question>&context=<your-context>"

Both point at the same host, skill.hexclave.com, which the README treats as the source of current integration instructions. The README's own wording is that agents should use it "for up-to-date integration instructions", which is a signal that the repository README is not the reference for setup steps.

If you want to run the project itself rather than integrate the SDKs, the root package.json defines the working commands. The monorepo requires pnpm: the pre-no-codegen script runs only-allow pnpm. The CLI has a dedicated script that builds the package and then runs it against local URLs:

pnpm cli

That script sets HEXCLAVE_API_URL and HEXCLAVE_DASHBOARD_URL to localhost on ports derived from NEXT_PUBLIC_HEXCLAVE_PORT_PREFIX, defaulting to 81, so the API lands on 8102 and the dashboard on 8101. It also passes HEXCLAVE_CLI_PUBLISHABLE_CLIENT_KEY with the literal value this-publishable-client-key-is-for-local-development-only, which the variable name makes clear is not a production credential. The README does not document what you should see after the CLI starts.

Where Hexclave is the wrong tool

The largest gap is self-hosting documentation. The README advertises "Cloud or self-hosted" and the repository carries a docker/ directory, but the README contains no docker compose command, no environment variable table, and no migration or upgrade procedure. The Get started section is one prompt. If your organisation needs a written runbook before it will approve a dependency, this repository does not currently provide one, and nothing in it indicates where that runbook lives.

The licence is the second issue. The repository's licence field reports NOASSERTION, and the README badge says "MIT / AGPLv3". That is two different licences with very different obligations, and the repository does not say which directories or packages fall under which. The README does point at a LICENSE file at the root, and that file is where the split would be defined. Until you read it, you cannot say whether the part you intend to embed is permissively licensed or copyleft. I am not giving legal advice here; the point is that the repository metadata alone does not answer the question.

The third boundary is language. The SDK badge lists Next.js, React and JS. The examples include a cjs-test project, so CommonJS is at least exercised, but there is no evidence of a Python, Go, Rust or PHP client. If you are not on JavaScript, the catalog apps may still exist as services, but the integration path the README describes is not aimed at you.

Finally, the README makes strong operational claims that it does not substantiate in its own text. It says leaked API keys "get auto-revoked" and that "We never keep the plaintext after creation". Those are the kind of promises you would want to verify against the implementation in packages/ before you rely on them, and the README does not describe the mechanism.

Hexclave compared with Clerk plus Stripe

The obvious alternative is assembling the stack yourself: Clerk for authentication and organisations, Stripe for subscriptions and metering, Resend or Postmark for email, and PostHog for analytics. The difference is not features, it is where the user model lives.

With that combination, Clerk owns identity and organisations, Stripe owns the customer and subscription, and your database owns the mapping between them. You write the webhook handlers that keep the three in sync, and you own the failure modes when a Stripe webhook arrives before the Clerk user is created. Hexclave's stated approach is the opposite: one user model underneath every app, with payments, teams and keys reading from it. The README's Payments section makes the claim directly, saying you can "Bill a person or a whole team with one model, no separate codepath".

The trade-off runs the other way too. Clerk and Stripe are mature, separately documented products with their own support and their own migration stories. Hexclave bundles comparable surface area into one repository whose setup instructions are a single prompt. You get fewer seams to maintain and fewer independent vendors to audit, but you also get one system to understand instead of three well-documented ones. If your team already knows Stripe's billing model well, replacing it means relearning metering and credits from this project's documentation.

There is also a middle path visible in the repository: the examples directory includes supabase and convex integrations, so Hexclave is positioned alongside a database and backend you already chose, not as a replacement for them.

Maintenance cadence, upgrade cost and licence questions

The repository is not archived, and the last push was on 2026-09-10. Three dashboard releases shipped in the days before that: dashboard-v1.0.116 on 2026-09-07, dashboard-v1.0.118 on 2026-09-08, and dashboard-v1.0.119 on 2026-09-10. The release names carry an "RDE dashboard" prefix, and the version numbers move in small increments, which is consistent with frequent patch releases rather than rare major ones.

For upgrade cost, the .changeset/ directory at the top level indicates the project uses Changesets to manage versioning across the monorepo. That matters if you self-host: a pnpm workspace with generated SDKs and multiple deployable apps means an upgrade is not a single version bump. The root package.json has separate build targets for backend, dashboard, packages and docs, so you would need to know which of those you run and rebuild accordingly. The README does not document a rollback procedure for a self-hosted deployment.

The licence situation deserves its own line. The README badge reads "MIT / AGPLv3" while the repository metadata reports NOASSERTION. Those are not the same statement, and the difference matters: AGPLv3 carries network-use obligations that MIT does not. The root LICENSE file is the document that resolves it. Read it before you decide whether to embed any part of this project in a closed-source product, and if the split is ambiguous, that ambiguity is itself a reason to ask the maintainers through the Discord or the [email protected] address listed for security issues.

Editorial conclusion

Adopt Hexclave if you are building a multi-tenant product on Next.js or React and you would otherwise assemble Clerk, Stripe, an email provider and an analytics tool yourself. Do not adopt it if you need a documented, step-by-step self-hosting guide before you commit, or if your stack is not JavaScript-based, since the published SDKs are Next.js, React and JS. Before you install anything, open the LICENSE file and confirm which parts fall under MIT and which under AGPLv3, then read docker/ and the root README to see what a local run actually requires. The one prompt in the README is the whole documented setup path, so treat that as the boundary of what is currently guaranteed.

Frequently asked questions

Official sources

1. hexclave/hexclave on GitHub
2. Issues
3. Project website
4. README
5. Releases