Hexclave: A User Infrastructure Platform Behind One Prompt

The problem Hexclave claims, and the shape of the product

Most products reach the same wall at roughly the same time. You need sign-in, then organisations or workspaces, then roles that gate features, then API keys for programmatic access, then a way to charge for all of it, then transactional email, then some view of what users actually do. Each of those is a separate vendor with a separate data model, and the joins between them are where the bugs live. Hexclave positions itself as the layer that owns all of it under one user model, with each capability shipped as a catalog app you switch on when your product needs it. The README frames the audience as teams that want to choose their own frontend, backend and database while something else handles the user-facing infrastructure. The scope is wide: authentication, teams, RBAC, API keys, payments, emails, analytics, webhooks, a data vault, and a launch checklist. That breadth is the pitch and also the thing to interrogate, because a platform that spans auth through billing has to get the joins right between all of them, and the README does not show those joins.

How the apps share state: one user model, many surfaces

The README's central architectural claim is that every app is built on the same user model. That is what makes the catalog more than a bundle. A workspace created in Teams is the same object that RBAC checks against, that Payments bills, and that API Keys can be scoped to. The README gives a few concrete behaviours that follow from this: the workspace switcher remembers the last selection, an invite to a new address triggers auto sign-up rather than a separate onboarding path, and a permission check runs the same way on server and client. Payments follow the same logic, billing a person or a whole team through one model instead of two code paths. Analytics is described as needing one flag enabled, with active user counts and session replays available without a separate data stack. The design intent is clear: fewer handoffs between systems that each keep their own copy of who a user is. What the repository material does not expose is the storage schema, the session format, or how a permission check resolves when a user belongs to several workspaces with different roles. Those are the details that determine whether the shared model holds up in a product with non-trivial tenancy.

Setup runs through an AI skill endpoint, not an install guide

The README does not contain a conventional getting-started section. Instead it offers a prompt to paste into a coding agent: read skill.hexclave.com and help me setup hexclave in this project. For agents, it documents a fetch call against the same host with question and context parameters, shown as a curl command with a placeholder question. That is the entire documented setup path in the material supplied. The practical consequence is that your first integration step is a network fetch whose output you have not reviewed, executed by a tool that will then edit your project. That is a real trust decision, and it is worth being explicit about it rather than treating the prompt as a convenience. The upside is that integration instructions can be updated server-side without a new release of the package. The downside is that the instructions you follow are not in the repository, are not versioned alongside the code you install, and cannot be diffed in a pull request. If your team needs a reproducible bootstrap that a human can read and approve, this design works against you, and you will want to capture whatever the skill endpoint returns into your own repository before running it.

Where the documentation thins out

Several claims in the README are stated as outcomes without a mechanism. API keys are said to be auto-revoked when leaked, with the full secret shown only once and plaintext never retained after creation. The one-time display and the no-plaintext rule are ordinary and credible. Auto-revocation on leak implies a detection path, and the README does not say what it is: a scanner over public sources, a pattern match on repository pushes, or something else. Data Vault is described as locked with your secret so the platform never sees plaintext, and as server-only by design, but the encryption scheme is not named. Webhooks are called signed and tamper-proof with retries and backoff handled for you, and verification is said to take five lines, yet no signature header, algorithm or retry schedule appears. Emails claim delivery tracking with opens and clicks. None of this is unusual for a README, and none of it is disproven, but a reader deciding whether to move authentication and billing onto this platform needs those specifics. The honest summary is that the repository describes a product surface, not an integration contract, and the integration contract lives behind the skill endpoint.

Licence: two identifiers on one badge

The repository metadata reports the licence as NOASSERTION, which means GitHub could not map the files it found to a single recognised identifier. The README badge reads MIT / AGPLv3. Those two facts together tell you the project is split-licensed and that the split is not resolvable from the repository listing. A common arrangement in this space is a permissive client SDK paired with a copyleft core, and the AGPLv3 half matters if you intend to modify the server and offer it as a service, because that licence carries a network-use clause. I am not giving legal advice and cannot confirm from the supplied material which directories fall under which licence. What I can say is that the discrepancy between the NOASSERTION metadata and the badge is the first thing to resolve before you build on this, and the answer is in the repository's licence files, not in the badge.

Maintenance cost and release cadence

The release list shows dashboard builds moving quickly: versions 1.0.116, 1.0.118 and 1.0.119 within four days in September 2026, with the last push to the dev branch on the same day as the newest dashboard tag. The default branch is dev, not main or master, which suggests development happens on that branch and releases are cut from it. Two things follow. First, a fast-moving dashboard means the surface you configure in the browser can change under you, and any screenshots or written procedures your team keeps will drift. Second, the versioned artifacts in the release list are dashboard builds, not SDK or server packages, so the material does not tell you how the parts you import into your application are versioned or how breaking changes are communicated. For a platform holding authentication and payment state, the upgrade question is not how often it ships but what guarantees accompany a version bump, and that is not answerable from what is here. Budget for reading release notes rather than assuming semantic versioning discipline.

How it differs from Supabase and Clerk

The topics list names supabase, clerk and auth0, so the comparison is fair game. Supabase gives you a Postgres database first and layers auth, storage and edge functions on top; you own the schema and write the policies, and the platform's value is the database you get. Clerk is narrower and deeper on authentication: prebuilt components, session management and organisation support, with billing and analytics handled elsewhere. Hexclave's stated difference is the opposite of both. It does not give you a database, and it does not stop at authentication. It assumes you already have a frontend, backend and database and offers to own the user-shaped layer across all of them, including payments and email, which Supabase and Clerk largely leave to other vendors. That is a bigger bet on one vendor. The trade is fewer integration seams for more concentration: if the shared user model is right, you avoid stitching four systems together, and if it is wrong for your domain, you have moved billing and identity onto a platform whose internals the README does not describe.

Who should adopt it, and what to check first

The fit is a small team building a multi-tenant product that expects to charge for it, wants passkeys and OAuth without writing the flows, and is comfortable letting a coding agent perform the initial integration. The catalog model suits products that will add teams, roles and metering over time, since those apps are switched on rather than migrated to. The misfit is anyone who needs a published API reference before writing code, a pinned and reviewable install procedure, or a single unambiguous licence. It is also a poor fit if your users are not the unit of tenancy, since the entire design rests on that model. Before adopting, fetch the skill endpoint with your actual stack as context and read what comes back, because that response is the real documentation. Confirm from the licence files which parts are MIT and which are AGPLv3. Then check whether self-hosting requires a licence key issued from the hosted dashboard, since the README advertises both cloud and self-hosted deployment without describing the self-hosted path.

Editorial conclusion

Adopt Hexclave if you want auth, teams, RBAC, API keys, payments and email behind one user model and you are willing to let an AI agent drive the initial wiring. Skip it if you need published SDK reference material, a conventional install guide, or a licence you can read off a badge. Before committing, fetch the skill endpoint for your stack, confirm the split between the MIT and AGPLv3 parts, and verify whether the self-hosted path needs a licence key from the hosted dashboard.

Official sources

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