sonn core is a complete multiroom audio solution — a modern TypeScript audio server that streams to zones across your home, with a wide range of sources, inputs, outputs, and external service bridging. It can run entirely on its own, or integrate with Loxone as a full functional emulation of the Loxone Audio Server.
sonn core runs in two modes:
- Standalone — runs on its own, with no Loxone hardware required. You configure zones and sources directly in the Admin UI.
- Loxone integrated — pairs with a Loxone Miniserver and stays fully compatible with Loxone Audio Servers; zones and configuration come from your Loxone project.
You choose the mode on first launch and can switch later by resetting the server configuration.
- Radio support backed by TuneIn and Radio Paradise
- Custom radio stream management
- Local music library
- File storage
- Shared network drives
- Per-zone recents and favorites
- Per-zone equalizer
- Multi-account Spotify support
- Alert engine
- Native Loxone alerts
- Text-to-Speech (TTS), including LoxBerry TTS over MQTT
- Spotify Connect
- AirPlay
- Line-in (with optional Shazam track recognition)
- Music Assistant
Zones can stream to a range of network and local playback targets:
- Google Cast (Chromecast)
- Sonos
- Snapcast
- Sendspin
- AirPlay
- DLNA / UPnP
- Squeezelite
- Music Assistant
- Spotify Connect
To expose unsupported services to Loxone, sonn core introduces bridge providers.
A bridge provider acts as a proxy layer that exposes a non-Spotify service as a virtual Spotify account.
Each bridge maps one external service to one virtual Spotify account, allowing Loxone to list and use multiple unsupported sources side by side without conflicts.
- Apple Music
- Deezer
- Tidal
- Youtube Music
- SoundCloud
- Music Assistant
All features, inputs, and bridge providers are fully configurable through the Admin UI.
- Docker (recommended) — easiest way to run the server without building from source.
- docker-compose (optional) — the repository includes a
docker-compose.ymlfor one-command startup. - Make sure host ports
7090,7091and7095are available (or adjust host mappings when running the container). - Network share library support relies on Unix-style mount tooling (e.g.,
mount.cifs); this is not available on Windows hosts.
The easiest options are docker-compose or docker run.
If you have Docker and docker-compose installed you can use the included docker-compose.yml:
docker compose up -dThis starts a container named sonn-core in host network mode, which is the simplest way to allow mDNS/UPnP/Snapcast discovery without extra flags. Because host mode bypasses port publishing, make sure ports 7090, 7091, and 7095 are free on the host. To persist configuration and library data, add a bind mount to the service in docker-compose.yml:
volumes:
- ./data:/app/datadocker compose up -d always pulls the published image and never builds, so it works on a host without the source checkout. If you have this repository checked out and want to build the image locally instead, layer the build override on top:
docker compose -f docker-compose.yml -f docker-compose.build.yml build
docker compose up -dIf you want to use the Power Manager with gpioset or USB HID relay boards from inside Docker, the container also needs access to the host devices. Expose the relevant /dev/gpiochip* and/or /dev/hidraw* entries, or run the container with elevated device access. Without that, GPIO and CRelay calls can succeed on the host shell but still fail in the container.
For gpioset, configure the chip and the line offset within that chip. On a Raspberry Pi 4, header GPIO22 is typically line 22 on /dev/gpiochip0; the old sysfs-style global number like 534 is not the value gpioset expects.
Shared amp or PSU switching is also supported through groups.powerGroups[]. Set a zone's powerManager.powerGroupId to the shared group id, then configure the group's own powerManager.gpio or powerManager.crelay. The shared output turns on while any member zone is active and turns off after the last member stops.
If you prefer docker run, host networking is recommended:
docker run -d \
--name sonn-core \
--network host \
-v $(pwd)/data:/app/data \
ghcr.io/sonn-audio/core:latestIf you must use bridge networking instead, remove --network host and add port mappings -p 7090:7090 -p 7091:7091 -p 7095:7095.
If you prefer to run the server directly on the host without Docker, follow these steps. This is a minimal "standalone" run and requires Node.js and npm.
Prerequisites
- Node.js 20 or newer (Docker images and CI build on Node 24)
- npm (comes with Node)
- Ports
7090,7091and7095available on the host
Step-by-step
- Clone the repository and change directory:
git clone https://github.com/sonn-audio/core.git
cd core- Create a persistent data folder (used for config, logs, and cache):
mkdir -p data- Install dependencies and build:
npm install
npm run build- Start the server:
npm startOpen the admin UI at http://sonn-core-ip:7090. On first launch it asks how the server should run:
Standalone — no Miniserver required. Add your zones directly in the Admin UI (up to 24) and assign sources and outputs to each. This is the quickest way to get playback running without any Loxone hardware.
Loxone integrated — the guided steps walk you through adding the Audio Server in Loxone Config, rebooting the Miniserver, pairing, and assigning zones/providers once the Miniserver reconnects. Zones and their configuration are taken from your Loxone project. When sonn core starts successfully and the Miniserver pairs successfully with it, the Audio Server icon in Loxone Config turns green.
You can change the mode later by resetting the server configuration.
Need help or found a bug? Open an issue in the repository.