Nuxt

npm

1. Install the package.

   npm install @ritim/browser-sdk

2. Add a client plugin. The .client suffix is the important part: it tells Nuxt to run this on the browser only, and init() touches window.

   plugins/ritim.client.ts

   import { init } from '@ritim/browser-sdk';
   
   export default defineNuxtPlugin(() => {
     init({ projectKey: 'P-ABC123' });
   });

That is the entire integration — Nuxt auto-registers anything in plugins/, so there is nothing to add to nuxt.config.ts.

You do not hook useRouter or router.afterEach either. Vue Router navigates by calling history.pushState, which the SDK already watches.

`.client` is not optional

A plugin named ritim.ts runs on the server too, where there is no window. The SDK guards against it, but the plugin is dead weight in your server bundle and any code you add around it will not be as careful. Name the file ritim.client.ts.

Where in the lifecycle it runs

Plugins run during app initialisation, before the first route renders — earlier than a React effect would. There is nothing to gain by moving it into app:mounted, and doing so only delays the first measurement.

Script tag

Declare it in nuxt.config.ts and Nuxt puts it in the head of every page:

nuxt.config.ts

export default defineNuxtConfig({
  app: {
    head: {
      script: [
        {
          src: 'https://cdn.ritim.io/latest/rum.min.js',
          async: true,
          'data-project-key': 'P-ABC123',
        },
      ],
    },
  },
});

Or from a single page or layout, when you only want it on part of the site:

<script setup lang="ts">
useHead({
  script: [
    {
      src: 'https://cdn.ritim.io/latest/rum.min.js',
      async: true,
      'data-project-key': 'P-ABC123',
    },
  ],
});
</script>

Navigation still needs no wiring — Vue Router calls history.pushState, which the SDK watches on its own.

Releases

Nuxt is the easy case. It publishes a build identifier on every client payload — app.buildId in the runtime config — and the SDK reads it. A Nuxt app that configures nothing still gets one release per deploy, on both install paths, and the dashboard can attribute a regression to a specific build.

The catch is what that value is. Nuxt generates it per build, so it is stable across a deploy and changes when you rebuild — the right shape for a release — but it is a generated identifier rather than one you chose. It tells you which build regressed without telling you what changed in it.

Name it yourself

Set buildId in nuxt.config.ts. It is the same field the SDK already reads, so there is nothing to change in your plugin or your script tag:

nuxt.config.ts

export default defineNuxtConfig({
  buildId: process.env.GIT_SHA,
});

Now the release is a commit you can look up, and detection keeps working exactly as before. See buildId in the Nuxt config reference.

This one is baked in at build time

buildId is build configuration, not runtime configuration, so its value is fixed when you run nuxt build. If you promote one build artifact through staging and production and want each to report its own release, use the runtime config route below instead — it can be changed per environment without rebuilding.

Or declare it at runtime

Nuxt’s runtime config is readable on the client and overridable by an environment variable at run time, which is what makes it the right home for a value that differs per environment:

npm

nuxt.config.ts

export default defineNuxtConfig({
  runtimeConfig: {
    public: {
      buildId: '',
    },
  },
});

plugins/ritim.client.ts

import { init } from '@ritim/browser-sdk';

export default defineNuxtPlugin(() => {
  const { public: config } = useRuntimeConfig();

  init({
    projectKey: 'P-ABC123',
    release: config.buildId || undefined,
  });
});

Script tag

nuxt.config.ts

export default defineNuxtConfig({
  app: {
    head: {
      script: [
        {
          src: 'https://cdn.ritim.io/latest/rum.min.js',
          async: true,
          'data-project-key': 'P-ABC123',
          'data-release': process.env.GIT_SHA,
        },
      ],
    },
  },
});

The head is rendered at build time here, so this is the build-time route rather than the runtime one — prefer buildId above unless you have a reason not to.

Because it is runtime config, NUXT_PUBLIC_BUILD_ID overrides it wherever the app runs, with no rebuild. The naming rule and the full mechanism are in Runtime Config.

Where `GIT_SHA` itself comes from is your platform's business

Environment variables are set by whatever builds or runs your app — a CI job, your host’s project settings, a Dockerfile — and every platform names and injects them differently. This documentation deliberately does not cover that: we would only be paraphrasing someone else’s docs, and the details change.

Nuxt’s Runtime Config guide is the reference for which variables Nuxt reads, when, and under what names.

If the variable is unset, the release falls back to the build identifier Nuxt generates on its own. You still get a release, just a less useful one.

Next steps

Verifying an installConfirm measurements are flowing, and the three things that usually stop them.

ConfigurationSampling, soft navigations and the rest of the options.