Lightpanda enterprise: how do I contact sales about SLA, private deployment/on-prem, and security requirements?

If you’ve reached the point where uptime guarantees, private deployment, and security posture matter more than raw experimentation, you’re exactly the kind of team we built Lightpanda Enterprise for. At that stage, “just run more Headless Chrome containers” stops working: cold starts stack up, memory peaks blow up your node density, and shared state becomes a security problem instead of a convenience.

This page walks through how to contact us about SLAs, on‑prem / private cloud deployment, and advanced security requirements—and what to include in your message so we can give you a concrete, technical response instead of sales fluff.

Quick Answer: Email hello@lightpanda.io with your SLA, deployment, and security requirements. That inbox goes directly to the founding team (Selecy SAS) and is the fastest way to start an enterprise discussion.

How to contact Lightpanda sales for enterprise discussions

We keep the contact path simple on purpose: no opaque forms, no SDR maze.

Primary contact channel (fastest)

Email: hello@lightpanda.io
Company: Selecy SAS
Address (legal):
Selecy SAS
8 rue du faubourg Poissonnière
75010 Paris
France

This is the right channel if you want to discuss:

SLA and uptime guarantees
On premise or private cloud deployments
Advanced security and isolation features
Proprietary licensing on top of the open‑source core

We read that mailbox ourselves and route you directly to the right person (usually me or our CTO) instead of pushing you through a generic ticket queue.

What to include in your email (so we can move fast)

If you want to get from intro → concrete proposal quickly, include these details in your first message to hello@lightpanda.io.

1. SLA & reliability requirements

Tell us what “reliable” actually means for your workload:

Availability targets:
- e.g., “99.9% monthly uptime” or “we need a hard 99.95% SLO for CDP endpoints”
Regions & latency:
- Which regions you care about (e.g., EU West, US West)
- Latency expectations if you’re connecting from a specific cloud region
Peak & steady‑state usage:
- Estimated concurrent sessions or pages/minute
- Typical session duration (seconds vs minutes)
Failure budget:
- Is a failed session acceptable if it can be retried within X seconds?
- Are you running transactional workflows where retries are sensitive (e.g., checkouts, booking flows)?

This helps us map you to the right deployment shape (Cloud with regional CDP endpoints vs. dedicated cluster vs. on‑prem install) and define realistic SLAs.

2. Deployment model: Cloud, private, or on‑prem

Lightpanda’s core browser is open source and can always be run locally, but enterprise conversations are usually about where and how it runs at scale. In your email, specify which of these you’re exploring:

Managed Cloud (multi‑tenant, but isolated sessions)
- You connect over Chrome DevTools Protocol (CDP) via ws:// or wss:// endpoints.
- You authenticate using a tokenized WebSocket URL.
- You keep your existing clients (Puppeteer, Playwright, chromedp).
- SLAs cover Cloud uptime and endpoint availability.
Private cloud (your VPC, our software)
- Lightpanda deployed into your AWS/Azure/GCP VPC or private cloud.
- You keep data plane traffic inside your own network boundary.
- We handle updates, operational hardening, and SLAs on the software.
- Good fit if you have strict data residency or vendor access rules.
On premise deployment
- Lightpanda deployed on your own infrastructure, sometimes air‑gapped.
- You might need:
  - Custom rollout & upgrade pipelines
  - Internal-only CDP endpoints
  - Integration with your existing logging/metrics stack
- For this path, explicitly mention “on premise deployment” or “proprietary licensing” in your email. As our docs state, if you require on‑prem or multi‑context tabs / sandboxing, contact us at hello@lightpanda.io.

The more precise you are about your environment (cloud provider, regions, Kubernetes vs bare metal, typical node size), the easier it is for us to propose a concrete architecture.

3. Security, compliance, and isolation needs

Lightpanda’s entire design is about running machine-first automation safely at scale. For an enterprise review, tell us:

Data classification and sensitivity
- Are you touching PII, finance, healthcare, or internal systems?
- Do you have constraints like “no logs may contain URLs,” or “no CPU profiles can be exported off-cluster”?
Isolation requirements
- Do you require:
  - Per-session isolation (no shared cookies/sessions)
  - Multi-context tabs with strict boundaries
  - Sandboxing of different tenants or business units
- Our enterprise features include multi-context tabs and sandboxing; if that’s at the top of your list, call it out explicitly.
Compliance & audit expectations
- Which frameworks matter: SOC 2, ISO 27001, HIPAA, internal security review only?
- Any specific logging, audit, or key management requirements?
Network & access controls
- Need egress control via proxies (--http_proxy or enterprise proxy configuration)?
- Restricted destination lists / allowlists?
- Requirements around IP rotation vs fixed IPs?

Put this in bullets in your email. That lets us respond with equally specific answers: how Lightpanda handles isolation, what telemetry exists, and how we can align with your controls.

How Lightpanda Enterprise differs from just running Chrome yourself

If you’re contacting us about SLAs and private deployment, you already know the pain of scaling legacy headless browsers in the cloud. For context you can share internally:

