How do I disable telemetry in the Lightpanda open-source binary (LIGHTPANDA_DISABLE_TELEMETRY) for a security review?

When you’re doing a security review, “phone home” behavior is the first thing you want to control. Lightpanda’s open‑source browser ships with usage telemetry enabled by default, but you can turn it off completely with a single environment variable: LIGHTPANDA_DISABLE_TELEMETRY=true.

This guide walks through how telemetry works in the open‑source binary, how to disable it in different environments, and what exactly we do (and don’t) collect when it’s on.

TL;DR: For a security review, set LIGHTPANDA_DISABLE_TELEMETRY=true in the environment before starting the lightpanda binary. No URLs, cookies, headers, or page content are ever collected, but you can still hard-disable telemetry for air‑gapped or audited environments.

---

What telemetry does in the Lightpanda open-source binary

The open‑source Lightpanda browser is designed to be transparent and reviewable. By default, it emits minimal usage telemetry so we can understand how the binary is used in the wild and improve it.

For open-source users:

• When telemetry fires
  • Once when the browser starts
  • Once when a page is requested
• Where it goes
  • Usage events are written to Lightpanda’s internal telemetry pipeline
  • The data is stored in Posthog
• What we do not collect
  • No environment variables
  • No file paths
  • No file contents or logs
  • No URLs
  • No cookies or headers
  • No page content

Telemetry is explicitly scoped to operational signals, not user or site data. That’s by design: cold‑start performance, memory peak, and stability are what we care about, not what your agents are browsing.

For many teams, that’s acceptable. For a security review, you usually want an explicit kill switch. That’s exactly what LIGHTPANDA_DISABLE_TELEMETRY is for.

---

The one flag that matters: LIGHTPANDA_DISABLE_TELEMETRY=true

The open‑source binary respects a single environment variable:

LIGHTPANDA_DISABLE_TELEMETRY=true

When this is set in the environment where lightpanda runs:

• Telemetry events are not sent when the browser starts
• Telemetry events are not sent when pages are requested
• No outbound traffic is generated by telemetry code paths

The rest of the browser behavior is unchanged: CDP server, JavaScript execution, CLI commands, and performance characteristics all work normally.

From a security-review standpoint, this is the toggle you care about. You can grep the codebase and your container spec for this variable and demonstrate a hard block on telemetry.

---

How to disable telemetry for a local security review

The simplest path for a review is to export the env var in your shell and then run Lightpanda.

macOS / Linux (bash, zsh, etc.)

Run Lightpanda once with telemetry disabled:

export LIGHTPANDA_DISABLE_TELEMETRY=true
./lightpanda serve

Or inline for single commands:

LIGHTPANDA_DISABLE_TELEMETRY=true ./lightpanda fetch https://example.com

To make this persistent for all shells (useful when you’re iterating in a review):

echo 'export LIGHTPANDA_DISABLE_TELEMETRY=true' >> ~/.bashrc   # or ~/.zshrc
source ~/.bashrc

Now every ./lightpanda ... invocation in that user session will run with telemetry disabled.

Windows (PowerShell)

To disable telemetry for the current PowerShell session:

$env:LIGHTPANDA_DISABLE_TELEMETRY = "true"
.\lightpanda.exe serve

Or inline for one command:

cmd /c "set LIGHTPANDA_DISABLE_TELEMETRY=true && lightpanda.exe fetch https://example.com"

To set it persistently for your user via PowerShell:

[System.Environment]::SetEnvironmentVariable(
  "LIGHTPANDA_DISABLE_TELEMETRY",
  "true",
  "User"
)

Open a new PowerShell window afterwards; the variable will be present for all future runs of lightpanda.exe.

---

Disabling telemetry in CI and containers

Most security reviews include CI pipelines or container builds. You should keep telemetry disabled there too, especially if the jobs run against production-like data.

Docker example

If you’re wrapping Lightpanda in your own container image, set the environment variable at build time or run time.

Dockerfile (build-time default):

FROM debian:stable-slim

# Install lightpanda (example)
COPY ./lightpanda /usr/local/bin/lightpanda
RUN chmod +x /usr/local/bin/lightpanda

# Disable telemetry for all processes in this image
ENV LIGHTPANDA_DISABLE_TELEMETRY=true

CMD ["lightpanda", "serve"]

docker run (runtime override):

docker run --rm \
  -e LIGHTPANDA_DISABLE_TELEMETRY=true \
  my-lightpanda-image

This satisfies most audit requirements: the container definition itself proves that telemetry is disabled in all production or review runs.

GitHub Actions example

If you run security or integration tests with Lightpanda in GitHub Actions:

