Running on Linux Servers
Run the gateway on a Linux server, with a virtual display, the sandbox, remote clients and setup without a terminal.
This page covers running the gateway on a Linux server: the display, the sandbox, clients on other machines, and setup without a terminal.
Platforms
bauta and the browser ship for Linux, macOS and Windows, x64 and arm64; Windows arm64 runs the x64 build. The
Linux binary is built against glibc 2.31 (Debian 11 / Ubuntu 20.04 and later) and measured on Ubuntu 24.04.
Set up without a terminal
The install script and the packages never prompt when stdin/stdout is not a terminal, CI is set, /.dockerenv
exists or BAUTA_NO_PROMPT=1. They then activate the free plan (one session) without asking.
export BAUTA_NO_PROMPT=1
curl -fsSL https://bauta.dev/install.sh | bashTo run setup yourself without its questions, use bauta setup --non-interactive.
Use a license key
Set BAUTA_LICENSE_KEY. When set, it wins over the key kept on the machine.
export BAUTA_LICENSE_KEY=<license key>
bauta serveThe server limits new free activations per IP, so in CI or with many containers, set a key (License keys).
Open windows on a virtual display
Each browser opens a window sized to its persona's screen. On a machine without a display, install Xvfb, and
bauta serve opens the windows on a virtual display of its own:
apt install xvfb
bauta serveWithout Xvfb, bauta serve falls back to Chrome's headless mode, which a page can tell apart, and says so.
Hide the windows
bauta serve --hidden puts the browsers' windows where no one sees them, even on a desktop:
| OS | where the windows go |
|---|---|
| Linux | A virtual display, whatever DISPLAY says. |
| Windows | A desktop of the gateway's own, where a page is visible and focused and WebGL runs on the GPU as on any desktop. |
| macOS | Chrome's headless mode. |
The packages' headless option, on by default, asks for it.
The sandbox on Ubuntu 24.04
AppArmor stops a Chrome it does not know from using unprivileged user namespaces. Point CHROME_DEVEL_SANDBOX at a
SUID sandbox helper; stock Chrome's /opt/google/chrome/chrome-sandbox works:
export CHROME_DEVEL_SANDBOX=/opt/google/chrome/chrome-sandboxOr launch with --no-sandbox. A persona applies either way.
Let other machines connect
bauta serve --listen 0.0.0.0--listen 0.0.0.0 lets other machines in, and whoever reaches the port drives the personas. Keep the port behind
your own access control.
From the packages, gateway (or BAUTA_GATEWAY) uses a gateway that runs elsewhere; you make its personas there.
| option | default | what it does |
|---|---|---|
--listen | 127.0.0.1 | The address the gateway listens on. |
--port | 9222 | The gateway's port. |
--idle | 30 | Seconds a persona's browser stays open after its last client. |
--per-browser | 8 | How many personas share one browser, at most; 1 gives each persona a browser of its own. |
--hidden | off | The browsers' windows where no one sees them. |
bauta stats shows the gateway's active and queued personas, against the license.
Timezone and locale when you launch the browser yourself
Timezone and locale are launch settings: they come from V8 and ICU, outside the binding layer. The gateway sets
them from a persona's "timezone" and "locale". When you launch the browser yourself, set TZ, and LANGUAGE
and LANG:
TZ=America/New_York LANGUAGE=en_US LANG=en_US.UTF-8 \
BAUTA_LICENSE=~/.bauta/license \
BAUTA_PLUGIN_CONFIG=$PWD/personas/win-intel.json \
FONTCONFIG_FILE=$PWD/personas/fonts/win.conf \
/path/to/bauta/chrome --user-data-dir="$(mktemp -d)" https://example.com