Make changes on your live site

Revyse can open on your deployed site, not only on your machine. A member of your project opens the real site, on a laptop or a phone, taps what's wrong and says what they want. Revyse makes the change in the cloud: its own branch, your checks, a pull request and a preview. Your site changes only when the change ships, the way your project chose.

Your visitors get none of this. The script on your pages does nothing until a member of your project turns it on in their own browser.

An owner sets it up once per site.

On Next.js, npx revyse init does steps 1 and 2 for you. After it connects the app, it registers the site's addresses (the ones in appOrigins that aren't local, once you confirm them, or ones you type), moves them out of appOrigins, and adds the live option to withRevyse() as a diff you approve. It then lists what's left, with links: connecting the GitHub repository, and step 3 when your app sends a Content Security Policy. Run by someone who isn't an owner, it gives them the link to the Live site tab instead of registering.

You need

• The owner role in the project to set it up. After that, anyone in the project with the editor role or above can use it. Viewers can't.
• Cloud changes working for the project: its GitHub repository connected, and for previews, its Vercel project mapped (see the cloud quickstart). A change from the live site goes through the same cloud loop as one from the dashboard.
• The site served over https from a domain you control.

1. Register your site

In Revyse, open the project, then the Live site tab. Under Registered origins, add the site's origin: its scheme and host, like https://www.example.com, with no path.

• Register every origin people use: https://example.com and https://www.example.com are two different origins.
• There are no wildcards, so preview deployments (whose addresses change) can't open Revyse. Use Revyse in your local dev server, or the dashboard, for those.
• http works only for localhost.

2. Add the loader to your pages

The Live site tab shows your project's loader tag with its key filled in. Add it to every page, before </body>:

<script async src="https://revyse.dev/live.js" data-project="pk_live_…"></script>

data-project is the project's public key. It tells Revyse which project the site belongs to, and grants nothing.

On Next.js, if the app already uses withRevyse(), add the live option instead and redeploy. It adds the same tag to production builds and changes nothing in development:

export default withRevyse(nextConfig, { live: { projectKey: "pk_live_…" } });

With the Pages Router, the app needs a custom pages/_document.tsx (Next's default document is fine) for the tag to have somewhere to go.

3. Allow it in your Content Security Policy

If your site sends a Content-Security-Policy header, add the Revyse app to two of its directives, as the Live site tab shows:

script-src https://revyse.dev
connect-src https://revyse.dev

Add these to the directives you already have; don't replace them. If your site has no Content Security Policy, skip this step.

4. Open Revyse on your site

Two ways, both on the Live site tab or the site itself:

• From Revyse: press Edit live site. Your site opens with the overlay already signed in. The link carries a one-time code after the # in the address, which lasts a minute and is removed as soon as the page reads it.
• From your site: add #revyse to the address, for example https://www.example.com/pricing#revyse. A small Revyse sign-in window opens; once you're signed in, the overlay appears on the page. Bookmark that address to come back.

The overlay stays signed in on that browser, for that site, for 12 hours. To end it sooner, revoke the session on the project's Live site tab.

5. Ask for a change

1. Open the overlay with the button in the corner and choose Select an element.
2. Click the element on the page (on a phone, tap it). The page doesn't react while you select.
3. Say what should change, and send it. Revyse plans the change from your repository. You can attach a screenshot for whoever reviews it.
4. Read the plan, then Apply the change, or Revise it, or answer Revyse's question if it has one.
5. Revyse writes the change on its own branch, runs your checks, and opens a pull request. Revyse links to it, then to the preview once it's built.
6. The change ships the way your project chose: promoted from its page in Revyse, straight to production once the checks pass, or after your reviewers approve. Your site changes on its next deployment.

For now, a change ships from its page in Revyse, not from your site.

On a phone

• The overlay opens as a sheet from the bottom of the screen.
• Tap to select. Scrolling still works while you select; a tap chooses what it lands on.
• To sign in on the phone, open the site with #revyse, or open Edit live site from the Revyse dashboard on the phone.
• The site should set <meta name="viewport" content="width=device-width, initial-scale=1">. Next.js adds it for you. Without it, phones lay the page out at desktop width.

What your visitors get

Nothing. For anyone without a Revyse session in that browser, the loader makes no request to Revyse, changes nothing on the page, and loads nothing more. It is about 2 KB, loads without blocking the page, and if Revyse is unreachable it gives up quietly. Your site keeps working either way.

Who can see and use Revyse on your site

Only members of the Revyse project with the editor role or above, after they activate it in their own browser. Each session belongs to one person, one project and one site. On the Live site tab, owners see every active session and can revoke any of them. Everyone else sees their own.

What the overlay sends to Revyse when you ask for a change: the page's address, the element you selected (its tag, text, classes, where it sits on the page) and any screenshot you attach. It never sends what anyone typed into a form. See how Revyse handles your data.

Exact locations (optional, Next.js)

Without this step Revyse finds the file behind what you selected from the page, the element's text and where it sits. That works for most selections. With exact locations, the selection points Revyse at the exact line of JSX.

On Vercel, npx revyse init does all of this for you. It sets the build token on your Vercel project and shows two edits to approve: the option in next.config, and the upload in your build script. Elsewhere, or by hand:

1. On the Live site tab, under Exact locations, press Create a build token. Copy it now; it isn't shown again.

2. Where your site builds (on Vercel: the project's Settings → Environment Variables, for Production and Preview), add REVYSE_BUILD_TOKEN with that value.

3. Turn the option on: withRevyse(nextConfig, { live: { projectKey: "pk_live_…", locations: true } }).

4. Upload the build's locations after each build. On Vercel, set the build command to:

   next build && npx revyse live upload

   If your Vercel project sets its own Build Command, add the upload there too.

Your pages then carry short, meaningless ids (data-rv="…"), never a file name. Only Revyse, for a signed-in member of the project, can turn an id into a place in your code. If the upload fails, the deploy still goes ahead, just without exact locations (use --strict to fail it instead). Revyse keeps each build's locations for 90 days after its last upload.

Limits and switches

• Each member, and each site, has an hourly limit on requests from the overlay. It's far more than a person needs, and it stops a runaway script.
• Pausing the project (Settings → Controls) stops new sessions and new changes from the live site, as it does everywhere else. So does Revyse's own maintenance switch.
• Removing the loader from your pages removes Revyse from your site.

Troubleshooting