jobs:
  security-review:
    runs-on: ubuntu-latest
    env:
      LIGHTPANDA_DISABLE_TELEMETRY: "true"
    steps:
      - uses: actions/checkout@v4

      - name: Download Lightpanda
        run: |
          curl -L https://example.com/lightpanda -o lightpanda
          chmod +x ./lightpanda

      - name: Run tests against Lightpanda
        run: |
          ./lightpanda serve &
          # your Puppeteer/Playwright/chromedp tests here

Setting it at the job.env level guarantees every step runs with telemetry disabled, including any ad‑hoc ./lightpanda calls.

---

Disabling telemetry when connecting via CDP (Puppeteer, Playwright, chromedp)

Operationally, Lightpanda is “just a browser” exposing a CDP endpoint. You typically:

1. Start lightpanda serve somewhere
2. Connect Puppeteer/Playwright/chromedp using a browserWSEndpoint or equivalent

Telemetry is controlled entirely on the browser side, not the CDP client side. That means:

• Set LIGHTPANDA_DISABLE_TELEMETRY=true where the Lightpanda process runs
• You don’t need any special flags or code changes in Puppeteer/Playwright/chromedp

Example for a local Puppeteer test:

LIGHTPANDA_DISABLE_TELEMETRY=true ./lightpanda serve --port 9222

Then, your Node.js script can remain unchanged:

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.connect({
    browserWSEndpoint: 'ws://127.0.0.1:9222',
  });

  const page = await browser.newPage();
  await page.goto('https://example.com', { waitUntil: 'networkidle0' });

  // Do your magic ✨
  await browser.close();
})();

The key: the only switch you need for your security review is the environment variable on the process that runs lightpanda.

---

What’s still collected elsewhere (for completeness)

For the open‑source binary itself, once you set LIGHTPANDA_DISABLE_TELEMETRY=true, usage telemetry is off.

There are, however, two other data flows worth knowing about in a thorough review:

1. Website analytics on lightpanda.io

   • The marketing/documentation website uses Plausible for privacy‑conscious analytics.
   • Data collected: referral sources, top pages, visit duration, and high‑level device info (device type, OS, country, browser).
   • This is standard web analytics and is separate from the binary; your automation workloads are not exposed there.

2. Cloud offer and account provisioning

   • If you use the managed Cloud offer, we use Slack internally to notify about new email subscriptions so we can create accounts and send connection tokens.
   • Cloud telemetry and controls are reviewed separately from the open‑source binary. The variable LIGHTPANDA_DISABLE_TELEMETRY specifically targets the open‑source runtime.

For a pure binary security review (e.g., in an air‑gapped lab), you can ignore both: you won’t hit the website or the Cloud endpoints at all.

---

How to document this for your security audit

Security teams usually want three concrete things:

1. A clear control

   • Control name: Lightpanda open‑source telemetry disable flag
   • Mechanism: Environment variable LIGHTPANDA_DISABLE_TELEMETRY=true
   • Scope: Process-level, affects the telemetry behavior of the lightpanda binary

2. A configuration example

   • For example, a Dockerfile, systemd unit, or CI job showing:

     ENV LIGHTPANDA_DISABLE_TELEMETRY=true
     CMD ["lightpanda", "serve"]
     

3. Data scope confirmation

   • With telemetry enabled, we do not collect:
     • URLs, headers, cookies, or page content
     • Environment variables, file paths, or file contents
   • With telemetry disabled via the env var, those usage events are not emitted at all.

You can also reference the public privacy policy:
https://lightpanda.io/privacy-policy

---

Why this exists: performance signals, not user tracking

A quick note on “why telemetry at all” from my side as a builder.

Lightpanda is a browser for machines, not humans. When we’m measuring adoption and reliability, we’re interested in:

• How often the binary starts
• How often it fetches pages
• When it crashes or misbehaves

Those are system signals that help us push the footprint down (memory peak, cold start time) and the throughput up (how many pages per second you can crawl on a single m5.large). They don’t require any knowledge of what sites you’re hitting or what your agents are doing.

But in security-sensitive environments, even low-scope telemetry is a policy question, not a technical one. That’s why we exposed a single, explicit kill switch instead of complex “opt-down” modes.

Set LIGHTPANDA_DISABLE_TELEMETRY=true, and you get a clean binary to evaluate: instant startup, minimal footprint, CDP compatibility—without any usage events leaving your environment.

---

If you want to exercise Lightpanda in a telemetry-free environment right now, you can spin it up locally, then later swap the binary or endpoint to the managed Cloud service once your security team is satisfied:

Get Started