Chrome wasn’t built for the cloud
It carries decades of UI and rendering baggage into your automation tasks. That’s fine on a developer laptop, but it’s wasteful and brittle when you’re spinning up thousands of headless sessions remotely.
Cold starts are a product bug, not a side effect
Multi‑second startup latency compounds across concurrent sessions. If every new automation task has to pay a 2–5 second boot penalty, your infrastructure either:
- runs hot with long‑lived browsers (risking state leakage and security issues), or
- spends a fortune on overprovisioned compute to compensate.
Memory peaks kill density and drive cost
Large, UI-focused browser processes limit container density. At scale, that’s the difference between tens and hundreds of concurrent sessions per node.

Lightpanda is a headless‑first browser built from scratch in Zig, with no rendering overhead and a minimal runtime footprint. It still executes JavaScript via V8-based runtime dependencies and supports real‑world Web APIs, but it doesn’t drag a GUI engine into your automation cluster.

In our own benchmark—Puppeteer, 100 pages, AWS EC2 m5.large—Lightpanda showed:

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

Enterprise matters here because once you align on SLAs and security, those numbers translate directly into:

Higher session density per node
More predictable latency
Lower cloud spend per workflow

How adoption works with your existing stack

When you talk to us about SLA and deployment, a big part of the conversation is about not rewriting everything you already have.

Lightpanda exposes a Chrome DevTools Protocol (CDP) server. In practice, that means:

Your Puppeteer, Playwright, or chromedp code can keep using the same browserWSEndpoint / endpointURL patterns.
You connect via ws:// or wss:// using a tokenized URL from Lightpanda Cloud or your private deployment.
The rest of your script largely remains the same—selectors, navigation, waits, etc.

In your email, it helps to tell us:

Which automation framework(s) you use now
Any custom CDP clients or in‑house tooling
Whether you also need Chrome fallback for specific edge sites

We’re explicit about this: our Cloud positioning includes “Lightpanda innovation, Chrome reliability”. For rare cases where a site needs full Chrome, we can design a hybrid that still centralizes control and telemetry while letting Lightpanda take the bulk of the workload.

Telemetry, privacy, and responsible automation

If your security team is involved, they’ll ask two questions right away: “what telemetry exists?” and “how do we run this safely at scale?”

Telemetry and opt‑out

Lightpanda is transparent about data practices in our privacy policy.
Telemetry can be disabled via the environment variable:
```
LIGHTPANDA_DISABLE_TELEMETRY=true
```
Include in your email if you require this as a default in your deployment.

We’ll walk your security team through exactly what’s collected (and what isn’t), plus how to configure or disable it in enterprise setups.

Responsible automation guidance

In both open-source and enterprise contexts, our stance is:

Respect robots.txt where appropriate.
- CLI flag: --obey_robots to enforce it.
Avoid high-frequency requesting that could degrade a site.
- Lightpanda can be very fast; without rate controls, accidental DoS is possible.
Tune concurrency consciously based on target site capacity and your business context.

If you’re designing a crawler or agent platform, mention that in your email so we can suggest defaults and safety rails that align with your risk tolerance.

Example email you can copy-paste

Here’s a minimal template you can adapt and send to hello@lightpanda.io to start the enterprise conversation:

Subject: Lightpanda Enterprise – SLA, private deployment, and security

Hi Lightpanda team,

We’re evaluating Lightpanda for [brief use case: crawling, QA automation, agents, etc.] and would like to discuss an Enterprise agreement covering:

- SLA: [e.g., 99.9% uptime, target regions, latency expectations]
- Deployment: [Lightpanda Cloud / private cloud in our VPC / fully on premise]
- Scale: [estimated concurrent sessions, pages per day, average session duration]
- Stack: [Puppeteer / Playwright / chromedp / custom CDP client]
- Security: [data classification, isolation needs like sandboxing or multi-context tabs, compliance constraints]

We’d appreciate:
- Details on your SLA and uptime guarantees
- Options for on premise or private cloud deployment
- Information about telemetry, logging, and how to disable or restrict them
- Any documentation you can share for a security & architecture review

Thanks,
[Name]
[Role]
[Company]
[Region / Cloud provider]

Send that to hello@lightpanda.io and we’ll typically respond with:

Proposed architecture for your scale and deployment model
SLA options (and what we can realistically guarantee)
Security notes covering isolation, telemetry, and data flows
Next steps for a technical deep‑dive or trial

Final verdict: when it makes sense to talk to sales

You should reach out to hello@lightpanda.io about enterprise if:

You’re running or planning large‑scale automation (crawlers, QA, agents) where cold starts and memory peaks from Chrome are now a cost line item.
You need formal SLA & uptime guarantees rather than best‑effort GitHub support.
Your security team requires on premise or private cloud deployment, or advanced isolation features like sandboxing and multi-context tabs.
You want a browser built for machines, not humans, with the numbers to back it (instant startup, ~11× faster execution, ~9× less memory vs Headless Chrome in our benchmark), but without rewriting your CDP‑based tooling.

When that’s your situation, an email to hello@lightpanda.io is the quickest way to move from “we’re testing this” to “this is a reliable part of our infrastructure.”

Get Started