Cloudflare 1-click install Planned

OAuth into Cloudflare. We provision a Worker on your zone that injects the message.com snippet into every HTML response, before </body>. Zero changes to your site code. Perfect for static sites, ancient CMSs, and anything you cannot easily edit.

How it works

1. You click Connect Cloudflare in our onboarding.
2. Cloudflare's OAuth flow asks for the scopes listed below.
3. You pick which zone (domain) to install on.
4. We deploy a tiny Worker, attach a route, and return you to the dashboard.
5. The widget appears on every HTML response served through Cloudflare.

Permissions we request

We ask for the minimum scopes required to deploy and manage the Worker. We do not request DNS, certificates, or page rules.

• Workers Scripts: write. To deploy and update the Worker.
• Workers Routes: write. To attach the Worker to the routes you choose (defaults to *your-domain.com/*, excluding common asset paths).
• Account.Zones: read. To list your zones so you can pick which to install on.

We never ask for DNS edit, SSL/TLS, or Worker KV scopes. We do not see your DNS records.

What the Worker does

The Worker uses Cloudflare's HTMLRewriter API to append a single <script> tag to the bottom of each HTML response. Non-HTML responses are passed through untouched. Static assets, JSON APIs, and images are not affected.

// What we deploy on your zone (open-source, audit-friendly)
export default {
  async fetch(req, env, ctx) {
    const res = await fetch(req);
    if (!isHtml(res)) return res;

    const rewriter = new HTMLRewriter().on("body", {
      element(el) {
        el.append(SNIPPET, { html: true });
      },
    });

    return rewriter.transform(res);
  },
};

The source is published in our public GitHub repo so you can audit exactly what gets deployed to your zone. See the Cloudflare HTMLRewriter docs for the API reference.

What we read and write

• The Worker never logs request bodies.
• The Worker never stores customer data.
• The Worker streams responses; it does not buffer them in memory.
• Our backend never receives raw request data from your zone. The Worker injects a script; the browser then connects to app.message.com directly.

Why no DNS touch

Many install paths require a CNAME or A record change. We do not. Your DNS stays untouched. We only attach a Worker to existing routes you authorise. This is also why uninstall is one click: removing the Worker route restores your origin behaviour byte-for-byte.

Performance impact

The Worker uses streaming HTMLRewriter, so it does not buffer the response. Added latency is typically under 5ms. Cloudflare runs the Worker at the edge nearest to the visitor, not at our origin.

Uninstall

From our dashboard, click Disconnect Cloudflare. We remove the Worker and the route in one call. Cloudflare logs the removal in your account audit log.

Common pitfalls

• Sites not on Cloudflare proxy (grey-cloud DNS) cannot use this. Switch the relevant record to orange-cloud first.
• Cloudflare Pages and Workers Sites route differently. Use the per-project install instead.
• Strict CSP headers may block the injected script. Allow app.message.com in your script-src directive.