openmixerGitHub →

First boot

A fresh install boots a complete, working console with no configuration and no environment variables. This page describes what you should see and how to confirm it.

What starts

openmixer-server.service runs

/usr/bin/openmixer-server --config /etc/openmixer/config.json

and the shipped /etc/openmixer/config.json is empty:

{}

It has nothing to select. There is one boot path — the console — and it is the product: a sized input/output topology, its own virtual PipeWire nodes, the plugin catalog, the buses, the native mix engine. The desk you see on first boot is the desk you will use.

It was chosen by a rig.preset key until 2026-07, when the second rig (bare, which started no engine and which nothing ever selected) was deleted. An upgraded host keeps its own /etc/openmixer/config.json, so a file naming any of the old presets still parses — the server ignores the key and says so at startup.

The file is marked %config(noreplace), so your edits survive a package upgrade.

Where the surface lives

nginx terminates TLS and HTTP/2 with a certificate the console issues itself, and serves the surface at:

https://<host>:8443/

The server itself listens on 8080 (loopback only) and nginx proxies /api/* (the REST entity API and its ?watch=1 live streams), /manual, /health, /telemetry and /patchbay/* to it. There is no WebSocket — every live value on the surface arrives over that same HTTPS connection. Port 8880 carries no API: it only redirects to 8443 and serves the page a browser uses to install the console's certificate before it trusts it, at http://<host>:8880/trust/.

The console's own browser needs nothing — installing openmixer-web-ui puts the certificate authority into that machine's system trust store. Every other device needs one step, once: see Trusting the console's certificate. See Ports for the full picture, and the web UI cannot reach the server if a device will not connect.

Health checks

systemctl --user status openmixer-server
curl -s http://127.0.0.1:8080/health
curl -sk https://127.0.0.1:8443/api/net/binding

/api/net/binding answers with the network facts the surface uses (host, port, which layer set them). /health answers with the server's liveness view.

From another machine, the equivalent through nginx:

curl -sk https://<host>:8443/health

What you should see in the browser

The surface draws a header with the openmixer mark, a connection indicator, the theme and personality pickers and the two panic buttons; a channel view across the upper part of the screen; and the fader bay below. The connection indicator is the thing to read first — it says Connecting, Connected, Demo (offline) or Disconnected.

Demo (offline) means the browser could not reach a server and is drawing a simulated board. It is a useful way to learn the controls, but nothing you do in it touches audio. If you see it on a fresh install, go to the web UI cannot reach the server.

Logs

Both units log to the journal:

journalctl --user -u openmixer-server -f
journalctl --user -u reac-pw -f

Does the desk work at all?

Five checks, two minutes, before you trust anything else on the console. If any of these fail, stop here and fix it before going further — everything else assumes they hold.

  1. The board comes up populated. Open the surface in a fresh, cold browser tab (not a reload of one you had open before) — twice. Every time, the full channel board appears: no tab that connects but shows no strips.
  2. A reload keeps the desk. Reload the tab against a running console. Every strip reappears, in the same order, with its name, and the faders sit where the mix left them.
  3. A restart reconnects on its own. Restart the server (systemctl --user restart openmixer-server) while the tab is open. The connection indicator shows Disconnected, the values on screen do not reset, and the surface reconnects by itself once the server is back — no reload needed. Move a fader after it reconnects and confirm the move lands.
  4. A restart never leaves audio running unmanaged. With something audibly playing into a channel, restart the server. The room goes silent the moment the server stops — never a burst of raw, unmixed audio — and stays silent until the console has reconnected and taken the graph back over.
  5. Routing and trims survive a restart. In the patchbay, assign an input to a channel and set a trim on an output, then restart the server. Both are still there once it reconnects — routing and trims are part of the session, not the running process.

Next

Your first session takes you from this state to audible sound.