Checklist
Add Sentry to a vibe-coded app
Short answer. Install the SDK for the framework you actually ship, put the DSN in the client, and keep the source-map auth token in the build environment only. Turn down what the SDK attaches, and lower the trace sample rate before real traffic. A stack trace is not a guarantee the app is fine.
Updated 9 Nov 2026
This is a practical checklist, not a guarantee. It is not a penetration test, a compliance audit, or proof that an app is safe to launch.
The directory entry is Sentry. This page is how to add it to an app a builder generated. If you are choosing between products, see Sentry vs LogRocket vs PostHog. The rest of the launch pass is the pre-launch checklist.
Sentry's docs below were read on 9 Nov 2026. The wizard and the option names change between SDK major versions. If a snippet here disagrees with the page it links, follow that page.
Pick the SDK that matches the app
A Lovable, Bolt, v0, or Cursor project is still some framework. Sentry's React guide says to use the dedicated SDK when the app is Next.js, Remix, or another server-rendered framework. A client-only Vite app uses @sentry/react.
- Next.js, including many v0 projects: Sentry for Next.js. The documented wizard is
npx @sentry/wizard@latest -i nextjs. Prerequisites on that page are Next.js 14 or higher and Node.js 20.19.0 or higher. - Vite or another client-side React app: Sentry for React. Install with
npm install @sentry/react --save. - Source maps on Vite, webpack, Rollup, or esbuild: the React guide points at
npx @sentry/wizard@latest -i sourcemaps, and the Vite upload page shows the plugin.
Create a Sentry project first so you have a DSN. The wizard can do that for Next.js. On Lovable or Bolt, you often cannot run the wizard inside the builder. Get the files in by the builder's code editor, or export or sync the project to GitHub and run the wizard in that clone. The per-builder lists are Ship a Lovable app, Ship a Bolt app, Ship a v0 app, and Ship a Cursor app.
Next.js: run the wizard
From the repository root, Sentry's Next.js page says to run:
npx @sentry/wizard@latest -i nextjsThe wizard asks about Tracing, Session Replay, routing browser requests through your server, and an example page. It writes a browser init (instrumentation-client.ts), a Node init (sentry.server.config.ts), an Edge init (sentry.edge.config.ts), and instrumentation.ts, which loads the server configs and exports onRequestError. For the App Router it also edits app/global-error.tsx. It wraps next.config with withSentryConfig.
If you would rather not run the wizard, the manual setup installs @sentry/nextjs and shows the same withSentryConfig wrapper. That page says to keep the auth token secret and out of version control.
Answer the wizard for the app you have. Replay and a tunnel route add data and server traffic. Sentry's Next.js page says a tunnel can increase server load and the hosting bill. You can remove an integration you do not want from the init files.
Vite and other React apps
Sentry's React page is for a client-side SPA. Create an init file, for example instrument.js, and import it before any other import in the entry file. Call Sentry.init with the DSN. Their snippet also turns on browserTracingIntegration, replayIntegration, and feedbackIntegration. Drop the ones you are not using.
For React 19 they show Sentry.reactErrorHandler on createRoot. For React 18 and earlier they show Sentry.ErrorBoundary.
Readable stack traces need source maps. Their React page says to run npx @sentry/wizard@latest -i sourcemaps and pick Vite when that is the bundler. The Vite plugin goes last in the plugins array, build.sourcemap must be on ("hidden" or true), and the plugin reads SENTRY_AUTH_TOKEN from the environment, from the authToken option, or from .env.sentry-build-plugin. Add that file to .gitignore. Vite does not load .env into process.env while it evaluates the config file. Their page says to use loadEnv if you want the token from a .env file inside vite.config. The plugin does not upload maps in dev or watch mode. Run a production build to see whether the upload worked.
The DSN is not the auth token
Sentry's DSN explainer says a DSN tells the SDK where to send events. It only allows submitting new events. It does not allow reading project data. The same page says a DSN can still be abused: anyone who has it can send events to that project. You can rotate it under the project's client keys, and you can block IPs. Putting the DSN in client code, or in a NEXT_PUBLIC_ / VITE_ variable, matches how the SDK is meant to run in the browser.
The auth token is a different credential. Sentry's auth tokens page says you use one to upload source maps, to run the CLI, or to call the API. The Next.js guide says the wizard writes it to .env.sentry-build-plugin and gitignores that file, and that CI should set SENTRY_AUTH_TOKEN in the build system instead. The manual setup says to keep it out of version control. Do not put it in a name the framework ships to the browser. The distinction is the same one in API keys in the frontend and how to keep API keys out of AI-generated code. If a builder chat or a committed .env already has the token, revoke that token in Sentry and create another one for CI only.
What the SDK sends
Sentry's Next.js options say that in SDK version 10, sendDefaultPii still controls automatic data collection unless you set dataCollection. dataCollection has been available since 10.57.0. Starting with version 11, those defaults apply even if you never set the option. The default they describe includes user identity, request and response bodies, and generative AI content, with values scrubbed when the key matches a built-in denylist (auth, token, password, and similar).
dataCollection.userInfo defaults to true. Sentry says that fills user fields such as id, email, username, and IP from instrumentation, and that data you set with Sentry.setUser() is always sent. httpBodies defaults to all body types. Set it to [] to turn body collection off. Query parameters and cookies are on by default, with sensitive names replaced by [Filtered]. dataCollection does not cover Session Replay. Replay has its own privacy options.
Their filtering page says beforeSend runs immediately before an error event is sent. Return the event to keep it, or null to drop it. Their example deletes event.user.email. Use that hook when a token, a raw request body, or an email can still sit on the event after the denylist. A denylist matches key names. It will not catch a secret stuffed into a free-text message.
Sentry.init({
dsn: "https://<key>@o<orgId>.ingest.sentry.io/<projectId>",
dataCollection: {
userInfo: false,
httpBodies: [],
},
beforeSend(event) {
if (event.user) {
delete event.user.email
}
return event
},
})That snippet is the shape of Sentry's docs, not a complete config. Put the same limits in the browser, server, and edge init files the wizard created. A server init that still uses the old default will keep sending what the browser init dropped.
Sample rates
Error events use sampleRate. Sentry's options page says the default is 1.0, so every error event is sent. 0.1 sends about one in ten, chosen at random.
Tracing is off until you set tracesSampleRate or tracesSampler. The number is from 0 to 1. The init samples on the Next.js and React pages set tracesSampleRate: 1.0 and say to reduce that in production. Replay in those samples is replaysSessionSampleRate: 0.1 and replaysOnErrorSampleRate: 1.0, and only if replayIntegration() is present. A generated app that copies the sample unchanged will send a trace for every request and a replay for every error. That is what the snippet does. Lower it when the project has real traffic, or you will pay for volume you did not mean to collect.
Releases and source maps
A release is the name Sentry uses to group events from one deploy. The options page says you set release in Sentry.init. On the server the SDK also reads SENTRY_RELEASE. In the browser it reads window.SENTRY_RELEASE.id when that exists. Sentry's releases page says that if you never create a release yourself, Sentry creates one the first time it sees an event with that identifier.
Source maps are how a minified stack becomes the file you wrote. The Next.js source maps page says a wizard install uploads them on next build, not on next dev. sourcemaps.deleteSourcemapsAfterUpload defaults to true, which deletes client source maps after upload. Server source maps are kept for runtime reporting. With Turbopack, that page says the upload happens after the build and needs @sentry/nextjs 10.13.0 or newer and Next.js 15.4.1 or newer. The manual path passes authToken: process.env.SENTRY_AUTH_TOKEN into withSentryConfig, plus org and project.
On Vite, set build.sourcemap and delete the maps after upload with sourcemaps.filesToDeleteAfterUpload, or block .map files on the host. Their Vite page says a public map can expose the original source. The same warning is why this site's free check looks for public source maps. That check does not set up Sentry, and it does not see a token that never reached the browser.
Put SENTRY_AUTH_TOKEN in the environment that runs the production build: the host's build settings, or CI. A local .env.sentry-build-plugin is for a build on your machine. It is not a substitute for the token on Vercel, Netlify, or whatever actually ships the app. If the org or project slug does not match the DSN's project, the maps upload to a different project than the errors, and the stack stays minified.
Get it into a builder project
Cursor, Claude Code, and Windsurf already have the repo. Run the wizard there, commit the SDK files, and set the auth token only on the build. Read the diff. The wizard edits next.config and adds several files. Confirm it did not commit .env.sentry-build-plugin.
Lovable and Bolt may not give you a shell for npx. Two paths still work. Edit the project in the builder and add the init files and the dependency by hand, using the manual setup for that framework. Or export or sync the project to GitHub, run the wizard in the clone, and push the result back or connect the repo to the host. Either way the DSN can live in the client environment. The auth token cannot. Builder secret stores that inject VITE_ or NEXT_PUBLIC_ names into the bundle are the wrong place for SENTRY_AUTH_TOKEN.
After the first production build, open the Sentry project and confirm an event arrived, then confirm the stack shows your file names rather than a single minified line. Sentry's Next.js page says an error thrown from the browser console is sandboxed and will not show up. Use a button in the app, or the example page the wizard can add, and remove that button before you share the URL.
Run a free passive check on the public URL when you are done. It looks at headers, a few common files, and keys in public scripts. It will not tell you whether Sentry is receiving events.
FAQ
How do I add Sentry to a Lovable app?
Use the project's code editor, or export or sync it to GitHub and run the command for the framework that project actually is. A Next.js app uses npx @sentry/wizard@latest -i nextjs. A Vite React app uses @sentry/react and, for source maps, npx @sentry/wizard@latest -i sourcemaps. Put the DSN where the client can read it. Put SENTRY_AUTH_TOKEN only in the build environment.
Is the Sentry DSN a secret?
Sentry's DSN page says it only submits events and does not grant read access. It can still be used to send junk events to your project. The auth token used to upload source maps is a secret. Sentry says to keep it out of version control and to set it in CI.
Do I still set sendDefaultPii?
On SDK version 10, sendDefaultPii is the old switch, and it applies when you do not set dataCollection. Current docs tell you to set dataCollection instead. Set userInfo to false and httpBodies to an empty list if you do not want inferred emails, IPs, and request bodies. Use beforeSend to delete anything that is still on the event, including event.user.email. Data passed to Sentry.setUser() is still sent.
Why is the stack trace one minified line?
The maps were not uploaded, they were uploaded to a different project than the DSN, or they were uploaded only from a local build and not from the build that shipped. next dev does not upload maps. The Vite plugin does not upload in watch mode. The auth token has to be present in the production build, and the org and project slugs have to match that DSN.
Sources
Checked 9 Nov 2026.
Informational only. This page describes checks and vendor documentation. It is not a security audit, a penetration test, or a certification, and it is not a guarantee.
Newsletter
A short weekly note on new tools and security checklists. No spam, unsubscribe anytime.