Stack Auth is now Hexclave, and what to do about it

Stack Auth is now Hexclave, and what to do about it

The Stack Auth name stopped applying at the end of May 2026. The stack-auth/stack-auth repository now redirects to hexclave/hexclave, the stack-auth.com domain redirects to www.hexclave.com, and the @stackframe/* packages were replaced by the @hexclave/* family. The service and the data stayed the same; the branding changed, and so did the declared scope of the product.

Evidence for the rename

Rather than trusting what a search engine remembers, you can check the redirects yourself. Three commands are enough to see where the old addresses lead.

# repository: the old address ends up on the hexclave account
curl -sL -o /dev/null -w "%{http_code} %{url_effective}\n" https://github.com/stack-auth/stack-auth

# product site
curl -sL -o /dev/null -w "%{http_code} %{url_effective}\n" https://stack-auth.com

# documentation
curl -sL https://docs.stack-auth.com | grep -i "<title>"

The first two return 200 with the target addresses https://github.com/hexclave/hexclave and https://www.hexclave.com/. The third returns a page titled Redirecting to Hexclave Docs. The repository redirect also works for the intermediate variant: github.com/hexclave/stack-auth lands in the same place, meaning the organisation account was renamed together with the repository.

The date can be narrowed down from the npm registry, where publication dates are hard facts. The last release of @stackframe/stack is 2.8.108 from 26 May 2026. The first version of the @hexclave/js package appeared on 27 May 2026. An unscoped placeholder package named hexclave was published even earlier, on 23 May 2026, which looks like a name reservation a few days before the operation itself. One package from the old family shipped after the deadline: @stackframe/stack-shared sits at 2.8.109 from 28 May 2026, two days later than the rest.

I found no official announcement. The blog on hexclave.com has six posts and none of them covers the rename. The oldest one, at /blog/introducing-stack, is titled today "Introducing Hexclave, the open-source user management service" and dated 14 April 2024, and the page body contains neither the string "Stack Auth" nor "stackframe". Old content was rewritten to the new brand without a note, although the post address still gives away the original name. The changelog page does not render its entries without JavaScript, so I cannot confirm whether a rebranding note lives there. The only place that names the thing directly is docs.hexclave.com/migration, which opens with the sentence that Stack Auth is now Hexclave.

Did only the branding change

The old description of the @stackframe/stack package, still visible in the npm registry, talks about a managed authentication service. The new repository presents itself as "The user infrastructure platform" and lists a catalogue of apps you switch on as needed.

The README list covers authentication, teams, role-based access control, API keys, payments, emails, a vault for sensitive user data, webhooks and a pre-production launch checklist. The documentation aimed at agents adds fraud protection, a Vercel integration, analytics, clickmaps and session replays. The scope genuinely widened and this is not just marketing, and the dependency tree shows it. The framework packages, @hexclave/react and @hexclave/next, pull in rrweb for session recording, @stripe/stripe-js together with @stripe/react-stripe-js for payments, and ai version 6 together with @ai-sdk/react. The last @stackframe/stack release already carried the same dependencies, so the product expansion started before the rename. The framework-agnostic core, @hexclave/js, is noticeably leaner: of that set it carries only rrweb, and thirteen production dependencies in total.

The practical consequence is that installing the React or Next.js package just to add sign-in also drags a Stripe client and a session recording library into your dependency tree, whether or not you plan to use them. If you watch bundle size or the list of sub-processors handling your data, that is a real cost rather than a detail, and it is worth checking whether the @hexclave/js core alone will do.

The analytics backend runs on ClickHouse, which is visible from the queryAnalytics method that accepts raw SQL. Handy while debugging, and at the same time it ties you to a specific engine if you self-host.

Licence checked against three sources

This is where it gets interesting, because three sources say three different things and none of them is complete.

The first source, the LICENSE file in the repository root, is not a licence. It is five lines stating that the project is licensed per package, client code and examples under MIT, server components under AGPLv3, with commercial licences available on request by email. The text still opens with the word "Stack", even though the contact address was changed to the hexclave domain. The actual licences sit deeper: apps/backend/LICENSE and apps/dashboard/LICENSE contain the full AGPLv3 text, and packages/template/LICENSE contains the full MIT text with a "Copyright 2024 Stackframe" notice.

The second source, the license field in the npm registry, simply does not exist. It is missing from @stackframe/stack 2.8.108, from @stackframe/js, from @hexclave/js 1.0.102, from @hexclave/next, from @hexclave/react and from @hexclave/tanstack-start. A missing field across six packages in a row is not an accident but a long-standing state. The packages/js/package.json file in the repository confirms it, since it has no license key either. The exception is @hexclave/cli, which declares MIT.

The third source, the contents of the published package, comes out best. The @hexclave/js 1.0.102 tarball contains package/LICENSE with the full MIT text, 1058 bytes, carrying the "Copyright 2024 Stackframe" notice. The very same file, byte for byte, sits in @stackframe/stack 2.8.108. The file does not exist on the main branch under packages/js/LICENSE, even though the files array in the manifest lists it, so it is added during the build, most likely from the template package. That last part is my inference, not a vendor statement.

A separate oddity: @hexclave/cli declares MIT in its manifest, but the LICENSE file inside its package contains not a licence but the same five-line text pointing at per-package licences. The declaration and the attachment say different things.

Several things follow for a dependency audit. Tools that read only the registry license field will report Hexclave packages as unknown, and some corporate policies will block that. Tools that scan files inside node_modules will find MIT and let it through. The repository as a whole puts AGPLv3 on the server parts, so self-hosting pulls you into AGPL, with a commercial licence as the way out. The copyright notice still names the old company, which you will need to be able to explain during a formal legal review.

Migrating from @stackframe to @hexclave

The migration guide exists and it is specific. The package mapping looks like this.

Note the trap in the first row: the package called stack maps to the package called next, not to js. Renaming by naive text substitution introduces a bug.

npm uninstall @stackframe/stack
npm install @hexclave/next

The public API stayed the same; only the Stack prefix was renamed to Hexclave.

// before
import { StackClientApp, StackProvider, useStackApp } from "@stackframe/stack";

// after
import { HexclaveClientApp, HexclaveProvider, useHexclaveApp } from "@hexclave/next";

The old names still work as aliases. You can see it in the type declarations of the published package: @hexclave/js exports HexclaveServerApp and StackServerApp side by side, HexclaveClientApp and StackClientApp, defineHexclaveConfig and defineStackConfig. Symmetrically, the last @stackframe/stack release already exports HexclaveServerApp, meaning the new names landed in the old package before the domains were redirected.

The constructor takes the same options as before.

import { HexclaveServerApp } from "@hexclave/next";

export const hexclaveServerApp = new HexclaveServerApp({
  tokenStore: null,
  urls: {
    default: {
      type: "hosted",
    },
  },
});

The tokenStore value is "nextjs-cookie" for Next.js, "cookie" for other browser frontends and null for purely server-side environments. For urls.default.type the documentation now recommends "hosted" over the older "handler", and the hosted variant no longer generates paths such as /handler/sign-in.

Two changes are needed outside the imports. The hardcoded address https://api.stack-auth.com becomes https://api.hexclave.com. If you verify JWTs yourself, you fix the expected issuer, because the new SDK signs under the new domain.

const { payload } = await jose.jwtVerify(token, jwks, {
  issuer: 'https://api.hexclave.com/api/v1/projects/YOUR_PROJECT_ID',
  audience: 'YOUR_PROJECT_ID',
});

The same applies to the issuer variants for anonymous and restricted users, that is the /api/v1/projects-anonymous-users/ and /api/v1/projects-restricted-users/ paths. The rest is optional: X-Stack-* headers can be renamed to X-Hexclave-*, STACK_* environment variables to HEXCLAVE_*, and tokens with the stackauth_ prefix stay valid. OAuth callback URLs pointing at the old domain keep working, though a provider recreated from scratch in the dashboard will get an address on the hexclave domain.

One thing does not migrate painlessly. Hosted pages moved from the .built-with-stack-auth.com subdomain to .built-with-hexclave.com, and passkeys are bound to the domain where they were registered and do not carry over between the two. If you have users with passkeys on the old domain, plan for re-registration.

The command line tool changed its binary name. The old stack program is no longer published and its place is taken by hexclave from the @hexclave/cli package.

{
  "scripts": {
    "dev": "hexclave dev --config-file ./hexclave.config.ts -- npm run dev:inner",
    "dev:inner": "next dev"
  }
}

The hexclave dev command injects HEXCLAVE_PROJECT_ID and HEXCLAVE_SECRET_SERVER_KEY into the child process, including NEXT_PUBLIC_ and VITE_ prefixed copies for the non-sensitive values.

What happens to the old packages

The migration documentation says outright that staying on the old SDK requires no action, because api.stack-auth.com and api.hexclave.com point at the same service. That answers the question of whether your project stops working on Monday. It does not.

What the documentation does not say is whether the old packages will get any releases at all. Registry facts suggest not: @stackframe/stack has been at 2.8.108 since 26 May 2026, close to three months, while the @hexclave/* family shipped further versions up to 1.0.102 on 20 August. I found no end-of-support statement, but I also found no promise of security fixes for the old packages. For an authentication library that is reason enough to schedule the migration, even if nothing is on fire today.

This is not a dummy project abandoned after two releases. @stackframe/stack has 225 published versions going back to March 2024, and @hexclave/js reached 98 in under three months. The hexclave/hexclave repository has 6842 stars and 522 forks, is not archived, and releases show up in the atom feed every few days. The name was abandoned, the code was not.

The bare hexclave npm package is a separate matter. Version 0.0.1 from 23 May 2026, MIT licence, three files, 660 bytes unpacked. Its entire content is a script that prints a message and exits with an error code. Worse, the message and the README contradict each other: the package description and README point at @hexclave/hexclave, which does not exist in the npm registry, while the binary script points at @hexclave/cli, which does exist and is the real tool. It is a name-reserving placeholder with stale instructions inside. Do not install it and do not treat it as an entry point.

Two more things to check in your lockfile while you are there. Family packages are pinned to a single version: @hexclave/next 1.0.102 requires exactly @hexclave/ui 1.0.102, @hexclave/sc 1.0.102 and @hexclave/shared 1.0.102, so mixing versions will not resolve. The peer dependency range for React was lowered along the way: @stackframe/stack required react at 18.3.0 or above, while @hexclave/next accepts >=18.0.0. The Next.js range is unchanged, that is >=14.1 with release candidates of version 15 allowed.

Pricing under the new name

Pricing is published and renders without JavaScript, so the figures below come straight from the hexclave.com/pricing page.

A few details are easy to miss. The free plan gives one dashboard admin, the paid plans four each, and every additional one costs 29 USD per month. The email quota does not grow between the 49 dollar plan and the 299 dollar plan; both stop at 25,000 messages. The session replay quota is 2,500 per month across all three plans, the free one included. What does grow is the analytics query timeout, from 10 seconds through 60 seconds to 5 minutes. There is no annual price, so there is nothing to multiply by twelve. An auth user means any account in the project, inactive ones included, which can surprise older projects with a long tail of dead accounts.

Self-hosting is free and the vendor says so prominently, with the caveat mentioned above: the server side is AGPLv3, and the alternative is a paid commercial licence.

What to use instead if you would rather not follow along

A rename is not by itself a reason to run, but it is a good moment for a review. Below are the licences declared in the npm registry for the respective SDK packages, checked on the same day.

If you are staying with the project, move to @hexclave/* and treat it as one proper migration instead of two. If you want something that keeps data in your own database and needs no vendor account, Better Auth is the closest fit, because it is a library rather than a service. If you prefer the same approach but with a self-hostable server and a separate engine, look at SuperTokens, keeping in mind the licensing nuances covered in that article. If you accept a closed service in exchange for ready-made components and a fast rollout, the natural reference point is Clerk, and for enterprise requirements such as SAML and directory sync, WorkOS. Auth0 remains the choice for organisations that need a mature vendor with a long history, while Kinde sits somewhere between Clerk and a cheap starter plan. Whichever you pick, the Next.js integration looks broadly similar across all of them today, so the cost of switching is mostly data migration rather than rewriting views.

The vendor advertises user imports from Clerk, Auth0, Firebase Auth and Supabase Auth without forcing password resets. That is information about traffic towards Hexclave, not away from it.

Common mistakes

Replacing @stackframe/stack with @hexclave/js instead of @hexclave/next is the most frequent slip, because the names suggest something other than what the mapping table says. The js package is the framework-agnostic variant.

Installing the unscoped hexclave package gives you a 660 byte placeholder that exits with an error code when run. The real tool is @hexclave/cli.

Swapping imports without fixing the issuer in JWT verification compiles fine and falls over in production, on the first token signed under the new domain.

Assuming passkeys carry over with everything else is wrong. Keys registered on .built-with-stack-auth.com do not work on .built-with-hexclave.com, because the standard binds them to the domain.

Recording the licence as "MIT" based on the npm field alone will not work, because the field is not there. Recording "AGPL" for the whole thing is inaccurate too, since it applies to the server side. The correct entry is a dual licence with a client and server split.

Leaving stack-auth.com links in your project documentation technically works thanks to the redirects, but a new team member will land on a page with a different name and lose fifteen minutes establishing whether it is really the same thing.

FAQ

Has Stack Auth ceased to exist?

No. The name changed; the code and the service run on under the Hexclave brand. The hexclave/hexclave repository has 6842 stars, is not archived and ships new versions every few days. The name disappeared, the project did not.

Will my app on @stackframe/stack stop working?

Not on any foreseeable date. The migration documentation states that both API addresses point at the same service and that staying on the old SDK requires no action. That said, the old package has had no release since 26 May 2026 and there is no statement about security fixes.

How much work is the migration?

For a typical Next.js project it is one dependency swap, replacing the Stack prefix with Hexclave in imports, and a fix to the JWT issuer if you verify tokens yourself. The old class names remain as aliases, so renaming is optional. Passkey re-registration has to be handled separately.

What is the Hexclave licence?

Dual, depending on the part. Client code and examples under MIT, server components including the backend and the dashboard under AGPLv3. Most packages carry no license field in the npm registry at all, so audit tooling will report them as unknown even though the MIT file sits inside every tarball.

How does Hexclave differ from the old Stack Auth in product terms?

The scope is wider. Beyond authentication, teams and roles it adds payments, emails, a vault for sensitive data, webhooks, analytics, clickmaps and session replays. Some of those dependencies were already present in the last release under the old name.

Did the vendor announce the rename?

I found no such announcement. The blog has no post on the subject, and the oldest post from 2024 was rewritten to the new brand without a note. The only place describing the change is the migration page in the documentation.