RightMessage
Security, performance & architecture

What RightMessage runs on your site, and what it can touch.

RightMessage adds one script to your pages. It runs with the same permissions as any other JavaScript you load, so you should know exactly what it does. Here’s what it can access, where your data goes, what it costs in performance, and what breaks when something fails.

Book a technical walkthroughSee the architecture

Last reviewed

Start here

The short version.

What runs on our site?

An async script delivered from Cloudflare’s global network. It isn’t sandboxed. Like any script in your <head>, it can read and change your page.

The details

Where does our data go?

Three separate paths: script delivery on Cloudflare, analytics to a separate ingestion service, and form submissions to our integration API, which calls your email platform.

The details

Who holds our email platform credentials?

RightMessage does, on its servers. They’re used by the integration API and aren’t part of the script your visitors download.

The details

Will it slow our pages?

It loads async, compiles per project, and caches script revisions for a year. It still runs on the main thread, so measure it on your own templates.

The details

What if RightMessage is down?

If the script can’t load, your page renders without it. If a form can’t reach your email platform, the visitor sees an error and can try again.

The details

Can we undo a change?

Changes are drafts until someone publishes. You can preview on your live pages, restore an earlier published version, or remove the snippet.

The details
1. What runs on your page

One script, with the same access as the rest of your JavaScript.

Installing RightMessage means pasting a short snippet into your <head>. It adds one async script tag for your project’s script and two small style rules. Those rules hide only elements you’ve explicitly marked as conditional, so they don’t flash before the script picks a version. They’re removed when the script is ready, when it fails to load, or after 20 seconds.

What the script does

  • Changes the headlines, copy, images and calls to action you target in the visual editor.
  • Renders forms, popups, quizzes and flows directly into your page’s DOM.
  • Reads the page URL, UTM parameters and referrer to match campaigns and segments.
  • Stores a visitor identifier and campaign context in first-party storage on your domain.
  • Sends analytics events and form submissions to RightMessage.

What that means for your review

  • It isn’t sandboxed. The script runs in your page’s JavaScript context and can read the DOM, including other form fields, like any script you load. We don’t use iframes or shadow DOM to fence it off.
  • Your published project is public. Copy, targeting rules and form setup ship in a JavaScript file anyone can fetch, so don’t put anything secret in campaign content. IP-based analytics exclusions are the exception: they’re kept out of the public file.
  • Publish access is site access. Anyone who can publish your RightMessage project can change what visitors see, and the optional custom JavaScript features can run code on your pages. Grant it the way you’d grant CMS access.

If you run a Content Security Policy

  • script-src: the RightMessage script host from your install snippet, plus a nonce or hash for the inline snippet itself.
  • connect-src: the RightMessage endpoints for analytics events, contact lookups and form submissions. Email hello@rightmessage.com and we’ll send the current list.
  • style-src: the snippet adds an inline style element and the script injects style elements for its widgets, so your policy has to allow them.
  • 'unsafe-eval' is only needed if you use the after-submit JavaScript hook or code steps in flows. If your policy forbids it, leave those two features off.
  • Roll the policy out in report-only mode on a few pages first, and read the violations before you enforce it.
2. Where each job runs

Three jobs, three separate paths.

The script your visitors download, the analytics it sends, and the form submissions it makes each go somewhere different. None of them sits in front of your website.

