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

Most security reviews start with a simple question: what leaves the box, and can I turn it off? With the Lightpanda open-source binary, the answer is straightforward—yes, you can fully disable telemetry with a single environment variable: LIGHTPANDA_DISABLE_TELEMETRY=true.

This guide walks through exactly how telemetry works in the open-source browser, how to disable it across environments, and what’s collected (and explicitly not collected) by default so you can document your findings for a security or compliance review.

---

What Lightpanda telemetry does in the open-source binary

By default, the open-source Lightpanda browser sends minimal usage telemetry so we can understand how it’s used and improve the project.

For the open-source browser specifically:

• What triggers telemetry:

  • Starting the browser
  • Requesting a page

• What we don’t collect (by design): Telemetry does not include:

  • Environment variables
  • File paths
  • File contents
  • Logs
  • URLs
  • Cookies
  • Headers
  • Page content

• Where it goes:

  • Lightpanda uses an internal database to store telemetry before forwarding it.
  • We use Posthog to store and analyze telemetry data.

If your org has a “no outbound telemetry” policy or you’re doing a locked-down security review, you can disable this completely with an environment variable.

---

The one switch that matters: LIGHTPANDA_DISABLE_TELEMETRY=true

Telemetry for the open-source binary is controlled by a single environment variable:

LIGHTPANDA_DISABLE_TELEMETRY=true

When this variable is set in the environment where ./lightpanda runs, telemetry is disabled. No telemetry events are sent when the browser starts or when pages are requested.

From a security-review standpoint, you can treat this as the canonical kill switch.

---

How to disable telemetry on Linux and macOS

One-off terminal session

If you’re doing a hands-on review and running Lightpanda directly in a shell:

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

• export makes the variable available to the process.
• Any Lightpanda command in that shell (fetch, serve, CDP server, etc.) will run with telemetry disabled.

Inline for a single command

If you prefer not to modify your shell environment:

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

This only affects that one invocation and leaves your shell environment untouched.

Systemd service (for long-running CDP servers)

If you run Lightpanda as a systemd service for your automation workers:

[Unit]
Description=Lightpanda headless browser

[Service]
ExecStart=/usr/local/bin/lightpanda serve
Environment=LIGHTPANDA_DISABLE_TELEMETRY=true
Restart=always

[Install]
WantedBy=multi-user.target

Then:

sudo systemctl daemon-reload
sudo systemctl restart lightpanda.service

This ensures every Lightpanda process spawned by systemd runs with telemetry disabled.

---

How to disable telemetry on Windows

PowerShell (current session)

In PowerShell:

$env:LIGHTPANDA_DISABLE_TELEMETRY = "true"
.\lightpanda.exe fetch https://example.com

• This sets the variable for the current PowerShell session.
• Any subsequent Lightpanda commands in that session will run with telemetry disabled.

PowerShell (permanent user environment)

To persist this for your user:

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

Then restart your terminal or services that depend on it.

CMD (single session)

If you’re using classic Command Prompt:

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

This only affects the current CMD session.

---

Disabling telemetry in Docker-based setups

A lot of teams run headless browsers inside containers. The same env var works there.

Docker CLI

docker run --rm \
  -e LIGHTPANDA_DISABLE_TELEMETRY=true \
  ghcr.io/lightpanda/lightpanda:latest \
  fetch https://example.com

docker-compose

services:
  lightpanda:
    image: ghcr.io/lightpanda/lightpanda:latest
    environment:
      LIGHTPANDA_DISABLE_TELEMETRY: "true"
    command: ["serve", "--port", "9123"]

Any automation framework connecting to that containerized CDP server (Puppeteer, Playwright, chromedp) benefits from telemetry being disabled at the browser level.

---

Verifying telemetry is disabled for a security review

Most auditors want observable proof, not just a config snippet. Here are practical ways to verify:

1. Inspect environment from the browser process

On Linux/macOS:

ps aux | grep lightpanda
# Note the PID, say 1234
tr '\0' '\n' < /proc/1234/environ | grep LIGHTPANDA_DISABLE_TELEMETRY

Expected output:

LIGHTPANDA_DISABLE_TELEMETRY=true

If it’s missing, the environment variable wasn’t applied to that process.

2. Run behind an outbound firewall or proxy

If you have egress logging:

• Run Lightpanda once without the env var, capture outbound connections.
• Run again with LIGHTPANDA_DISABLE_TELEMETRY=true.
• Confirm that telemetry-related outbound traffic disappears in the second run.

This pattern is often sufficient for internal security documentation.

---

Open-source binary vs Cloud: telemetry and account-related data

This article focuses on the open-source binary you run yourself.

For clarity during a review:

• Open-source binary:

  • Telemetry controlled by LIGHTPANDA_DISABLE_TELEMETRY=true.
  • Uses Posthog + internal storage.
  • Does not collect URLs, cookies, headers, or page content.

• Cloud offer:

  • Separate telemetry and account flows.
  • We use Slack to notify about email subscriptions and to create/send your connection token when you sign up.
  • Network surface and data model are different from the local binary.

If your security review is strictly about the open-source binary, you can explicitly scope it to the env-var-controlled telemetry described here.

---

Why we made telemetry disablement a first-class switch

I previously ran scraping infrastructure across millions of pages per day. At that scale, “small” observability hooks inside tools can quickly become privacy and compliance liabilities if they’re not explicit and controllable.

With Lightpanda, we treat two things as non-negotiable:

1. Machine-first performance:
   The browser is built from scratch in Zig, headless-only, no rendering overhead. In our own Puppeteer benchmark (100 pages on an AWS EC2 m5.large), we measured:

   • ~2.3s vs 25.2s execution time (≈11× faster)
   • ~24MB vs 207MB memory peak (≈9× less)

2. Operator control:
   Cold-start time and memory peak are tunable product features. Telemetry lives in the same category—you should be able to hard-disable it in one step, bake it into your images, and document it for your security team.

LIGHTPANDA_DISABLE_TELEMETRY=true is how we encode that stance: one visible, auditable switch, no hidden behavior.

---

Summary: what to document for your security review

If you’re writing up findings for “how do I disable telemetry in the Lightpanda open-source binary (LIGHTPANDA_DISABLE_TELEMETRY) for a security review?”, you can summarize:

• Telemetry is enabled by default in the open-source binary.
• It is fully disabled by setting LIGHTPANDA_DISABLE_TELEMETRY=true in the browser’s environment.
• When disabled:
  • No telemetry events are sent at startup or on page requests.
• Even when enabled, telemetry does not include:
  • Environment variables, file paths, file contents, logs, URLs, cookies, headers, or page content.
• Telemetry is stored via an internal database and Posthog.
• The switch works uniformly across:
  • Local shells (Linux/macOS/Windows)
  • System services (systemd)
  • Containers (Docker/Docker Compose)
• You can verify the setting via:
  • /proc/<pid>/environ (Linux)
  • Egress firewall/proxy logging

Once you’ve wired LIGHTPANDA_DISABLE_TELEMETRY=true into your runtime (CI, containers, or orchestration layer), you can proceed with your review knowing the browser will not emit telemetry.

---

Next step

If you want to test Lightpanda with telemetry disabled in your own stack, you can get started and wire it into your existing CDP clients (Puppeteer, Playwright, chromedp) using a simple browserWSEndpoint switch:

Get Started