From an empty directory to a signed-in user.
DemoThe 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. A garbage token gets the same 401, with USER_TOKEN_INVALID in the body.
What you are looking at
The code on screen is the code the running app is serving, and the responses at the end are the responses it actually returned. Nothing is mocked up to look like output.
Scaffolding and installing take about a minute between them, and that minute is played back at a readable pace so you are not watching a progress bar. Everything after it runs at the speed it really runs at.
No credential here is live. Every address uses the reserved .example TLD, and the Application secret key never reaches the screen. 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.