Skip to main content
This guide shows you how to wire @hyperauth/react into a Next.js App Router project. By the end, your app will mount HyperAuthProvider on the client, emit the Content Security Policy directives the SDK needs to boot, and read its runtime configuration from environment variables. Use this guide if you build with Next.js 14 or later on the App Router. If you use Vite or another bundler, the Quickstart covers the simpler setup path.

Prerequisites

  • A Next.js 14+ project using the App Router.
  • Node.js 18 or higher and a package manager (npm, pnpm, or bun).
  • A browser that supports WebAuthn (Chrome, Firefox, or Safari).

Install the packages

@hyperauth/react declares viem as a peer dependency. Install all three together:
Make sure your lockfile resolves a single copy of react. If you ship a workspace with multiple apps, dedupe React at the root — the provider relies on useSyncExternalStore, which throws if it sees two React instances.

Wrap the provider for the client boundary

HyperAuthProvider spawns browser workers and reads useSyncExternalStore at module-eval time. Both require the client runtime, so import it through next/dynamic with ssr: false:
app/_providers/hyperauth-provider.tsx
Don’t import @hyperauth/react directly into app/layout.tsx. The package’s production bundle uses react/jsx-runtime, and Next.js will try to resolve the SSR path of the provider at build time. Routing the import through next/dynamic({ ssr: false }) keeps the SDK off the server entirely.
Then mount the wrapper in the root layout:
app/layout.tsx
Components inside the tree can now call useHyperAuth and the other hooks from @hyperauth/react. See the React Hooks Reference for the full surface.

Emit the required CSP

The SDK needs a specific set of Content Security Policy directives to boot. Without them, workers fail to start, OPFS writes are blocked, or the bundler ALPN handshake silently drops. Use Next.js middleware (named proxy.ts in Next 16+, middleware.ts in earlier versions) to attach the header:
proxy.ts
If @hyperauth/react’s exports map can’t be resolved from the edge runtime in your setup, inline the directive string verbatim by running bun --print "import('@hyperauth/react').then(m => console.log(m.cspManifestString()))" and pasting the output. Re-run after each SDK upgrade.

Why CSP is gated to production

Next.js dev injects inline scripts for HMR and RSC hydration markers that would violate script-src 'self' 'wasm-unsafe-eval'. Those scripts don’t exist in production builds, so the default gate is NODE_ENV === "production". A nonce-based strategy is required to enforce CSP in dev too — out of scope for this guide.

Configure runtime env vars

Document the SDK’s runtime configuration in .env.example so contributors know what to set:
.env.example
The NEXT_PUBLIC_ prefix is required so the values reach the browser bundle — the provider runs on the client.

Verify the boot

A quick way to confirm the provider booted is a smoke test that fails on any SDK-related console error:
e2e/hyperauth-boot.spec.ts
Run it against a production build (next build && next start) so the middleware enforces CSP and the test exercises the same code paths as a real deployment.

Next steps