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

Most teams first hit the limits of Headless Chrome in the cloud through cost and flakiness, not features: multi‑second cold starts, high memory peak per instance, and brittle pooling logic. Lightpanda Cloud flips that model by charging on a simple “browser-hours + concurrent sessions” basis, with a machine‑first browser that starts instantly and uses ~9× less memory than Chrome in our own 100‑page Puppeteer benchmark on an AWS EC2 m5.large.

This page walks through where to find Lightpanda Cloud pricing, how browser-hours are counted, how concurrency limits work, and how to choose the right plan for your workload.

Where to find Lightpanda Cloud pricing

You can always see live, up‑to‑date pricing on the main site:

Go to https://lightpanda.io
Navigate to the Pricing section from the top navigation
Or go directly from docs/console links that point to the same pricing table

You’ll see three plans:

Explorer – free, for testing and small workloads
Builder – paid, for production automation and agent runs
Enterprise – custom, for high volume and advanced security/compliance needs

The numbers below match what’s in the pricing table at the time of writing; the website is the source of truth for any changes.

Current Lightpanda Cloud plans at a glance

Explorer (Free)

Price: $0 / forever
Included usage:
- 10 browser-hours per month
- 5 concurrent sessions
Support: Community (Discord)
Network: Bring your own proxy

Explorer is designed to let you prove to yourself that a machine‑first browser is faster and leaner than your current Headless Chrome setup, without changing your stack: connect via CDP from Puppeteer, Playwright, or chromedp, run your usual scripts, and compare timings and memory externally.

Builder (For production workloads)

Price: $19 / month
Included usage:
- 300 browser-hours per month
- 30 concurrent sessions
Overage: $0.08 per additional browser-hour
Support: Email + Slack
Network: Bring your own proxy

Builder is the default choice for most production crawlers, QA suites, and AI agent runners. It gives you enough hours and concurrency to move real workloads while still keeping the model simple: you pay for actual browser execution time, not instance uptime or idle capacity.

Enterprise (High volume & advanced requirements)

Price: Contact us
Included usage: Custom volume pricing (browser-hours + concurrency negotiated to fit your scale)
Support & guarantees:
- Dedicated support
- SLA and uptime guarantees
- On premise or private cloud options
- Options for advanced security needs (more isolation, custom networking, stricter data handling)

Enterprise is for teams running at a scale where a few percentage points of cold‑start overhead or memory peak translate to real cloud spend and operational risk. If you’re orchestrating thousands of browser sessions per minute across regions, we’ll align browser‑hours and concurrency limits with your traffic patterns and risk model.

How browser-hours work in Lightpanda Cloud

Browser-hours are the primary unit you’re billed on. Conceptually, they measure how long browser instances are actually running, not how long your account exists or how many tokens you have configured.

What counts as a browser-hour?

At a high level:

Each browser session you start in Cloud (via a CDP WebSocket connection) consumes time while it is alive and connected.
We sum that usage across all your sessions, then convert it into hours.

Because Lightpanda is built from scratch for machines—with instant startup and no rendering overhead—the actual billable time is dominated by your script’s work, not multi‑second spin‑ups or UI subsystems that you never use in headless mode.

Common examples:

A single Puppeteer script connects to Lightpanda Cloud, opens a page, does some interactions, then closes:
- If the session is live for 30 seconds, that’s ~0.0083 browser-hours.
A test runner spawns 20 parallel sessions, each running for 3 minutes:
- 20 sessions × 3 minutes = 60 minutes total = 1 browser-hour.

The key idea: we account for wall-clock time per running browser, aggregated across all sessions.

How concurrency limits work

Concurrency limits cap how many browser sessions you can have running at the same time. They don’t affect how many total hours you can consume in a month; they shape the parallelism of your workload.

Concurrency by plan

Explorer: up to 5 concurrent sessions
Builder: up to 30 concurrent sessions
Enterprise: negotiated, often significantly higher, with room for region splits and isolation requirements

If you hit your concurrency ceiling:

New sessions will fail to start until some existing sessions close, or
Your orchestrator (queue, scheduler) should back off and retry later

This is intentional. Without concurrency limits, a bug in your job runner can spin up thousands of sessions and effectively DDOS targets or surprise you with one massive billing spike. Concurrency caps give you a hard safety rail around burn rate and traffic volume.

How browser-hours and concurrency interact

Think of these as orthogonal controls:

Browser-hours = how much work you do in total
Concurrency = how fast you do that work in parallel

Examples:

Slow and steady crawler
- 5 concurrent sessions, each running ~12 minutes at a time
- You can run 25 such batches in a month before exhausting 300 browser-hours on Builder:
  - 5 sessions × 12 min × 25 batches = 1500 minutes ≈ 25 hours (so actually far below your cap)
- Here, concurrency is the limiter (how quickly you process the queue), not hours.
High‑throughput test runner
- 30 concurrent sessions, each running 2 minutes
- Full burst for 1 hour: 30 × 2 min × 30 rounds ≈ 1800 minutes = 30 browser-hours
- You’re under the 300-hour cap, but using your concurrency fully during test windows.
Migration from Chrome farm
- You previously had 10 Chrome containers, each with high overhead.
- With Lightpanda’s instant startup and low memory peak, you can often match throughput with fewer concurrent sessions, or increase throughput at the same concurrency with lower cost.