Standard RightMessage installation topologyYour website or CDN serves HTML that includes the RightMessage snippet to the visitor's browser. The script runs in your page with the page's own permissions. From the browser, three separate paths leave: 1, script delivery from RightMessage's Cloudflare Workers and R2 storage; 2, analytics events to an event ingestion Worker that writes to Elasticsearch for reporting; 3, form submissions and contact lookups to the integration API in RightMessage's Laravel Cloud data environment, which calls your email platform or CRM with credentials stored server-side. The data environment and the control environment, which runs the dashboard, API, publishing and background workers, share a managed MySQL database and Valkey cache on a private network.YOUR INFRASTRUCTUREYour website & CDNServes your HTML with the snippetHTML + snippetVISITOR'S BROWSERYour page + RightMessage script• Personalizes elements you target• Renders forms, popups and flows• Reads URL, UTMs and referrer• Stores a first-party visitor ID• Sends events and form dataSame access as your page. Not sandboxed.OPERATED BY RIGHTMESSAGECLOUDFLAREScript deliveryWorkers + R2: a loader plus immutableper-project script revisionsEvent ingestionPage, campaign, flow and conversioneventsElasticsearchReporting data. Not a lead queue.LARAVEL CLOUDDATA ENVIRONMENTIntegration APIForm submissions, contact lookupsCONTROL ENVIRONMENTDashboard & APIPublishing, MCP, background workersShared MySQL + ValkeyPrivate network, shared by bothenvironments. Credentials for yourconnected tools are stored here.YOUR TOOLSEmail platform or CRMCalled with your stored credentials123

Standard installation. Dashed outlines are ownership boundaries. Your site serves its own HTML; RightMessage never proxies it.

  • 1 Script delivery
  • 2 Analytics
  • 3 Leads and lookups
  • Your HTML and internal links
1

Script delivery

Your script is delivered from Cloudflare’s global edge network. When you publish, RightMessage compiles a script for your project and stores it in Cloudflare R2 as an immutable revision, and Cloudflare Workers serve it close to each visitor, along with a small loader that tells browsers which revision is current. Nothing is generated per page view.

2

Analytics

Page views, campaign and form views, flow answers and conversions go to a separate ingestion Worker on Cloudflare, which writes them to Elasticsearch for reporting. This path measures. It never delivers a lead.

3

Leads and contact lookups

Form submissions and contact lookups go to our integration API on Laravel Cloud. It calls your email platform or CRM with the credentials you connected and returns the result to the browser.

What’s separated, and what’s shared

The integration API runs in its own Laravel Cloud environment. The dashboard, public API, MCP server, publishing and background workers run in a second one, so dashboard load doesn’t compete with your visitors’ form submissions for compute.

Separate workloads, shared storage. Both environments are deployed from the same commit and share a managed MySQL database and Valkey cache on a private network. That’s workload separation, not full fault isolation: a database or cache problem affects both. Traffic between browsers, RightMessage and connected platforms uses HTTPS.

3. What happens to a lead

What happens when someone fills out a form.

Here’s the path a signup takes. Every email platform and CRM follows the same shape: the browser talks to RightMessage, and RightMessage talks to your email platform or CRM.

Lead delivery and visitor recognitionAn unknown visitor submits a RightMessage form. The browser sends the fields to RightMessage's integration API and waits for the answer. The integration API uses the stored credentials for your connected email platform or CRM to add the subscriber, tags and fields. If it accepts the request, a first-party visitor ID is stored in that browser and the visitor is recognized, so tags and fields can drive targeting, for example an upgrade offer instead of the signup form. If the call fails, the form shows an inline error, keeps the answers and lets the visitor submit again; nothing retries automatically, and support can replay the logged request once the cause is fixed. Separately, a subscriber who clicks an identifying link in your email is looked up through the integration API and recognized. Analytics events travel on a separate path to event ingestion and Elasticsearch and never deliver a lead.FORM SUBMISSIONUnknown visitorSees your signup form or quizSubmits the formBrowser sends fields and waitsRIGHTMESSAGEIntegration APIUses your stored credentialsYour email platform or CRMAdds the subscriber, tags, fieldsAcceptedVisitor ID storedin this browserFailsInline error,answers kept,visitor can retry.Logged for replay.Recognized visitorTags and fields from your email platformcan drive targeting, e.g. an upgradeoffer instead of the signup form.IDENTIFYING EMAIL LINKClicks an identifying email linkSome platforms add it automaticallyAPI looks up the contactin your connected email platformAnalytics travel separatelyPage views, form views and conversionsgo to event ingestion and Elasticsearchfor reporting. That path neverdelivers a lead.

