Stack Auth to teraz Hexclave, co z tym zrobić

Stack Auth to teraz Hexclave, co z tym zrobić

Nazwa Stack Auth przestała obowiązywać pod koniec maja 2026 roku. Repozytorium stack-auth/stack-auth przekierowuje dziś na hexclave/hexclave, domena stack-auth.com na www.hexclave.com, a pakiety @stackframe/* zastąpiła rodzina @hexclave/*. Usługa i dane zostały te same, zmienił się szyld, a przy okazji także deklarowany zakres produktu.

Dowody na zmianę nazwy

Zamiast opierać się na tym, co pamięta wyszukiwarka, można sprawdzić same przekierowania. Trzy polecenia wystarczą, żeby zobaczyć, dokąd prowadzą stare adresy.

# repozytorium: stary adres kończy na koncie hexclave
curl -sL -o /dev/null -w "%{http_code} %{url_effective}\n" https://github.com/stack-auth/stack-auth

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

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

Pierwsze dwa zwracają 200 i adres docelowy https://github.com/hexclave/hexclave oraz https://www.hexclave.com/. Trzecie zwraca stronę o tytule Redirecting to Hexclave Docs. Przekierowanie repozytorium działa też dla wariantu pośredniego: github.com/hexclave/stack-auth ląduje w tym samym miejscu, czyli konto organizacji zostało przemianowane razem z repozytorium.

Datę można zawęzić na podstawie rejestru npm, bo daty publikacji są tam twarde. Ostatnie wydanie @stackframe/stack to 2.8.108 z 26 maja 2026 roku. Pierwsza wersja pakietu @hexclave/js pojawiła się 27 maja 2026 roku. Pakiet-zaślepka o nazwie hexclave bez zakresu został opublikowany jeszcze wcześniej, 23 maja 2026 roku, co wygląda na rezerwację nazwy kilka dni przed samą operacją. Jeden pakiet z dawnej rodziny wyszedł po terminie: @stackframe/stack-shared ma wersję 2.8.109 z 28 maja 2026 roku, czyli o dwa dni późniejszą niż reszta.

Oficjalnego ogłoszenia nie znalazłem. Blog na hexclave.com ma sześć wpisów i żaden nie dotyczy zmiany nazwy. Najstarszy z nich, pod adresem /blog/introducing-stack, nosi dziś tytuł "Introducing Hexclave, the open-source user management service" i jest datowany na 14 kwietnia 2024 roku, a w treści strony nie pada ani raz ciąg "Stack Auth", ani "stackframe". Stara treść została przepisana na nową markę bez adnotacji, choć adres wpisu zdradza pierwotną nazwę. Strona changelog nie renderuje wpisów bez JavaScriptu, więc nie potwierdzę, czy jest tam notatka o rebrandingu. Jedynym miejscem, które nazywa rzecz po imieniu, jest strona docs.hexclave.com/migration otwierająca się zdaniem, że Stack Auth jest teraz Hexclave.

Czy zmienił się tylko szyld

Stary opis pakietu @stackframe/stack, wciąż widoczny w rejestrze npm, mówi o zarządzanej usłudze uwierzytelniania. Nowe repozytorium przedstawia się jako "The user infrastructure platform" i wymienia katalog aplikacji, które włącza się według potrzeb.

Lista z README obejmuje uwierzytelnianie, zespoły, kontrolę dostępu opartą na rolach, klucze API, płatności, maile, magazyn wrażliwych danych użytkownika, webhooki oraz listę kontrolną przed uruchomieniem produkcyjnym. Dokumentacja dla agentów wymienia dodatkowo ochronę przed nadużyciami, integrację z Vercelem, analitykę, mapy kliknięć i nagrania sesji. Zakres faktycznie się poszerzył i nie jest to sam marketing, widać to po drzewie zależności. Pakiety dla frameworków, czyli @hexclave/react i @hexclave/next, ciągną rrweb do nagrywania sesji, @stripe/stripe-js razem z @stripe/react-stripe-js do płatności oraz ai w wersji 6 razem z @ai-sdk/react. Te same zależności miał już ostatni @stackframe/stack, więc rozszerzanie produktu zaczęło się przed zmianą nazwy. Rdzeń @hexclave/js, niezwiązany z żadnym frameworkiem, jest wyraźnie chudszy: z tego zestawu ma tylko rrweb, a całych zależności produkcyjnych trzynaście.

Praktyczna konsekwencja jest taka, że instalując pakiet dla Reacta albo dla Next.js po to, żeby dodać logowanie, wciągasz do drzewa zależności także klienta Stripe i bibliotekę do nagrywania sesji, niezależnie od tego, czy zamierzasz ich używać. Jeśli pilnujesz rozmiaru paczki albo listy poddostawców przetwarzających dane, to jest realny koszt, a nie szczegół, i wtedy warto sprawdzić, czy sam rdzeń @hexclave/js nie wystarczy.

Serwer analityczny działa na ClickHouse, co widać po metodzie queryAnalytics, przyjmującej surowy SQL. To wygodne przy debugowaniu i zarazem wiąże Cię z konkretnym silnikiem przy samodzielnym hostowaniu.

Licencja sprawdzona z trzech źródeł

Tu robi się ciekawie, bo trzy źródła mówią trzy różne rzeczy i żadne z nich nie jest kompletne.

Źródło pierwsze, plik LICENSE w katalogu głównym repozytorium, nie jest licencją. To pięć linii tekstu informującego, że projekt jest licencjonowany per pakiet, kod kliencki i przykłady na MIT, komponenty serwerowe na AGPLv3, a licencje komercyjne są dostępne po kontakcie mailowym. Tekst nadal zaczyna się od słowa "Stack", mimo że adres kontaktowy zmieniono na domenę hexclave. Faktyczne licencje leżą głębiej: apps/backend/LICENSE i apps/dashboard/LICENSE zawierają pełny tekst AGPLv3, a packages/template/LICENSE pełny tekst MIT z notą "Copyright 2024 Stackframe".

Źródło drugie, pole license w rejestrze npm, po prostu nie istnieje. Nie ma go ani @stackframe/stack 2.8.108, ani @stackframe/js, ani @hexclave/js 1.0.102, ani @hexclave/next, ani @hexclave/react, ani @hexclave/tanstack-start. Brak pola przy sześciu pakietach z rzędu nie jest wypadkiem przy pracy, tylko stanem utrzymującym się od dawna. Potwierdza to plik packages/js/package.json w repozytorium, w którym również nie ma klucza license. Wyjątkiem jest @hexclave/cli, który deklaruje MIT.

Źródło trzecie, zawartość opublikowanej paczki, wypada najlepiej. W tarballu @hexclave/js 1.0.102 leży package/LICENSE z pełnym tekstem MIT, 1058 bajtów, z notą "Copyright 2024 Stackframe". Dokładnie ten sam plik, co do bajta, jest w @stackframe/stack 2.8.108. Plik nie występuje w gałęzi głównej pod packages/js/LICENSE, choć tablica files w manifeście go wymienia, więc jest dokładany w trakcie budowania, najprawdopodobniej z pakietu szablonowego. To już moje wnioskowanie, nie deklaracja dostawcy.

Osobny kwiatek: @hexclave/cli deklaruje w manifeście MIT, ale plik LICENSE w jego paczce zawiera nie licencję, lecz ten sam pięciolinijkowy tekst odsyłający do licencji poszczególnych pakietów. Deklaracja i załącznik mówią co innego.

Dla audytu zależności wynika z tego kilka rzeczy naraz. Narzędzia czytające wyłącznie pole license z rejestru zaraportują pakiety Hexclave jako nieokreślone i część korporacyjnych polityk to zablokuje. Narzędzia skanujące pliki w node_modules znajdą MIT i przepuszczą. Repozytorium jako całość ma AGPLv3 na częściach serwerowych, więc samodzielne hostowanie wciąga Cię w AGPL, a wyjściem jest licencja komercyjna od dostawcy. Nota o prawach autorskich nadal wskazuje starą nazwę firmy, co przy formalnym przeglądzie prawnym trzeba będzie umieć wytłumaczyć.

Migracja z @stackframe na @hexclave

Przewodnik migracji istnieje i jest konkretny. Mapowanie pakietów wygląda tak.

Zwróć uwagę na pułapkę w pierwszym wierszu: pakiet nazywający się stack odpowiada pakietowi nazywającemu się next, a nie js. Zamiana nazw przez proste podstawienie tekstu wprowadzi błąd.

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

Publiczne API pozostało to samo, przemianowano jedynie prefiks Stack na Hexclave.

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

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

Stare nazwy nadal działają jako aliasy. Widać to w deklaracjach typów opublikowanej paczki: @hexclave/js eksportuje równolegle HexclaveServerApp i StackServerApp, HexclaveClientApp i StackClientApp, defineHexclaveConfig i defineStackConfig. Symetrycznie ostatnie wydanie @stackframe/stack eksportuje już HexclaveServerApp, czyli nowe nazwy trafiły do starego pakietu jeszcze przed przekierowaniem domen.

Konstruktor przyjmuje te same opcje co wcześniej.

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

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

Wartość tokenStore to "nextjs-cookie" dla Next.js, "cookie" dla innych frontendów przeglądarkowych i null dla środowisk czysto serwerowych. Dla urls.default.type dokumentacja zaleca dziś "hosted" zamiast dawnego "handler", przy czym wariant hostowany nie generuje już ścieżek w rodzaju /handler/sign-in.

Zmiany, które trzeba zrobić poza importami, są dwie. Twardo wpisany adres https://api.stack-auth.com zamieniasz na https://api.hexclave.com. Jeśli weryfikujesz tokeny JWT samodzielnie, poprawiasz oczekiwanego wystawcę, bo nowe SDK podpisuje pod nową domeną.

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

To samo dotyczy wariantów wystawcy dla użytkowników anonimowych i ograniczonych, czyli ścieżek /api/v1/projects-anonymous-users/ oraz /api/v1/projects-restricted-users/. Reszta jest opcjonalna: nagłówki X-Stack-* można przemianować na X-Hexclave-*, zmienne środowiskowe STACK_* na HEXCLAVE_*, a tokeny z prefiksem stackauth_ pozostają ważne. Adresy zwrotne OAuth wskazujące na starą domenę działają dalej, ale dostawca odtworzony na nowo w panelu dostanie już adres w domenie hexclave.

Jedna rzecz nie migruje bezboleśnie. Strony hostowane przeniesiono z poddomeny .built-with-stack-auth.com na .built-with-hexclave.com, a klucze passkey są przypisane do domeny, w której je zarejestrowano, i nie przenoszą się między jedną a drugą. Jeśli masz użytkowników z passkey na starej domenie, zaplanuj ponowną rejestrację.

Narzędzie wiersza poleceń zmieniło nazwę binarki. Stary program stack nie jest już publikowany, jego miejsce zajmuje hexclave z pakietu @hexclave/cli.

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

Polecenie hexclave dev wstrzykuje do procesu potomnego zmienne HEXCLAVE_PROJECT_ID i HEXCLAVE_SECRET_SERVER_KEY, także z przedrostkami NEXT_PUBLIC_ i VITE_ dla wartości niewrażliwych.

Co dalej ze starymi pakietami

Dokumentacja migracji mówi wprost, że pozostanie przy starym SDK nie wymaga żadnego działania, bo api.stack-auth.com i api.hexclave.com wskazują na tę samą usługę. To odpowiedź na pytanie, czy Twój projekt przestanie działać w poniedziałek. Nie przestanie.

Czego dokumentacja nie mówi, to czy stare pakiety dostaną jeszcze jakiekolwiek wydania. Fakty z rejestru sugerują, że nie: @stackframe/stack stoi na 2.8.108 od 26 maja 2026 roku, czyli od blisko trzech miesięcy, a rodzina @hexclave/* wydała w tym czasie kolejne wersje aż do 1.0.102 z 20 sierpnia. Deklaracji o końcu wsparcia nie znalazłem, ale nie znalazłem też żadnej obietnicy poprawek bezpieczeństwa dla starych paczek. Przy bibliotece uwierzytelniającej to wystarczający powód, żeby migrację zaplanować, nawet jeśli nic nie pali się dzisiaj.

To nie jest przy tym projekt-atrapa porzucony po dwóch wydaniach. @stackframe/stack ma 225 opublikowanych wersji od marca 2024 roku, @hexclave/js w niecałe trzy miesiące dobił do 98. Repozytorium hexclave/hexclave ma 6842 gwiazdki i 522 rozgałęzienia, nie jest zarchiwizowane, a wydania w kanale atom pojawiają się co kilka dni. Porzucona jest nazwa, nie kod.

Osobna sprawa to pakiet npm o gołej nazwie hexclave. Wersja 0.0.1 z 23 maja 2026 roku, licencja MIT, trzy pliki, 660 bajtów po rozpakowaniu. Cała jego zawartość to skrypt, który wypisuje komunikat i kończy się kodem błędu. Co gorsza, komunikat i README nie zgadzają się ze sobą: opis pakietu i README odsyłają do @hexclave/hexclave, którego w rejestrze npm nie ma, a skrypt binarki odsyła do @hexclave/cli, który istnieje i jest prawdziwym narzędziem. To zaślepka rezerwująca nazwę, z nieaktualną instrukcją w środku. Nie instaluj jej i nie traktuj jako punktu wejścia.

Przy okazji dwie rzeczy do sprawdzenia w blokadzie zależności. Pakiety rodziny są sztywno przypięte do jednej wersji: @hexclave/next 1.0.102 wymaga dokładnie @hexclave/ui 1.0.102, @hexclave/sc 1.0.102 i @hexclave/shared 1.0.102, więc mieszanie wersji nie przejdzie. Zakres zależności równorzędnej dla Reacta został przy okazji obniżony: @stackframe/stack wymagał react w wersji co najmniej 18.3.0, @hexclave/next przyjmuje już >=18.0.0. Zakres dla Next.js pozostał bez zmian, czyli >=14.1 z dopuszczeniem wydań kandydujących piętnastki.

Cennik pod nową nazwą

Cennik jest opublikowany i renderuje się bez JavaScriptu, więc dane poniżej pochodzą wprost ze strony hexclave.com/pricing.

Do tego kilka szczegółów, które łatwo przeoczyć. Plan darmowy daje jednego administratora panelu, płatne po czterech, a każdy kolejny kosztuje 29 USD miesięcznie. Limit maili nie rośnie między planem za 49 a planem za 299 dolarów, w obu wypadkach jest to 25 tysięcy wiadomości. Limit nagrań sesji wynosi 2500 miesięcznie we wszystkich trzech planach, także w darmowym. Rośnie za to limit czasu zapytania analitycznego, od 10 sekund przez 60 sekund do 5 minut. Cennika rocznego nie ma, więc nie ma czego mnożyć przez dwanaście. Za użytkownika auth uważa się każde konto w projekcie, także nieaktywne, co przy starych projektach z długim ogonem martwych kont potrafi zaskoczyć.

Samodzielne hostowanie jest darmowe i dostawca to eksponuje, z zastrzeżeniem, o którym była mowa wyżej: część serwerowa jest na AGPLv3, a alternatywą jest płatna licencja komercyjna.

Czym zastąpić, jeśli nie chcesz iść dalej

Zmiana nazwy sama w sobie nie jest powodem do ucieczki, ale jest dobrym momentem na przegląd. Poniżej licencje deklarowane w rejestrze npm dla pakietów SDK, sprawdzone tego samego dnia.

Jeśli zostajesz przy projekcie, przejdź na @hexclave/* i potraktuj to jako jedną porządną migrację zamiast dwóch. Jeśli szukasz czegoś, co trzyma dane w Twojej bazie i nie wymaga konta u dostawcy, najbliżej jest Better Auth, bo to biblioteka, a nie usługa. Jeśli wolisz to samo podejście, ale z możliwością samodzielnego hostowania serwera i osobnym silnikiem, sprawdź SuperTokens, pamiętając o niuansach licencyjnych opisanych w tamtym artykule. Jeśli akceptujesz zamkniętą usługę w zamian za gotowe komponenty i szybkie wdrożenie, naturalnym punktem odniesienia jest Clerk, a przy wymaganiach korporacyjnych, takich jak SAML i katalogi użytkowników, WorkOS. Auth0 pozostaje wyborem dla organizacji, które potrzebują dojrzałego dostawcy z długą historią, a Kinde mieści się gdzieś pomiędzy Clerkiem a tanim planem startowym. Niezależnie od wyboru, integracja z Next.js wygląda dziś podobnie u każdego z nich, więc koszt zmiany to głównie migracja danych, a nie przepisywanie widoków.

Dostawca deklaruje import użytkowników z Clerka, Auth0, Firebase Auth i Supabase Auth bez wymuszania resetu haseł. To informacja o ruchu w stronę Hexclave, nie w drugą stronę.

Typowe błędy

Zamiana @stackframe/stack na @hexclave/js zamiast na @hexclave/next to najczęstsza pomyłka, bo nazwy sugerują coś innego, niż mówi tabela mapowania. Pakiet js jest wariantem bez integracji z frameworkiem.

Instalacja pakietu hexclave bez zakresu daje zaślepkę o wielkości 660 bajtów, która przy uruchomieniu kończy się kodem błędu. Właściwe narzędzie to @hexclave/cli.

Podmiana importów bez poprawienia wystawcy w weryfikacji JWT przechodzi kompilację i przewraca się dopiero na produkcji, przy pierwszym tokenie podpisanym pod nową domeną.

Założenie, że passkey przeniosą się razem z resztą, jest nieprawdziwe. Klucze zarejestrowane na .built-with-stack-auth.com nie działają na .built-with-hexclave.com, bo standard wiąże je z domeną.

Wpisanie w rejestrze licencji "MIT" na podstawie samego pola z npm nie zadziała, bo tego pola tam nie ma. Wpisanie "AGPL" dla całości też będzie nieścisłe, bo dotyczy części serwerowej. Właściwy zapis to podwójna licencja z rozróżnieniem na klienta i serwer.

Pozostawienie w dokumentacji projektu odnośników do stack-auth.com formalnie działa dzięki przekierowaniom, ale nowa osoba w zespole trafi na stronę o innej nazwie i straci kwadrans na ustalanie, czy to na pewno to samo.

FAQ

Czy Stack Auth przestał istnieć?

Nie. Zmieniła się nazwa, kod i usługa działają dalej pod marką Hexclave. Repozytorium hexclave/hexclave ma 6842 gwiazdki, nie jest zarchiwizowane i wydaje nowe wersje co kilka dni. Zniknęła nazwa, nie projekt.

Czy moja aplikacja na @stackframe/stack przestanie działać?

Nie w przewidywalnym terminie. Dokumentacja migracji mówi, że oba adresy API wskazują na tę samą usługę i pozostanie przy starym SDK nie wymaga działania. Stary pakiet nie dostał jednak wydania od 26 maja 2026 roku i nie ma deklaracji o poprawkach bezpieczeństwa.

Ile pracy kosztuje migracja?

Przy typowym projekcie w Next.js to zamiana jednej zależności, podmiana prefiksu Stack na Hexclave w importach oraz poprawka wystawcy JWT, jeśli weryfikujesz tokeny samodzielnie. Stare nazwy klas zostały jako aliasy, więc zmiana nazw jest opcjonalna. Osobno trzeba obsłużyć ponowną rejestrację passkey.

Jaka jest licencja Hexclave?

Podwójna, zależnie od części. Kod kliencki i przykłady na MIT, komponenty serwerowe, w tym backend i panel, na AGPLv3. W rejestrze npm większość pakietów nie ma w ogóle pola license, więc narzędzia do audytu zaraportują je jako nieokreślone, mimo że plik MIT leży w każdej paczce.

Czym różni się Hexclave od dawnego Stack Auth pod względem produktu?

Zakres jest szerszy. Poza uwierzytelnianiem, zespołami i rolami dochodzą płatności, maile, magazyn wrażliwych danych, webhooki, analityka, mapy kliknięć i nagrania sesji. Część tych zależności była już obecna w ostatnim wydaniu pod starą nazwą.

Czy dostawca ogłosił zmianę nazwy?

Nie znalazłem takiego ogłoszenia. Blog nie ma wpisu na ten temat, a najstarszy wpis z 2024 roku został przepisany na nową markę bez adnotacji. Fakt zmiany opisuje wyłącznie strona migracji w dokumentacji.