# Agent and browser testing

> Point Playwright, Puppeteer, or an LLM browser agent at a stable HTTPS origin.

Automated browsers behave most like production when they hit a real HTTPS origin.
routeup gives your dev server one, locally or publicly.

## In-process test runners

When the test runner is on the same machine (Playwright, Puppeteer, Cypress),
use the local route, real HTTPS, no network:

```bash
routeup serve example-app --port 3000
```

```js
await page.goto('https://example-app.localhost');
```

This exercises secure cookies, service workers, and `https`-only web APIs that a
plain `http://localhost:3000` would not.

### Trusting the CA in the runner

Browsers launched by these tools usually use the system trust store, so the
routeup CA is already trusted. If a runtime ships its own CA bundle, point it at
the routeup CA:

```bash
export NODE_EXTRA_CA_CERTS=~/.routeup/ca.crt
```

Apps with a separate trust store may need the CA imported through their own
settings. See [Custom CA certificates](/docs/configuration/custom-ca-certificates).

## Off-host or cloud browsers

When the browser runs somewhere else, CI, a cloud browser, or an LLM agent
driving a remote browser, `localhost` is not reachable. Expose the route and
hand the agent the public URL. First configure a public server as described in
[Exposing publicly](/docs/getting-started/exposing-publicly). This example assumes your saved token allows
`*.team.routeup.dev`:

```bash
routeup serve example-app --port 3000 --expose
```

```txt
https://example-app.team.routeup.dev
```

The configured route and namespace let you request the same target URL between
runs, so test configs and prompts do not need a newly generated URL. Public
claims remain subject to the server's normal conflict rules.