The upgrade offer is an illustrative example of what a recognized visitor could see instead.

  • Lead delivery
  • Recognized visitor
  • Failure path
  • Analytics only

Who counts as a known visitor

A visitor becomes known only after an identification event: a RightMessage form submission, a supported third-party form the script can detect, a click on an identifying link in your marketing email, or an email query parameter. Being on your list doesn’t make a browser recognizable by itself.

After that, the browser is remembered through first-party storage until it’s cleared. Another device stays anonymous until it’s identified too. Tags, fields and purchase data from your email platform apply only after identification, and only when that integration is on your plan.

What gets logged, and what support can replay

Requests to the integration API are logged with what was sent, how your email platform responded, the status and the timing. Those logs contain what visitors submitted. That’s what makes them useful: if your email platform rejected or missed submissions, our support team can find the recorded requests and resend them once the cause is fixed.

That’s a support process, not automatic delivery. Nothing retries in the background, there’s no exactly-once guarantee, and the analytics pipeline isn’t a backup copy of your leads.

4. Performance cost

What it costs your page, and how to measure it.

How it loads

  • The snippet is a few lines of inline code. The script it adds is async, so it downloads without blocking HTML parsing.
  • Every publish compiles a minified script for your project that includes only the runtime modules your configuration uses.
  • Compiled revisions live at immutable URLs that browsers and Cloudflare’s global network can cache for a year. The small loader revalidates in the background, and an uncached revision check confirms which revision is current.
  • If that check takes more than 3 seconds or fails, the browser runs the revision it already has.
  • Only elements you mark as conditional are hidden while the script loads. The snippet never hides the whole page.

What it still costs

  • The script downloads, parses and runs on the main thread, alongside your own JavaScript. The more campaigns, flows and widgets your project has, the more work it does.
  • Personalization applied in the browser happens after first paint, so visitors can briefly see your original content. Edge addresses that for server-rendered HTML.
  • Popups and inline forms add DOM. An inline form placed without reserved space can shift the layout.
  • Expect a handful of requests: the loader, the revision check, the script revision, analytics events, and integration calls when someone is identified or submits a form.

Measure it on your own pages

We don’t publish a script size or benchmark, because both depend on what’s in your project. Here’s how we’d measure it:

  1. 1Pick two or three representative templates, such as your homepage, a landing page and an article.
  2. 2Compare LCP, INP, CLS and Total Blocking Time with and without the snippet under the same conditions: throttled lab runs, plus your real-user monitoring if you have it.
  3. 3In the network panel, record each RightMessage request, its size, and whether repeat views come from cache.
  4. 4Profile main-thread work on a mid-range phone, not just a developer laptop.
  5. 5Repeat after you add campaigns.
5. When something fails

What breaks when something fails, and what doesn’t.

Your site staying up, RightMessage’s widgets showing, and a lead reaching your email platform are three different things. Here’s how each one behaves.

The RightMessage script can’t load (blocked, network or CDN problem)

What visitors see

Your page renders without RightMessage. The snippet removes its hide rules when the script errors. If the script hangs instead of failing, anything you marked as conditional stays hidden until it arrives or 20 seconds pass.

What happens to leads

No RightMessage forms appear, so nothing is submitted through them.

The revision check is slow or fails

What visitors see

After up to 3 seconds, the browser runs the script revision it already has instead of waiting.

What happens to leads

Unaffected.

Analytics ingestion is slow or down

What visitors see

Nothing visible. Personalization and forms don’t wait on it.

What happens to leads

Unaffected. Reports can be incomplete for that period.

The integration API or your email platform fails the request

What visitors see

The form shows an inline error, keeps what they typed, and lets them submit again. It isn’t counted as a conversion and the flow doesn’t move on.

What happens to leads

Not delivered unless the visitor resubmits. The request is logged, and support can replay it once the cause is fixed.

RightMessage’s shared database or cache has a problem

What visitors see

