UI kits: use the Better Auth ecosystem, keep Signet headless

Status: adopted 2026-08-04.

Signet will not ship a separate signet-ui package. For React applications, the recommended starting point is the open-source Better Auth UI ecosystem, with a stock Better Auth client pointed at the Signet HTTP base path. Signet remains responsible for the certified wire; the UI kit remains an application dependency that the application pins, tests, themes, and upgrades.

This is a selective blessing, not a claim that every Better Auth UI component works. The audited combination is:

Better Auth UI v1.6.43 is MIT-licensed and its React/HeroUI packages declare better-auth >=1.6.19, which includes Signet's certified 1.6.23 client. The exact upstream source inspected for this decision was commit 74a9a5091abf4e2a26976c59d6e281835e2bb917, released 2026-07-29. Pin exact versions in a lockfile; do not turn this audit into an unbounded latest compatibility claim.

Supported integration boundary

Create the browser client normally and give it to Better Auth UI:

import { createAuthClient } from "better-auth/react"
import { AuthProvider } from "@better-auth-ui/react"
import type { ReactNode } from "react"

export const authClient = createAuthClient({
  baseURL: "https://auth.example.com/api/auth",
})

export function AuthRoot({ children }: { children: ReactNode }) {
  return (
    <AuthProvider
      authClient={authClient}
      navigate={({ to, replace }) =>
        replace ? window.location.replace(to) : window.location.assign(to)
      }
    >
      {children}
    </AuthProvider>
  )
}

The browser/runtime data layer is the compatibility seam: it calls methods on the supplied stock Better Auth client, which sends HTTP requests to Signet. The core email/password, social sign-in, sign-out, verification/reset, session, profile, linked-account, and active-session surfaces may be used against enabled Signet routes.

Three rules keep that statement honest:

1. Configure baseURL with Signet's full auth base path, normally /api/auth, and preserve credentials/cookies through the application's origin and proxy policy.
2. Enable only UI plugins whose complete endpoint set appears in the running instance's /open-api/generate-schema or /llms-full.txt. A typed client method existing in npm does not prove that the server implements it.
3. Exercise sign-up, sign-in, reset/verification, callback, and sign-out in the application's E2E suite before deployment. Signet certifies the HTTP profile, not third-party rendering, navigation, framework, or package upgrades.

One current example is passkey management: Better Auth UI calls list/add/delete client methods, while this Signet build advertises only the lower-level register/authenticate option and verify routes. CAPTCHA/bot UI is also outside the binary. Organization, phone, magic-link, email-OTP, two-factor, username, API-key, device, and multi-session UI must still be limited to the endpoints actually advertised by the deployed instance.

Server rendering boundary

Do not use @better-auth-ui/react/server recipes that receive a Better Auth Auth object and call auth.api directly. Signet is a Rust HTTP service, not an in-process TypeScript Better Auth server, so it cannot satisfy that interface.

For SSR, either render the auth shell client-side or fetch the Signet HTTP endpoint from the application server while forwarding the request cookie and preserving set-cookie where the flow needs it. Treat that adapter as application code and test it. Client-side TanStack Query helpers remain usable because they operate through the supplied browser client.

Why there is no signet-ui

A Signet-owned component library would duplicate fast-moving framework, styling, accessibility, localization, and auth-plugin work while adding a second compatibility surface. Better Auth UI already supplies a maintained component/data ecosystem and accepts the stock client that Signet certifies. The narrower Signet responsibility is more durable: document the HTTP boundary, publish the real route inventory, audit one pinned combination, and refuse unsupported server-direct or partial-plugin claims.

Revisit this decision if the ecosystem stops accepting the certified browser client, if a required Signet capability cannot be expressed through its extension points, or if customers require a Signet-owned hosted account portal with a support/versioning promise. Until then, downstream apps own their chosen UI package; Signet owns the wire.

Upstream references

Retrieved 2026-08-04:

• Better Auth UI documentation and component catalog: https://better-auth-ui.com/
• React data layer: https://better-auth-ui.com/docs/react
• SSR integration boundary: https://better-auth-ui.com/docs/react/ssr
• Audited source and MIT license: https://github.com/better-auth-ui/better-auth-ui/tree/v1.6.43