Demo
From an empty directory to a signed-in user.
The operator-panel walkthrough shows the Rekey side: an Application, a key, an auth config. These two show the other side — what you actually type in your own project. Both start with an empty directory and the framework's own scaffolder, and both end with the thing working, in a browser or in a terminal.
Next.js — sign-in in a fresh App Router project
create-next-app to a working sign-up, with @rekey.dev/nextjs. Four files: the env, the middleware, a server action, a protected page.
What happens, in order
create-next-app, from nothing
An empty directory and the stock scaffolder — no template, no starter kit, nothing pre-wired.
Install @rekey.dev/nextjs
One package. It brings the App Router middleware, the server-side auth() helpers and the browser client with it. The install you see is from a tarball built out of the Rekey repository — see the note below.
Two credentials, two homes
The secret key powers the server and never gets a NEXT_PUBLIC_ prefix. The publishable key is browser-safe by design — it names the Application and grants nothing on its own.
Gate routes in middleware.ts
rekeyMiddleware checks for the session cookie at the edge and redirects to /login with a next param. No network call per request.
A sign-up action and a protected page
signUp() in a server action puts the token pair straight into httpOnly cookies; auth() reads them back in a server component. The browser never touches a token.
It works — and the operator sees it
/dashboard while signed out redirects. Signing up lands on it. The same user is then in the operator panel's end-user list, seconds after being created.
NestJS — a guard on a protected route
nest new to a route that refuses requests without a valid end-user token, with @rekey.dev/node. Three files, one of which is the controller you already had.
What happens, in order
nest new, from nothing
The stock Nest CLI scaffold — the same one you would run for any new service.
Install @rekey.dev/node
The server SDK. One client per Application, constructed once at module scope rather than per request. Installed from a repository build, as above.
A guard, not a middleware you wrote
Twenty lines implementing CanActivate. getCurrentUser resolves the end user behind the JWT; a RekeyError becomes a 401 carrying the real error code.
Put a route behind it
@UseGuards(RekeyAuthGuard) on the controller method. The handler reads req.user and nothing else changes.
200 with a token, 401 without
Two real requests against the running server, made while the recording was being produced. A garbage token gets the same 401, with USER_TOKEN_INVALID in the body.
How these recordings are made
Each is one command: pnpm demo:record:nextjs and pnpm demo:record:nest. Each creates a scratch Postgres database, boots the API from this repository, really runs create-next-app or nest new into a temporary directory, writes the files you see, starts the resulting app, records the session, and then deletes the database and the directory.
The code on screen is the code the running app is serving — the same strings are written to disk and typed into the editor pane. The command output is whatever the tool actually printed on that run, not prose styled to look like output. The closing responses are real responses, and the scripts fail the run rather than record an unexpected status, so a final frame cannot show a 200 that did not happen.
Two things are honestly not real time. The scaffolding and install steps take about a minute between them; they run before the camera rolls and their real output is replayed at a readable pace. And the terminal is a styled HTML pane rather than a captured TTY — that is what lets a single continuous take cut from a terminal straight into a live browser without stitching two recordings together.
One thing you will notice on the install line: the SDK comes from a .tgz packed out of the Rekey repository rather than from npm i @rekey.dev/nextjs. That is deliberate, and we would rather show it than hide it. It keeps these recordings pinned to the same commit as the API they run against, so they cannot drift into demonstrating a version that no longer exists — and, at the time of recording, it was also load-bearing: the 2.0 release candidate on npm ships an exports map that a CommonJS project cannot resolve, and nest new scaffolds CommonJS. Both are fixed in the repository and waiting on a release; the recording scripts take DEMO_SDK_SOURCE=registry to switch back the day it lands.
No credential in either video is live. The workspace, the Application and its keys are created seconds before the recording and destroyed seconds after it, every address uses the reserved .example TLD, and the Application secret key is masked before it can reach the page at all rather than blurred after the fact. The publishable key is visible on purpose: it is public by design, and the split between the two is half the point of that step.
Prefer to read it? The SDK reference covers every method these two videos touch, and a good deal more.