# Next.js Plugin Reference — @rep-protocol/next
> API reference for the REP Next.js plugin. RepScript props, the session-key route handler, and how the plugin behaves in dev vs. production builds.
Source: https://rep-protocol.dev/reference/plugins/next/
```bash
npm install -D @rep-protocol/next
```
```tsx
// app/layout.tsx
import type { ReactNode } from 'react';
import { RepScript } from '@rep-protocol/next';
export default function RootLayout({ children }: { children: ReactNode }) {
return (
{children}
);
}
```
## ``
```typescript
interface RepScriptProps {
env?: string;
strict?: boolean;
}
function RepScript(props?: RepScriptProps): React.ReactElement | null;
```
A React Server Component. Renders `` breakout from untrusted env values. The tag still carries `type="application/json"`, so the browser never executes it.
- **Ephemeral keys are process-scoped**, held in a module-level singleton (`getOrCreateKeys()`) so the same key survives across route handler invocations within one `next dev` process.
- **Guardrails scan every `REP_PUBLIC_*` value whole**, including `csv` values the gateway scans by element ([details](/guides/feature-flags/#dev-plugins)).
- **Byte-identical payload** to the Go gateway and the Vite plugin (sorted keys, same HMAC + SRI format) — `rep.verify()` and `rep.meta()` behave the same regardless of which one produced the payload.
## App Router only
`RepScript` is a Server Component and requires the App Router (`app/`). The Pages Router (`pages/`) doesn't support React Server Components — use the [CLI dev server](/guides/development/#option-d-cli-dev-server-full-fidelity) or [mock payload](/guides/development/#option-c-mock-payload-in-html) approach instead.
## See also
- [Local Development guide](/guides/development/) — where this fits alongside the CLI dev server and mock-payload approaches
- [Next.js — Proxy Mode example](/examples/nextjs-proxy/) — production deployment behind the gateway
- [Vite plugin reference](/reference/plugins/vite/) — the equivalent for Vite