Published scripts keep coming from Cloudflare storage, not the application. Contact lookups and anything that needs the integration API can fail.

What happens to leads

Form submissions can fail and show the error above. The dashboard is affected too.

6. How changes are controlled

Every change is a draft until someone publishes it.

Your changes

  • Edits save as drafts. Nothing reaches visitors until someone publishes.
  • Preview drafts on your real pages with a preview link before you publish.
  • Each publish creates a new immutable script revision. From publish history, you can restore an earlier published version into your draft and publish it again.
  • On Pro, built-in A/B testing can hold back a percentage of matched visitors on your original page.
  • To switch RightMessage off completely, remove the snippet. The standard installation doesn’t change your stored HTML, so your pages go back to exactly what your server sends.

Our releases

  • Production releases run only after automated checks pass for the release commit: linting, type checks, static analysis, and front-end, browser and back-end test suites, either on the pull request or in the release run itself.
  • Both Laravel Cloud environments are deployed from the same exact commit, one after the other, and the release is promoted only after both succeed. That isn’t an atomic switch, so database migrations are written to stay backward-compatible during the gap.
  • A published script revision never changes after it’s published. Built dashboard assets are stored per build and checksum-verified.
7. RightMessage Edge

Change the HTML before it reaches the browser.

The standard installation changes your page after the browser starts painting it, so visitors can briefly see the original version. RightMessage Edge is an optional, open-source way to apply supported campaigns to the HTML before the response reaches the browser.

This isn’t the same as our script delivery. RightMessage already serves its script from Cloudflare’s global network, but that sits beside your site, not in front of it. Edge is different: you deploy it in your own request path, on infrastructure you control.

Standard installation

Request path with the standard browser installationThe browser requests your page and your server or CDN returns the original HTML. The browser paints the original page first, so visitors can see the default version. The RightMessage script then downloads asynchronously and runs, applies personalization, which can show as a flash of original content, and renders forms, popups and flows. You deploy only the snippet, with no DNS, CDN or hosting changes.Browser requests your pageYour server or CDN returns the original HTMLBrowser paints your original pageVisitors can see the default versionRightMessage script loadsDownloads async, then runsScript applies personalizationThe swap can show as a flashForms, popups and flows renderAnalytics events are sent separatelyWhat you deployOnly the snippet. No DNS, CDN or hostingchanges.FIRST PAINT

With Edge on Cloudflare

Request path with RightMessage Edge on CloudflareThe request reaches an Edge Worker you deploy on your own Cloudflare zone, in front of your origin. The Worker fetches your origin HTML and loads the published plan with a 300 millisecond default deadline. Supported campaigns are applied to the HTML and the response is marked private. The browser's first paint already includes the change. The RightMessage browser script still loads for forms, popups, analytics and browser-only rules. If the plan is missing, late or invalid, or the transform fails, the Worker returns your origin HTML unchanged.Request reaches your Edge WorkerOn your Cloudflare zone, in front of originWorker fetches your origin HTMLLoads the published plan (300 ms deadline)Campaigns applied to the HTMLSupported targets only; response is privateBrowser paints personalized HTMLFirst paint already includes the changeRightMessage script still loadsForms, popups, analytics, browser-only rulesFallback: your origin HTML, unchangedIf the plan is missing, late or invalid, or thetransform failsFIRST PAINT

The “first paint” marker shows when visitors first see the page relative to the change.

  • Browser script
  • Changed before paint
  • Original content visible
  • Fallback
Standard installation compared with RightMessage Edge
QuestionStandard installationWith Edge
What you deployThe snippet in your <head>The snippet, plus an Edge integration you run in your request path
DNS, CDN or hosting changesNoneCloudflare adapter: your DNS proxied through Cloudflare and a Worker on your route. Next.js adapter: no DNS change, but it runs inside your Next.js app.
When the page changesAfter the browser starts paintingBefore the HTML leaves the edge (Cloudflare adapter)
What it can changeAnything the script can reach in the DOMSupported campaign targets in server-rendered HTML
If something goes wrongYour original page showsYour origin HTML is returned unchanged

