How Nightjar works

Most hosted-browser platforms run a browser in the cloud, and that browser can reach the public internet. Nightjar runs the browser in the cloud too — and then lets it reach your network: the dev server on your laptop, an office LAN, a CI runner, a staging VPC.

That inversion is the whole product, and everything below follows from it.

The inversion

The browser runs on Nightjar's infrastructure; its network egress can run through your machine.

A cloud browser is a real browser on Nightjar’s hardware. Your agent drives it remotely — navigating, perceiving the page, clicking, typing.

A tunnel daemon is a small process you run, inside a network you already control. It joins one of your networks and carries the browser’s traffic. The browser then reaches whatever that network reaches.

So an agent can open a localhost address and get the dev server running on your laptop — even though the browser is nowhere near it.

The seam

Every agent enters through the same door. There is no private entrance.

Agents talk to Nightjar over MCP (the Model Context Protocol) — an HTTPS endpoint your agent host points at, with a Bearer token. The Nightjar tools then appear in your agent: session_start, navigate, perceive, act, screenshot, and the rest.

The important part is a rule Nightjar holds itself to: the MCP server is the seam. Agents that Nightjar hosts are just MCP clients that happen to run on Nightjar’s infrastructure. They use the same tools you do.

That is a constraint, not a description. If Nightjar’s own agents needed private APIs, the promise that your agent needs zero Nightjar-specific code would already be broken.

Four doors

One system, four public surfaces.

Nightjar is reachable four ways, and they are deliberately the same system seen from different sides:

The MCP server — the primary seam, described above. This is the door agents use.

The REST and WebSocket API — the /v1 HTTP surface, described by an OpenAPI document that is generated from the Rust source rather than hand-written. The code is the contract; the specification is emitted from it.

The npm packages — a typed SDK for that API, generated API types, and the design system and component library the console is built from.

The executables — the CLI, the tunnel daemon you run in your own network, and the server-side binaries that host browsers and serve the control plane.

The console you log into is not a fifth thing. It is a client of the same /v1 API, built from the same published packages.

What crosses the seam

Three rules hold across every door. They are worth knowing because they are the same wherever you meet them.

Egress is a per-session decision

Every session chooses how its traffic leaves.

When you start a session you choose its egress mode:

platform — ordinary internet access from Nightjar’s infrastructure.
split — only the target you granted goes through your daemon; everything else stays on platform egress.
local — all the session’s traffic routes through your daemon. This one needs a stronger organisation policy, because it is the widest.

Split is the usual choice: it reaches your dev server without routing the rest of the web through your laptop.

Authority is a closed set of scopes

Every API key carries scopes, and the set of scopes is a fixed registry in the source rather than an open-ended string. Some are marked dangerous — reading a session’s clipboard, recording a session, writing keys, reaching into your own network, touching files in your consented workspace.

Two things follow that tend to surprise people:

A key that can drive a session cannot necessarily read files through it. Driving and file access are separate scopes, and a key holding only the first gets a 403.
The dangerous flag changes how a scope is presented, not whether a preset bundle may contain it. Read the bundle, not the flag.

Tokens say what they are

Nightjar’s token prefixes are a closed vocabulary — the prefix tells you what kind of credential you are holding before you use it. A key that drives sessions and a capability handed to a spawned child session are different things, and they never look alike.

Where to go next

The Glossary defines the individual terms used above.
Getting started walks through pointing an agent at the MCP endpoint.
Local reach covers running the daemon and granting it a target.
The API reference is the field-level contract for everything above.