Where can I see Lightpanda Cloud pricing, and how do browser-hours and concurrency limits work?

Most teams first hit our Cloud pricing page when a Puppeteer or Playwright farm starts getting expensive, or cold-start latency from remote Headless Chrome eats their budget. Lightpanda Cloud is priced to reward efficiency: you pay for browser hours, and you’re capped by concurrent sessions, not by “projects” or “sites.”

Below is how to find current pricing, and exactly how browser-hours and concurrency limits work in practice.

Note: Details here reflect the current plans, but the source of truth is always the live pricing page.

Where to see current Lightpanda Cloud pricing

You can always see up‑to‑date pricing and plan limits on the main site:

Go to https://lightpanda.io
Navigate to the Cloud or Pricing section
You’ll see the three plans:
- Explorer (free)
- Builder (paid, fixed price + metered overage)
- Enterprise (custom)

Those pages are the canonical reference for:

Monthly included browser hours
Concurrency limits (max parallel browser sessions)
Overage rate per extra browser hour on paid plans
What kind of support and deployment options each plan gets

If you’re already a user, you can also:

Sign in to the console at https://console.lightpanda.io
Review your recent sessions and usage
Monitor how close you are to your hour and concurrency ceilings

Plans at a glance

Here’s the current structure of Lightpanda Cloud plans:

Explorer – “Test the performance yourself”
- Price: $0 / forever
- Included: 10 browser hours / month
- Concurrency: 5 concurrent sessions
- Support: Community (Discord)
- Proxy: Bring your own proxy
Builder – “For production workloads”
- Price: $19 / month
- Included: 300 browser hours / month
- Overage: $0.08 / extra browser hour
- Concurrency: 30 concurrent sessions
- Support: Email + Slack
- Proxy: Bring your own proxy
Enterprise – “For high volume usage and advanced requirements”
- Price: Contact us
- Included: Custom volume, negotiated
- Concurrency: Custom, negotiated
- Support: Dedicated support, SLA and uptime guarantees
- Deployment: On premise or private cloud options
- Security: Advanced security needs, isolation, etc.

Everything else in this article explains how these “browser hours” and “concurrent sessions” behave when you actually wire Lightpanda into Puppeteer, Playwright, or your own CDP client.

How browser-hours work

What is a “browser hour”?

A browser hour is one hour of an active browser session in Cloud.

