CheckRoostCheckRoost
On your sites and servers

Next.js package

One route in your app lets CheckRoost check the packages it actually has deployed against published vulnerabilities.

@checkroost/next adds a route to your app that answers CheckRoost’s application health check with the Node, Next.js and React versions it runs and the exact version of every package it ships. CheckRoost checks those against OSV.dev every hour and lists anything affected, with the release that fixes it.

This is a change to your app's code, not to the server

Every step below happens in your app’s project — the folder with its package.json, on the computer where you work on it. You commit the change and deploy the way you always do. The only thing that goes on the server by hand is the token, in step 5. Running npm install on the server does nothing: the app never sees a package installed outside its own project.

What it reports, and what it does not

  • Reports: the Node, Next.js and React versions, and the name and version of every production package in the app’s lockfile. Development tools are left out.
  • Never: the environment, any file’s contents, or a path on the server.
  • Sends nothing. CheckRoost asks; the route answers, and only to a request carrying your token. With no token set it answers 503 to everybody. It is never cacheable.

Setting it up

  1. Step 1. Add the package, in the app’s project folder

    cd path/to/your-appnpm install @checkroost/next

  2. Step 2. Add the route

    Create app/api/checkroost/route.ts (or src/app/api/checkroost/route.ts):

    export { GET } from '@checkroost/next'export const dynamic = 'force-dynamic'

  3. Step 3. Let it past your proxy or middleware

    If your app has a proxy.ts or middleware.ts that sends signed-out visitors to a login page, or moves requests between hostnames, the health check will be caught by it — it carries a token, never a session. Add api/checkroost to the paths its matcher skips:

    export const config = {  matcher: ['/((?!_next/static|_next/image|api/checkroost|favicon.ico).*)'],}

  4. Step 4. If you build with output: ‘standalone’, include the lockfile

    A standalone build copies only the files the app imports, and the lockfile is not one of them. One line in next.config.ts puts it in the build:

    output: 'standalone',outputFileTracingIncludes: { '/api/checkroost': ['./package-lock.json'] },

    Use ./pnpm-lock.yaml for pnpm. An app run with next start from its project folder already has its lockfile and needs nothing here.

  5. Step 5. Put a token on the server

    Make one — a random string of at least 32 characters — and keep it to hand for step 7:

    openssl rand -hex 32

    Add it to the app’s environment on the server as CHECKROOST_TOKEN=…: the .env file or EnvironmentFile its service reads, or your host’s environment variables screen. Never commit it.

  6. Step 6. Commit and deploy as usual

    The app starts answering at /api/checkroost. It reads the token when it starts, so if you add the token after deploying, restart the app.

  7. Step 7. Turn on the health check

    In CheckRoost, open the site’s monitor, choose Edit, and turn on Application health with the address https://your-app/api/checkroost and a header named X-CheckRoost-Token holding the same token. The first reading arrives within five minutes, and its packages are matched within the hour.

Checking it from outside

Ask for the route with no token, from anywhere:

curl -i https://your-app/api/checkroost
  • 403 Working: it is deployed, the token is set, and it refused you because you sent none. This is the answer you want.
  • 503 Deployed, but CHECKROOST_TOKEN is not set where the app can read it — or it was added without restarting the app.
  • 404 The route is not in the deployed app. Check the file is at app/api/checkroost/route.ts and that the deploy carried it.
  • A redirect, or your login page Your proxy or middleware is catching it — step 3.

On the monitor, a reading that names no packages means the app could not find its lockfile — step 4. A reading that fails with HTTP 403 means the header on the monitor does not match CHECKROOST_TOKEN on the server.

Can't change the app, or deploy without a lockfile?

Connect GitHub instead: CheckRoost reads the lockfile from the repository. It shows what is in the code rather than what is deployed, so where an app runs this package too, the app’s own report is the one used.