Install yourself or with your coding agent

Installation guide

Start in your website project. Your agent prepares the changes; you approve access and decide what goes live.

1. Inspect the project

   Read its repository instructions. Identify the framework, existing analytics, consent manager and release process. If Relentless is already present, inspect that installation before adding anything. Preserve existing tracking and unrelated work. Identify the regions served, including UK and EEA, from existing approved project information. Keep unknown regions unknown and resolve them before collection review; they do not prevent inert preparation. The site owner owns visitor-facing privacy content and chooses the default per region. Relentless tracks every visitor by default with an opt-out, and requires a prior opt-in only for EU/EEA visitors. Use the site’s permission signal without injecting legal copy or a banner.

2. Connect the right website

   When the required setup capabilities are available, the owner opens website setup, signs in using an available option, and selects or adds the website. Confirm its exact address and environment. Keep development and production separate. Never ask the owner to paste sign-in links, session cookies or private account credentials into the agent.

3. Verify website control

   When verification is available, use Create verification file in website setup and give the agent the generated verification instructions. Prepare only that file at the supplied address. Publishing it follows the project’s normal review and explicit deployment approval. The owner then uses Verify file. An expired challenge needs a new file; website verification alone does not enable capture or grant consent.

4. Get the website’s installation package

   When preparation downloads are available, use Prepare your installation, select candidate static public pages and the intended release, then choose Download installation package. Share that download with the agent. Read its RELENTLESS_INSTALL.md and manifest to identify the package; the button label is not proof that capture is ready. Keep an unknown release explicitly unknown.

   A preparation package says capture_ready:false and contains a data-only bootstrap and inert relay. It has no SDK, recorder or forwarding handler. Follow its guide to prepare a small change and PR; do not add event listeners, wire consent or mount ingestion. Missing consent or capture permission does not block this inert preparation. It cannot collect events and is not a verified installation.

   Collection needs a separate, grant-backed capture package and review. Do not invent a package, SDK or endpoint when a download is unavailable. An existing issued package may still be prepared within its instructions; otherwise record the service blocker and the project findings.

5. Review any later capture integration

   Running the installation prompt in an authorised coding agent permits preparation of the issued package and its pull request. Inert preparation cannot become capture merely by changing a flag. It does not provide visitor consent or authorise activation. Initial analytics must exclude session replay, DOM capture, form entries and all tax or protected data. If the issued package cannot enforce an approved non-form event contract, keep capture disabled. Replay-capable code may ship, but disabled replay must not collect or transmit payloads. Require signed current per-site configuration, account-owner enablement and the site’s capture-permission signal before collection. Make the smallest compatible change. Keep server files and private credentials out of browser assets. Bind the existing permission signal; do not add a banner or fake an EU/EEA opt-in in code. Keep sensitive pages excluded and test masking, navigation and removal. Run the project’s checks. A refusal, or no choice from an EU/EEA visitor, must block capture, and withdrawal must stop it. Obtain approval before deploying or enabling visitor capture.

6. Check what actually arrived

   After separate activation approval, verify synthetic non-form events for the actual website, release and issued package. Inspect what was sent and stored, including logs and reports. Keep the event receipt and evidence that excluded information never arrived. Do not use session replay to prove installation. If the package or verification flow requires replay, keep capture disabled and report that mismatch. A download or script tag is not proof of success.