When you connect to a Lightpanda Cloud endpoint (e.g. wss://euwest.cloud.lightpanda.io/ws) and a browser instance spins up, usage starts counting.
When that browser session is closed, usage stops.

If a session runs for 2.3 minutes, you’re billed for 2.3 minutes of browser time, not a whole hour chunk. Hours are aggregated across all sessions during the month.

Simple mental model

Think of browser-hours as:

sum of (end_time - start_time) for all Cloud browser sessions this month

Examples:

1 session, open for 1 hour → 1 browser hour
10 sessions, each open for 6 minutes → 10 × 0.1 = 1 browser hour
100 sessions, each open for 30 seconds → 100 × (0.5 / 60) ≈ 0.83 browser hours

Lightpanda’s whole premise is that you can finish work faster (instant startup, ~11× faster 100‑page run vs Headless Chrome on an EC2 m5.large) with ~9× less memory. That means:

Less time per session
More pages crawled / tested / visited per browser hour

You’re not paying to keep a heavyweight UI browser idle in the background.

What happens when you hit included hours?

On Explorer: you have 10 browser hours. When you hit that, new sessions may be blocked until your next monthly cycle. This plan is meant for evaluation and low-volume experiments.
On Builder:
- You get 300 browser hours included.
- After that, each additional browser hour is billed at $0.08/hour.
- You can keep running; your workload doesn’t suddenly stop because you crossed 300 hours.

On Enterprise, the volume, overage structure, and any caps are negotiated, typically aligned with your expected monthly agent/crawler/test workloads.

How concurrency limits work

What does “concurrent sessions” mean?

Concurrency is the maximum number of browser sessions you can have open at the same time in Cloud.

Explorer: up to 5 concurrent sessions
Builder: up to 30 concurrent sessions
Enterprise: defined by your contract

If you try to spin up more sessions than your concurrency limit:

Additional connection attempts can be throttled, rejected, or queued (depending on the orchestration on your side and any future platform behavior).
The simplest pattern: you enforce concurrency from your own app (job queue, worker limits) so you never exceed your plan’s caps.

Concurrency vs browser-hours

These two dimensions interact but are distinct:

Browser-hours = how long you run sessions
Concurrency = how many at once you’re allowed

You can run:

1 session for 300 hours (low concurrency, high hours)
30 sessions for 10 hours each, all in parallel (max concurrency, same 300 hours)
Many short-lived sessions in bursts as long as you never exceed your concurrent cap

Example on Builder:

If you run 30 sessions in parallel, each lasting 2 minutes:
- 30 × (2 / 60) = 1 browser hour consumed
- Concurrency = 30 (you’re at your limit, but not exceeding)
If you run 60 sessions in parallel:
- You’re trying to exceed your 30-session cap
- You need to queue or stagger them to stay within the limit

From a systems perspective, I strongly recommend you design your workers with an explicit concurrency limit (30 for Builder, 5 for Explorer) and treat Lightpanda like any other capped external resource.

How this maps to your automation patterns

Crawling and scraping

If you’re scraping millions of pages a day, you typically care about:

Page throughput per hour
Memory peak per container
Cold-start overhead of each browser

Lightpanda is built exactly for that:

Purpose-built headless engine (no rendering baggage)
V8-based JS runtime and Web APIs for real sites
Instant startup and low memory

On Builder (300 browser hours + 30 concurrency), typical patterns:

Run 30 workers, each holding a browser session and cycling through pages
Respect robots.txt and moderate your request rate
Avoid high-frequency requesting; with a fast engine, DDOS is easy to do by accident

Because sessions are cheaper (in time and memory), you can:

Keep them shorter for isolation and safety
Or keep them long-lived if you want to amortize connection overhead

Either way, you’re controlling browser-hours via session lifetimes and concurrency via worker count.

AI agents and LLM tools

For AI agents that open pages via CDP:

Each agent → typically one browser session
Parallel agents → concurrency

On Builder, 30 concurrent sessions is usually plenty for:

A fleet of agents that each intermittently browse
Training or evaluation runs where you batch tasks through a worker pool

If you need continuous, high-concurrency agent workloads (hundreds or thousands of parallel sessions), that’s where Enterprise and private deployments become relevant.

About Cloud endpoints, sessions, and tracking

In Cloud, you connect to regioned CDP endpoints:

wss://euwest.cloud.lightpanda.io/ws
wss://uswest.cloud.lightpanda.io/ws

You use your token when connecting, and each browser session started through those endpoints counts toward:

Your browser-hours
Your concurrency limit

Lightpanda uses Posthog to track Cloud usage:

We send your IP and a unique Lightpanda token identifier when you create a new browser session.
Retention matches your active subscription and legal obligations.
For local, open-source usage, you can opt out of telemetry with:
```
export LIGHTPANDA_DISABLE_TELEMETRY=true
```

The Cloud browser itself remains the same engine: headless-first, minimal footprint, wired to CDP so your existing Puppeteer/Playwright/chromedp code can connect without rewrites (swap the browserWSEndpoint, keep the rest of the script).

Choosing the right plan based on hours and concurrency

Use this as a quick decision frame:

Explorer
- You’re testing Lightpanda’s speed and footprint against Headless Chrome.
- You don’t yet have production traffic.
- 10 browser hours and 5 concurrency is enough to benchmark a few realistic workloads.
Builder
- You’re running production crawlers, tests, or AI agents.
- You want predictable cost (flat monthly + cheap overage).
- 300 browser hours and 30 concurrency matches small-to-mid scale cloud automation.
Enterprise
- You’re operating at large scale (hundreds+ concurrent sessions, thousands of hours).
- You need:
  - Volume pricing aligned with your load
  - SLAs and uptime guarantees
  - On-prem or private cloud deployments
  - Advanced security isolation and compliance

If you’re unsure, start with Explorer to validate performance and integration, then move to Builder as soon as you have a recurring workload.

Next step

If you want a browser actually designed for machine workloads—not a UI browser repurposed for the cloud—Lightpanda Cloud gives you that with transparent pricing and simple limits.

Get Started