Native Server Tray and Administration

Published native server packages include a system-tray UI. Headless and Docker servers run without it; administer those through the web interface and service/container manager.

Tray information

The icon and popover summarize server status, connected clients, active/waiting/recent agents, and update state. Selecting a card opens it through the stib:// desktop link when possible and falls back to the local web URL.

The running server version is shown next to the name in the popover header, and at the foot of the native menu. It turns amber when an update is available.

Selecting the connected-client count opens the list of live connections: who is connected, from which client (desktop, browser, mobile), from which address, and for how long. A loopback connection reads as this machine. The same list is reachable from Connected clients in the menu.

The foot of the menu lists the server's own addresses — the local one, and the external URL when an operator configured one (Settings → Server, or STIB_API_URL). Selecting either copies it to the clipboard.

The native menu provides actions to:

• open Stib, through the desktop app when it is installed;
• open the server logs page, always in a browser — the logs are consulted precisely when the desktop client is the suspect;
• export rolling server logs;
• stop all agents;
• restart the server after it has stopped;
• enable operating-system autostart;
• install an offered native server update;
• quit, with a warning when agents are still running.

“Quit” stops the server process, not just the tray icon. Every connected web, desktop, and mobile client loses access until it restarts.

Web administration

Use Settings → Server for durable configuration. The tray is intended for local process control and status, not for managing users, credentials, integrations, backups, authentication, API keys, or encryption.

Updates

The server checks the signed manifest 30 seconds after startup and every 24 hours thereafter. Stable/beta channel comes from the build version or STIB_RELEASE_CHANNEL; STIB_UPDATE_URL can override the manifest endpoint for controlled deployments.

The updater validates schema, target platform/architecture, checksum, signature, and expected installation strategy. Native packages use PKG, MSI, or DEB. Docker and generic tarball deployments should be updated by their operator instead.

An update can wait for active agents and report progress. Create a backup first and do not force-terminate the process during database migration or package replacement.

Headless service control

Use the service installed by your package or your own supervisor. For Docker, use docker compose. Avoid running two server processes against the same data directory; port fallback does not make shared SQLite access a supported active-active deployment.

Next: Server Configuration and Desktop Features.