What ships today

  • Cloudflare Worker. Runs on your Cloudflare zone and rewrites qualifying HTML responses with Cloudflare’s HTMLRewriter. It needs your DNS proxied through Cloudflare, a Worker on your route, and a Workers paid plan.
  • Next.js. Middleware on Next.js 15 or proxy on Next.js 16 that hands campaign decisions to your server components. It doesn’t rewrite HTML; your app renders the chosen variant.
  • Other CDNs. The engine and adapters are open source, so they can be adapted to other CDN platforms that run edge workers.

If the published plan is missing, invalid or misses its 300 ms default deadline, or the HTML transform fails, the Worker returns your origin HTML unchanged. If your origin itself fails, that error passes through. Personalized responses are marked private and no-store, so shared caches don’t serve one visitor’s version to another.

What Edge doesn’t do

  • Change content your own JavaScript inserts after load, or the inside of a cross-origin iframe.
  • Run every campaign. Rules only the browser can evaluate stay with the browser script.
  • Look up contacts in your CRM. It uses request signals such as the URL, UTMs and referrer, plus context the browser script has already stored in a first-party cookie.
  • Replace the browser script. You still need it for forms, popups, analytics and browser-only rules.
  • Cover client-side navigation. Route changes inside a single-page app don’t pass through the Worker.
Read how Edge worksrightmessage/edge on GitHubrightmessage/edge-cloudflare on GitHubrightmessage/edge-nextjs on GitHub
Boundaries

What this page doesn’t promise.

For data processing terms, see our data processing agreement and privacy policy.

  • A security certification or audit report. This page describes how the platform works. It isn’t an attestation.
  • An uptime SLA, or specific backup, retention, region or failover commitments.
  • A fixed script size or benchmark. It depends on your project, so measure it.
  • Guaranteed or exactly-once lead delivery. Failures show up for the visitor and support can replay logged requests, but nothing is silently queued.
  • Flicker-free personalization everywhere. Only supported campaigns on server-rendered HTML can change before first paint, and only with Edge.
FAQ

Questions security reviewers ask.

Is the RightMessage script sandboxed?+

No. It runs in your page’s JavaScript context with the same access as any other script you load, and it renders forms and popups into your page rather than an iframe. Treat it the way you’d treat any third-party tag in your <head>, and give publish access in RightMessage the way you’d give CMS access.

Can RightMessage read what visitors type into our other forms?+

The script technically can, like any script on your page. By default, RightMessage identifies visitors from its own forms, supported third-party forms the script can detect, identifying email links, and email query parameters. Email Watcher is an optional setting that picks up email addresses submitted through other forms on the site; it’s off unless you turn it on.

Do we need to move our DNS or CDN to Cloudflare?+

No. The standard installation is the snippet in your <head>, and RightMessage delivers its script from its own Cloudflare setup. Only the optional RightMessage Edge Cloudflare adapter needs your DNS proxied through Cloudflare, because it runs in front of your site.

Where are our email platform API keys stored?+

On RightMessage’s servers. The integration API uses them to call your email platform when a form is submitted or a contact is looked up. They aren’t included in the script your visitors download.

Can we run RightMessage with a strict Content Security Policy?+

Usually, with allowances. You’ll need to allow the RightMessage script host and the endpoints it calls, the inline install snippet, and the style elements it injects. The optional after-submit JavaScript hook and code steps in flows need 'unsafe-eval'; if your policy forbids that, don’t use those two features. Test in report-only mode first.

How do we A/B test the impact safely?+

Use built-in A/B testing on the Pro plan to hold back a percentage of matched visitors on your original page. Compare your conversion goal within that same audience before rolling the change out to everyone.

Got a question this page doesn’t answer?

Forward this page to whoever has to approve the script. If they want to go deeper, we’ll walk an engineer through your setup.

Book a technical walkthroughEmail hello@rightmessage.com