Can I audit a Vercel preview deployment today?

Yes, manually: run rowshield probe against the preview URL for the outside-in view, and rowshield scan against whichever database the preview's environment points at for the catalog view. The planned integration would automate the trigger, not invent new checks.

Are preview environments really worth scanning?

Often yes — they routinely share databases with production, carry test copies of real data, and receive less review than any other deploy. A preview leaking behaves identically to production leaking, from the outside.

When will the preview integration ship?

No date is promised, and this page deliberately avoids predicting one. Everything described as shipped elsewhere on the page — the CLI, the probe, scheduled scans — is available now.

Guides

Auditing preview deployments: the plan, and today's practice

Preview deployments are where environment discipline quietly loosens. Each preview gets its own set of variables, often pointing at a shared or branch database, and the surface it exposes can differ from production in ways nobody reviewed — a new table wired up early, a bucket policy adjusted for testing, a privileged key pasted into the wrong pane.

A planned RowShield integration would treat previews as first-class scan targets: when a preview URL exists, probe its public surface and report findings against the same rules as production. That integration is not shipped, no date is promised, and this page promises nothing on its behalf. What follows is why previews deserve auditing and how to check them today with shipped commands.

RowShield does not detect this yet. This guide gives you the catalog queries to check it yourself. The nine rules that do ship are listed on the rules index.

Why previews are worth auditing

The risk model of a preview differs from production in one important direction: attention. Production receives reviews, alerts and habits accumulated over months; previews get built quickly, shared loosely in a pull-request thread and forgotten for weeks with a database still attached to them.

Three concrete patterns account for most preview trouble. Environment variables pointing every preview at one shared database, making an experiment a production event. Test data seeded from real tables, giving the preview the sensitivity of production with none of its protection. And credentials placed in client-reachable variables during debugging, shipping the service_role key into browser code where any visitor can read it.

What the planned integration would do

The design sketch is deliberately small. On a deployment event for a preview URL, run the probe — the same outside-in check used everywhere else, issuing GET, HEAD and OPTIONS only and refusing private network ranges before connecting. Report anonymously-readable tables and browser-exposed privileged keys against the same severities as a production finding, labelled with the preview's origin.

Catalog-level scanning of preview databases raises questions the sketch leaves open — which database counts as the preview's, who owns the credential, how long results persist — and those questions are why the feature remains planned rather than rushed. Nothing here commits dates or behaviour.

Checking a preview today

Both shipped commands apply to a preview immediately, with nothing to wait for and nothing preview-specific to learn first. The probe takes any reachable URL you control and needs only what a visitor already has — the preview hostname included:

For the catalog half of the picture, point the CLI at whichever database the preview's environment variables hold — using a dedicated read-capable role rather than a privileged one — and read through the findings together with their generated fixes afterwards:

# Outside-in check of the preview's public surface
rowshield probe https://my-pr-142.example.vercel.app

# Catalog check of the database the preview points at
rowshield scan --db-url "$PREVIEW_DATABASE_URL" --fail-on high --sql
# exit 0 = clean, 1 = findings at/above threshold, 2 = broken run

Planned, plainly

Restating the standing sentence so it cannot be missed: preview auditing is a planned capability, described here so the practice can start today rather than at some promised date — no dates are given, and the design may change before anything arrives.

Until the trigger exists, the burden of remembering belongs to your release habits, which is worth knowing before adopting previews heavily. Meanwhile scheduled scans keep production watched continuously, and the free audit at rowshield.dev/audit accepts any project URL you control, preview or otherwise — paste the address, read what an anonymous caller sees.

Frequently asked

Can I audit a Vercel preview deployment today?: Yes, manually: run rowshield probe against the preview URL for the outside-in view, and rowshield scan against whichever database the preview's environment points at for the catalog view. The planned integration would automate the trigger, not invent new checks.
Are preview environments really worth scanning?: Often yes — they routinely share databases with production, carry test copies of real data, and receive less review than any other deploy. A preview leaking behaves identically to production leaking, from the outside.
When will the preview integration ship?: No date is promised, and this page deliberately avoids predicting one. Everything described as shipped elsewhere on the page — the CLI, the probe, scheduled scans — is available now.

Check your project in about ten seconds

Paste a URL. No signup, no writes, nothing stored.

Run the free audit