As you scale, you tune both:

Increase browser-hours when your aggregate monthly work grows.
Increase concurrency (or upgrade to Enterprise) when you need shorter wall-clock completion time for large jobs.

How to choose the right plan based on your workload

Use your existing automation metrics as a baseline: number of sessions per month, average session duration, and desired parallelism.

When Explorer is enough

Explorer (10 browser-hours, 5 concurrency) is usually sufficient when:

You’re validating Lightpanda against your current Headless Chrome flows.
You’re running small internal tools, admin dashboards, or low-volume agents.
Your sessions are short (seconds to a couple minutes) and infrequent.

If you’re hitting “concurrency limit reached” or running out of hours mid‑month, that’s your signal to move to Builder.

When Builder is the right default

Builder (300 browser-hours, 30 concurrency, $19/month + $0.08/hr overage) fits if:

You run daily or continuous scraping, testing, or agent workloads.
You want a predictable baseline bill with room for spikes.
You’re replacing a homegrown Chrome farm and want to compress cost and operational noise.

A rough order-of-magnitude guide:

If you run 30 concurrent sessions for 30 minutes per day, every day:
- 30 sessions × 0.5 hours × 30 days = 450 browser-hours
- This fits Builder with ~~150 hours of overage at $0.08/hr (~~$12 extra), still simple and cheap compared to infrastructure + management for Chrome.

If you don’t know your exact patterns yet, starting on Builder and watching usage for a month is usually the fastest feedback loop.

When Enterprise makes sense

Enterprise is worth it when:

Your workloads regularly exceed Builder’s 300 hours and 30 concurrency by a large margin.
You need SLA and uptime guarantees for customer-facing automation.
You have strict data, security, or residency requirements and want on premise or private cloud deployment.
You want to coordinate concurrency caps, region topology, and cost ceilings with us directly.

With Enterprise, we treat browser-hours and concurrency as tunable primitives in your architecture, not just a pricing table row.

Practical tips for staying efficient with browser-hours

Even with a much faster, leaner browser, good hygiene keeps your bills predictable and your targets safe.

Close sessions cleanly
- Always call browser.close() (or equivalent) in your Puppeteer/Playwright/chromedp scripts.
- Don’t leave stale connections open “just in case”; they keep consuming browser-hours.
Use parallelism intentionally
- Increase concurrency only as far as your target sites and network can handle.
- Remember: a machine‑first browser makes it easy to go very fast; that also means you can overload targets if you’re careless.
Respect robots.txt and rate limits
- Configure your crawlers to obey robots.txt (with Lightpanda’s --obey_robots flag on the OSS side when you’re testing locally).
- Avoid very high request frequencies on small sites; an accidental DDOS is still possible, just faster.
Benchmark against your Chrome baseline
- Run the same 100‑page flow against both Headless Chrome and Lightpanda Cloud.
- Compare:
  - Total execution time
  - Peak memory per session (via your orchestrator metrics)
  - Cloud infra cost (if you’re still paying for Chrome containers)
- Often you can either reduce concurrency for the same throughput or cut wall‑clock time at the same concurrency, both of which shape how many browser-hours and sessions you need.

How to get started and see your usage

Create or sign in to your account
- Go to https://console.lightpanda.io
- Sign in with your email and token.
Pick a plan
- Start on Explorer if you’re just testing.
- Upgrade to Builder when you’re ready to run real workloads.
Connect via CDP
- Use the Cloud CDP endpoints (for example, wss://euwest.cloud.lightpanda.io/ws or wss://uswest.cloud.lightpanda.io/ws, depending on your location and region choice).
- In Puppeteer/Playwright/chromedp, swap your browserWSEndpoint / endpointURL to point to Lightpanda. The rest of your script can remain the same.
Monitor browser-hours and concurrency usage
- Use the console to inspect recent sessions and get a feel for your typical session length and parallelism.
- Adjust your scheduler to stay within the limits you’re comfortable with.

Summary

You can view the most up‑to‑date Lightpanda Cloud pricing directly on https://lightpanda.io, where you’ll see the Explorer, Builder, and Enterprise plans. Pricing is based on browser-hours (total time your headless browser sessions are running) and concurrency limits (how many sessions you can run in parallel).

Explorer: 10 browser-hours, 5 concurrent sessions, free forever.
Builder: 300 browser-hours included for $19/month, then $0.08/hr, with 30 concurrent sessions.
Enterprise: custom browser-hours and concurrency, with SLAs and options for on premise or private cloud.

Under the hood, Lightpanda’s machine‑first browser gives you instant startup and a much lower memory footprint than Chrome, so most of your billed browser-hours go into actual work, not overhead. If you want to see this in your own environment, you can connect your existing CDP tooling to Lightpanda Cloud and start measuring within a few minutes.

Get Started